Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

Post reply on HN
Print view View original

351–360 of 385 posts

Re: Remote code execution, git, and OS X

#351

Post by ubernostrum »

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…

People like Richard Stallman have been warning about this sort of thing for decades.

Any GNU/GNU, GNU/Linux, or GNU/anything system could do exactly the same thing without violating any terms of the GPL. Requiring a reboot into a special "I know I'm messing with the system" mode in order to mess with important core binaries is not an unreasonable way protect the user from malware, and does not in any way abridge any of the core freedoms Stallman promotes.

(and yes, you literally can run a command and reboot your Mac to be able to make changes to the protected stuff, and the process to do this is well-documented)

Re: Remote code execution, git, and OS X

#352

Post by joushou »

satysin wrote: post #348
joushou wrote: post #314

Earlier quoted context omitted.

A little, but you have enough to get started. Rather an old bash than no bash. First task on OS X is usually to use the bundled curl and ruby to get homebrew. :)

Will be interesting when Windows comes (well via an update) with a later version of bash than OS X!

Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.

Re: Remote code execution, git, and OS X

#353

Post by satysin »

joushou wrote: post #352
satysin wrote: post #348

Earlier quoted context omitted.

Will be interesting when Windows comes (well via an update) with a later version of bash than OS X!

Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.

I am pretty sure we will see a better terminal come out thanks to this new Linux sub-system or whatever they decide to call it.

Re: Remote code execution, git, and OS X

#354

Post by opejn »

atdt wrote: post #11
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.

It's a bit too precarious to be an adequate solution, in my opinion. It depends on /usr/local/bin always being ahead of /usr/bin in $PATH, and on scripts never invoking the system git via its full path, and on Homebrew never accidentally uninstalling git due to a botched upgrade. Not to mention the fact that Homebrew itself uses the system git to install itself.

> Not to mention the fact that Homebrew itself uses the system git to install itself.

To me, this is the biggest problem, and it's not just Homebrew. Any source package manager that uses Git will potentially have this problem. With a vulnerable Git on your system, you have to second-guess every build script you ever run that might make use of Git, to make sure it obeys the path you set instead of choosing its own.

Re: Remote code execution, git, and OS X

#355

Post by eeeeeeeeeeeee »

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…

Router companies have the exact same problem. They package software that will probably be out of date by the time it ships to the customer and there is rarely a mechanism to update it except "buy a new one."

Re: Remote code execution, git, and OS X

#357

Post by pdonis »

Sidnicious wrote: post #336
pdonis wrote: post #294

Earlier quoted context omitted.

> 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 unacc…

It's interesting, lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer (Apple or some Linux distro's community). I configure my package managers (brew, pip, gem…) to install to my home directory and set up my PATH accordingly. This way, I don't have to worry at all about the state of my OS (e.g. whether an upgrade will damage some customizat…

> lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer

As an ordinary user, this can be perfectly reasonable. I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user. Developers need a level of control over their machines and configurations that ordinary users, as a rule, don't.

Re: Remote code execution, git, and OS X

#358

Post by pdonis »

joushou wrote: post #315
pdonis wrote: post #291

Earlier quoted context omitted.

> 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. > W…

> You have the user's execution rights only; you don't have root access. That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it. Also, privilege escalation bugs. > This is true of any program the user…

> code execution

Code execution how? How are you going to execute code on my machine if you don't have physical access to it? That's why the RCE makes a difference.

> it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no?

As I understood the comment that started this subthread, it was talking about using a remote code execution vulnerability to modify .bashrc. Nobody, as far as I can tell, in this discussion is talking about having local (i.e., physical) access to the machine.

Re: Remote code execution, git, and OS X

#359

Post by chetanahuja »

comex wrote: post #97
chetanahuja wrote: post #94

So... to try and get an answer to the unanswered question in the blogpost. The files are probably hardlinks to a single "superbinary" image somewhere. The actual code is probably checking the value of argv[0] to dispatch to the actual git code (or whatever command name was invoked). The question is, why is Apple doing this? Is it some sort of diskspace saving scheme (to avoid duplicating common boilerplate code)? I s…

Nah, the binary doesn't actually contain git. It's just a stub (in /usr/bin) that locates Xcode on the system (in /Applications/Xcode.app by default but configurable) and execs the real git binary from there. See also: https://developer.apple.com/library/mac/documentation/Darwin...

OK great. So now the question is why? I've seen this "multiplexed binary" scheme implemented elsewhere in more constrained circumstances but it doesn't really make sense to me for a desktop OS to be doing it.

Re: Remote code execution, git, and OS X

#360

Post by hobarrera »

joushou wrote: post #346
jamessb wrote: post #338

Earlier quoted context omitted.

It doesn't hide anything related to git The link between /usr/bin/git and /Application/Xcode.app/Contents/.../bin/git is hidden. I don't know how you would discover this: ls indicates /usr/bin/git is a regular file rather than a symlink; stat -f "%i" says the two files have different inodes, so they're not hardlinked. What is the nature of the link, and how would you find this if you didn't already know?

man xcode-select - It's right there in the manpage. /usr/bin/git is a "toolshim" that effectively calls "xcrun git" (it actually calls xcselect_invoke_xcrun, from /usr/lib/libxcselect.dylib, if you really want the details - this can be found by inspecting the binary). xcode-select's manpage tells you that these shims call the respective binary in the active developer directory, whereas xcrun's manpage describes its c…

How did you reach that man page from the git manpage?
Post reply on HN