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

251–260 of 385 posts

Re: Remote code execution, git, and OS X

#251

Post by falcolas »

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…

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

Re: Remote code execution, git, and OS X

#252

Post by falcolas »

zaphar wrote: post #247
blub wrote: post #188

Earlier quoted context omitted.

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.

But if the goal of the rewrite is safer tooling then Rust wins.

Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages.

When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".

Re: Remote code execution, git, and OS X

#253

Post by coredog64 »

falcolas wrote: post #251
joushou wrote: post #240

Earlier quoted context omitted.

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…

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

I would argue it's not even that difficult. In the README.md, put some kind of note that there's a bug in the current version of git (and maybe point to some random Google group posting) and mention that on OS X it's better to use the XCode version.

Re: Remote code execution, git, and OS X

#254

Post by steveklabnik »

blub wrote: post #103
pjmlp wrote: post #76

Best part: > So, what's the big deal? Crappy C code gets exploited every day, and we upgrade it, and then we're "safe" until the next huge hole that's been there forever is reported. (In the meantime, people party with their private stash of vulnerabilities.)

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.

Since we're talking about git, here's an interesting PR: https://github.com/libgit2/libgit2/pull/3540

(EDIT: Some stuff has changed since February, so some of these claims are now out of date. But not all of them, the overall situation is still similar.)

Re: Remote code execution, git, and OS X

#255

Post by raimue »

chris_wot wrote: post #237
amake wrote: post #218

Earlier quoted context omitted.

> I'm still trying to understand why Apple install XCode command line utilities into an area of the system that is protected by SIP. They don't. Plenty of comments explain where the Xcode git actually is.

And as has also been asked - why do they symlink to the /usr/bin directory in the first place then? They have three perfectly reasonable directories they can install into, which is what they recommend that application developers do when installing their software: /Applications /Library /usr/local So why do they feel the need to link git into /usr/bin? They could link it into /usr/local/bin - the $PATH variable includ…

There are no symlinks in /usr/bin, they are wrapper programs determining whether you already have the Command Line Tools or full Xcode installed. If not, they will open dialogs asking you to install these additional software packages.

Re: Remote code execution, git, and OS X

#256

Post by w8rbt »

pjmlp wrote: post #229
blub wrote: post #221

Earlier quoted context omitted.

Using std::vector, std::string and smart pointers would already bring large benfits, so even a C-like subset could work fine. The point is that code like in that function is a nightmare to write correctly and test in plain C.

I agree with you, the only problem being that even in 2016 there are shops that prohibit the usage of STL. The real way out is to eventually change to a language where safety is opt-out and not opt-in, like in C++.

C++ is far safer than C precisely for the reasons listed. The standard is safe by default (it's not opt-in). If you want or need backward compatibility with C, then you can use the more error prone C constructs for that. Otherwise, pure C++ code is safe.

Re: Remote code execution, git, and OS X

#257

Post by kaffeinecoma »

blub wrote: post #103
pjmlp wrote: post #76

Best part: > So, what's the big deal? Crappy C code gets exploited every day, and we upgrade it, and then we're "safe" until the next huge hole that's been there forever is reported. (In the meantime, people party with their private stash of vulnerabilities.)

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.

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

Re: Remote code execution, git, and OS X

#258

Post by raimue »

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.

Isn't this the perfect setting where an attacker will ask you to replace this binary with a custom binary with an additional backdoor?

In the best case the attacker would fake an email that looks like it came from your IT department. Even if you were suspicious, a quick search on the web would confirm that Apple really ships a vulnerable binary. So you believe the email is real. Then you go along and replace the binary with the malicious binary provided in the mail.

The fixed binary needs to be shipped by Apple.

Re: Remote code execution, git, and OS X

#260

Post by pjmlp »

kaffeinecoma wrote: post #257
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.

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

Yet given the actual state of Gtk development, even Linus is using C++ nowadays via Qt.

https://github.com/torvalds/subsurface

Post reply on HN