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

181–190 of 385 posts

Re: Remote code execution, git, and OS X

#181

Post by fvargas »

raimue wrote: post #175
OJFord wrote: post #170

> They are basically screwed until Apple deigns to > deliver a patched git unto them Actually, no. Don't use the tools that come pre-installed. All you have to do* is: brew install git *and make sure that brew installs are prioritised in your $PATH. Which you should do anyway.

Then you will get caught by some GUI that uses /usr/bin/git. Be aware changes to PATH in your shell startup files do not affect graphical applications at all. Just installing git from Homebrew or MacPorts is not enough to be safe from this remote code execution.

Yosemite and El Capitan prioritize /usr/local/bin over /usr/bin, so if you install the latest version of git via Homebrew, you're mostly okay. If you're using Mavericks or older, it is as described above.

That said, any program that invokes /usr/bin/git directly instead of /usr/bin/env git would still be vulnerable.

It's not as big of a problem as the article makes it out to be so long as you install a newer version of git.

If you're really concerned, the filesystem restrictions mentioned can be bypassed by booting into safe mode. Though it's still not a good idea to mess with the default program installations since Apple may depend on that particular version of git for some program.

Re: Remote code execution, git, and OS X

#182

Post by chris_wot »

userbinator wrote: post #167
chris_wot wrote: post #157

Earlier quoted context omitted.

Sometimes I think that Apple are increasingly trying to lock down OS X to prevent anything from being installed outside of its own walled garden. The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature…

The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature that is preventing the security vulnerability from being fixed. I understood the point perfectly well, and that's why I think it's a bit overblow…

In other words: if you want to live in a walled garden with lots of holes, then use SIP. Good to know.

Re: Remote code execution, git, and OS X

#183

Post by e12e »

fauigerzigerk wrote: post #81
mjn wrote: post #70

Earlier quoted context omitted.

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…

What if I want to decide for each individual package if it should get (a) upgraded to the latest version (b) upgraded to the latest version that the developer considers API compatible (c) kept frozen Is there a way to do that with the debian package management system?

If you're on Debian, an want to try and run testing/unstable, you probably want to install "apt-listbugs" -- which will warn you about open bugs in software you're installing/updating. Another option is to run Debian stable, and have testing and/or unstable chroot, managed via schroot: https://wiki.debian.org/Schroot (that page and the manpages could use an update, but having a scroot backed by lvm, and set up to mount /home works well enough for running x11 apps (the MIT auth cookie is in $HOME)).

I would recommend trying to keep things separate like that (or via something like docker/kvm/vagrant/etc) -- rather than trying to mix'n'match. You'll likely be the only one trying a particular combination of versions, and it's unlikely to be much fun.

Re: Remote code execution, git, and OS X

#184

Post by chris_wot »

trywerwerwer wrote: post #169
userbinator wrote: post #160

Earlier quoted context omitted.

Rewriting in any language won't help with this one unless the language has builtin integer overflow checking. The solution here is actually quite trivial: just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.

> just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane. Funny, because I've actually been locked up for being insane five times. Speaking from experience, they'd only consider me insane if I said something like 255 was an important number because there are two sides to ever…

As someone who has also spent time in a mental institution, I just want to say that I really think you need to be less sensitive on this one. That's just an expression and not in any way aimed at people who have mental illness.

Re: Remote code execution, git, and OS X

#186

Post by blub »

userbinator wrote: post #160
blub wrote: post #103

Earlier quoted context omitted.

I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better. A lot of Linux C utilities would benefit from such a treatment.

Rewriting in any language won't help with this one unless the language has builtin integer overflow checking. The solution here is actually quite trivial: just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.

The trick is to not do any index calculation.

I think that using std::string would prevent the bug, because it would throw length_error on append. string::resize can be used to avoid excessive allocations.

Sanity checks would provide extra safety, but the code should fail cleanly even without them.

Re: Remote code execution, git, and OS X

#187

Post by emmelaich »

xyzzy123 wrote: post #47
tadfisher wrote: post #23

Earlier quoted context omitted.

Now grep your system for `/usr/bin/git`.

$ grep -rc /usr/bin/git /usr/bin/ /usr/local/bin/ /usr/sbin/ /sbin/ | grep -v ':0' | wc -l 0

er..

    find /usr/bin/ /usr/local/bin/ /usr/sbin/ /sbin/ |grep -w git

Re: Remote code execution, git, and OS X

#188

Post by blub »

lmm wrote: post #155
blub wrote: post #103

Earlier quoted context omitted.

I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better. A lot of Linux C utilities would benefit from such a treatment.

If you're going to rewrite in any case surely it's worth going to Rust (or Ada, or another language that simply doesn't have the myriad unsafe possibilities that C++ does).

There are many arguments to be made in favor of C++, such as talent availability, experience from other porting projects, the possibility of doing incremental porting, etc.

My impression is that some projects are already experimenting with or using C++ in their C code bases, so C to C++ is quite likely.

Re: Remote code execution, git, and OS X

#189

Post by anu_gupta »

chris_wot wrote: post #148
anu_gupta wrote: post #138

Earlier quoted context omitted.

No, I'm just bored of faux-outrage and agenda pushing. If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it. [edited to add] It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?

You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway. https://github.com/gdbinit/rootfool Incidentally, calm down a bit - you sound pretty outraged yourself! You m…

> Incidentally, calm down a bit - you sound pretty outraged yourself!

This seems to be your pattern when you get upset. You've told someone else they were being defensive, now you're saying I need to calm down.

I guess that's easier than rebooting a server and turning off SIP.

Re: Remote code execution, git, and OS X

#190

Post by blub »

joushou wrote: post #149
blub wrote: post #103

Earlier quoted context omitted.

I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better. A lot of Linux C utilities would benefit from such a treatment.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

Yes it would, because this is basically string processing where C is the worst possible language one could use. I've detailed in another comment how std::string could be used.
Post reply on HN