Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

61–70 of 385 posts

Re: Remote code execution, git, and OS X

#61
post #60

I have my git repo on debian stable and git --version git version 2.1.4 Should I be worried?

As long as you have the latest version (2.1.4-2.1+deb8u2) from the repository you should be safe, as Debian usually backports security patches. You can check the changelog: http://metadata.ftp-master.debian.org/changelogs//main/g/git...

Re: Remote code execution, git, and OS X

#63
post #53
post #22

Earlier quoted context omitted.

Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.

Sure, as many other software with vulnerability, but with local software like brew (I wrote also [dotsoftware]( http://g14n.info/dotsoftware ) for the same reasons) you don't have it in your PATH so you are not using it. Using local software has many benefits, among others, a shorter release cycle.

As I said, one config mistake or running a script which uses /usr/bin/git and you're subject to RCE. For example, many GUI programs, such as Atom editor, when not launched from terminal, don't know your PATH.

Re: Remote code execution, git, and OS X

#66
post #60

I have my git repo on debian stable and git --version git version 2.1.4 Should I be worried?

No, as long as "dpkg -l git" shows that you have package version 1:2.1.4-2.1+deb8u2 or later. Debian backported the fixes:

  git (1:2.1.4-2.1+deb8u2) jessie-security; urgency=high
  
    * Non-maintainer upload by the Security Team.
    * Fix remote code execution via buffer overflows (CVE-2016-2315, CVE-2016-2324) (Closes: #818318)
  
   -- Salvatore Bonaccorso   Fri, 18 Mar 2016 06:20:38 +0100
The Debian Changelog (where you find this stuff out) is linked from the package page at https://packages.debian.org/jessie/git (on the right hand side under Debian Resources) or you can look at /usr/share/doc/git/changelog.Debian.gz on your system.

Re: Remote code execution, git, and OS X

#67
post #60

I have my git repo on debian stable and git --version git version 2.1.4 Should I be worried?

As long as you have the latest version (2.1.4-2.1+deb8u2) from the repository you should be safe, as Debian usually backports security patches. You can check the changelog: http://metadata.ftp-master.debian.org/changelogs//main/g/git...

Why does debian do that instead of upgrading everyone to the latest git version?

Re: Remote code execution, git, and OS X

#68
Initially I was shocked that the vendor has files on the system that cannot be changed by the user.. but now I think there is more to it.

The real thing that is bugging me, is finding out what /usr/bin/git really is.. which this article doesn't answer.

Is it a standalone immutable executable that the file system is aware of, or something else?

Right now, I wish I had a mac.

Re: Remote code execution, git, and OS X

#69
post #46

Earlier quoted context omitted.

And at this point the first instruction for any OSX user who downloads and compiles anything is "Install Homebrew"

The Homebrew installation process uses the system git.

Yep, since Homebrew requires the Xcode Developer Tools to be installed (which of course includes the outdated Git).

Re: Remote code execution, git, and OS X

#70

Earlier quoted context omitted.

As long as you have the latest version (2.1.4-2.1+deb8u2) from the repository you should be safe, as Debian usually backports security patches. You can check the changelog: http://metadata.ftp-master.debian.org/changelogs//main/g/git...

Why does debian do that instead of upgrading everyone to the latest git version?

Debian 'stable' releases mainly target people who like fixed upgrade cycles. No feature/API/etc. changes for the lifetime of a release, only security patches. Means that you can have your servers routinely applying updates with relatively little worry that something is going to stop working because of a change. Even minor feature changes can break things, especially when run in scripts, so they prefer not to risk non-security updates, even small ones. Then you upgrade to the next release at a time scheduled to debug any problems that come up. I believe RHEL releases work somewhat similarly.

For my developer machine I prefer rolling updates, so I run Debian 'testing' on that one, which is basically a snapshot of what is going to be the next stable release, with daily updates (there are also distros like Arch that only do rolling release).

There's also a kind of in-between option: http://backports.debian.org/

Post reply on HN