Remote code execution, git, and OS X • Hacker News Board

Re: Remote code execution, git, and OS X

#291

Post by pdonis » Mon, Apr 18, 2016, 4:25 PM UTC

joushou wrote: post #274

falcolas wrote: post #251

Earlier quoted context omitted.

> Tricking you into using the old version would require execution rights on the machine Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user). Re-ordering `/usr/bin` and `/usr/local/bin` in $PATH isn't that hard.

With the ability to modify .bashrc, you have execution right to the machine. If not before, to modify the file, then after, because you modified a shell script that is automatically run all the time. Thr machine is already pwned, and one privilege escalation bug away from being completely lost. With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. It is hardly related…

> With the ability to modify .bashrc, you have execution right to the machine.

You have the user's execution rights only; you don't have root access.

> Thr machine is already pwned, and one privilege escalation bug away from being completely lost.

This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge.

> With this level of privileges, you can, on any machine, mask existing binaries with whatever you want.

And the user can unmask them just as easily. It's not at all the same as having root access.

Re: Remote code execution, git, and OS X

#292

Post by mcintyre1994 » Mon, Apr 18, 2016, 4:26 PM UTC

I have a macbook with command line tools installed and I have homebrew installed. I think I installed Python on brew, but which git tells me I'm using /usr/bin/git for that.

Is there a list somewhere of dangerously old software Apple have shipped to me that I should reinstall with brew immediately?

Re: Remote code execution, git, and OS X

#293

Post by mikegerwitz » Mon, Apr 18, 2016, 4:28 PM UTC

It's a shame that Git uses GPLv2; this would not be permitted under v3. Unless, I suppose, Apple does actually provide a means of replacing these programs.

Of course, the overall issue of not being able to modify the software on your own system still holds.

Re: Remote code execution, git, and OS X

#294

Post by pdonis » Mon, Apr 18, 2016, 4:28 PM UTC

joushou wrote: post #240

cs702 wrote: post #236

Companies like Apple and Microsoft prevent you from modifying the software installed on your computer to improve your security. Ironically, when they do that, they also make it difficult, impractical, or impossible for you to upgrade or disable vulnerable software (in this case, an old, insecure version of git with remote-code-execution vulnerability). People like Richard Stallman have been warning about this sort of…

I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH. Tricking you into using the old version would require execution rights on the machine. You can also remove the /usr/bin/* binaries if you boot the mac…

> installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH

Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacceptable. I want full root access to my development machine, not a dumbed down version of "root" that doesn't let me mess with certain things. This is one of the key reasons why I will not use a Mac as a development machine.

Re: Remote code execution, git, and OS X

#295

Post by kaffeinecoma » Mon, Apr 18, 2016, 4:29 PM UTC

geofft wrote: post #273

kaffeinecoma wrote: post #257

Earlier quoted context omitted.

Re-writing Git in C++? Can't tell if you're trolling or not. http://harmful.cat-v.org/software/c++/linus

Argument 1 is nontechnical and by someone who does not have a lot of experience writing userspace software. Argument 2 is valid, but only applies to kernels, and also only applies to 1992 (it works a lot better now).

My comment wasn't meant to knock C++; it was to point out that Linus' opposition to the language is well-documented, and an official git-rewrite in C++ is very unlikely.

Re: Remote code execution, git, and OS X

#296

Post by cname » Mon, Apr 18, 2016, 4:35 PM UTC

fniephaus wrote: post #106

StreamBright wrote: post #87

Earlier quoted context omitted.

Are you not using virtualenv? I always use virtual environments as much as possible to avoid being locked in on an older version (for example Python in this case).

Of course you can also use virtualenv, but if Apple kept software that ships with OS X up-to-date I wouldn't have to deal with this at all.

It seems like this is an issue with most operating systems. Regarding Python in particular, RedHat/CentOS seems particularly "bad".

My take is that the OS-installed tools, such as git or Python, are generally for use by the system and not for use by me for software development.

Re: Remote code execution, git, and OS X

#297

Post by fauigerzigerk » Mon, Apr 18, 2016, 4:40 PM UTC

jordigh wrote: post #284

fauigerzigerk wrote: post #222

Earlier quoted context omitted.

The problem with this concept of "stability" is that it depends on a particular software development philosophy that isn't shared by all projects. It works well if developers make sure that bugs in older versions of their software are fixed even after the next version is released. I think that is the case with a lot of infrastructure sort of software. But if developers do not maintain old versions and fix bugs only b…

Debian's system does not require developers to maintain older versions, only to clearly indicate security fixes. Debian patches its own older versions to include the security fixes.

I understand that, but it means that debian inevitably distributes buggy software in a supposedly 'stable' distribution.

And I don't mean buggy in the sense that all software is buggy. I mean buggier than the best compatible release version available.

Re: Remote code execution, git, and OS X

#298

Post by sbuk » Mon, Apr 18, 2016, 4:45 PM UTC

aorth wrote: post #6

reedloden wrote: post #2

Isn't this why projects such as Homebrew thrive? For me personally, I just `brew install git`, and I keep it updated that way (`brew update && brew upgrade`)... Sure, Apple should ship a fix, but there are ways around it for now.

Yes, indeed, but Mac OS X users who use Homebrew are a subset of all Mac OS X users. The problem is in the default software. Apple's update model isn't good for this type of software, so the fact that it is possible for a user to install secure versions from Homebrew (or compile their own) doesn't matter.

I'd argue that the the OS X user who use git are a subset of Mac OS X users. In fact, a similar subset to that which uses Homebrew...

Re: Remote code execution, git, and OS X

#299

Post by makecheck » Mon, Apr 18, 2016, 4:50 PM UTC

Apple clearly has some frequency of updates (10.11.x updates, security updates, etc.) so the fact that they’re a corporation or using closed-source, etc. is not necessarily relevant. If they want to patch something tomorrow, they can.

Since they haven’t changed this package, there may be another reason besides security. For example, some important group at Apple or a big customer may have created a dependency on "git" functionality, and they want to carefully test any change on a large scale before proceeding. Just because it isn’t wise for important things to depend on fragile environments doesn’t mean they can ignore those environments when making changes.

The problem with simple versions is that an update seems to be all or nothing: you can’t easily fix a small security hole when starting from a few versions ago because you have to consider anything else that changed. Ideally, systems are designed in enough layers that small updates really are practical without affecting other features.

Re: Remote code execution, git, and OS X

#300

Post by geofft » Mon, Apr 18, 2016, 4:52 PM UTC

kaffeinecoma wrote: post #295

geofft wrote: post #273

Earlier quoted context omitted.

Argument 1 is nontechnical and by someone who does not have a lot of experience writing userspace software. Argument 2 is valid, but only applies to kernels, and also only applies to 1992 (it works a lot better now).

My comment wasn't meant to knock C++; it was to point out that Linus' opposition to the language is well-documented, and an official git-rewrite in C++ is very unlikely.

Linus is almost entirely uninvolved with git these days, though. `git log --author=Torvalds` finds no commits in 2015 or so far this year, three patches in 2014, none in 2013, five in 2012, four in 2011... if the git core team felt using C++ was a possible course, Linus would not be involved in the decision.

(That's probably why I misunderstoood your statement an argument against C++ on its own merits.)