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

Re: Remote code execution, git, and OS X

#271

Post by EGreg » Mon, Apr 18, 2016, 3:08 PM UTC

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.

Linus would chew you out for saying that son.

http://harmful.cat-v.org/software/c++/linus

Re: Remote code execution, git, and OS X

#272

Post by raimue » Mon, Apr 18, 2016, 3:20 PM UTC

chris_wot wrote: post #269

raimue wrote: post #255

Earlier quoted context omitted.

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.

And if you do have them installed? What does it do then - invoke git?

Yes. It uses the tools from the location currently selected as the active developer directory (via xcode-select).

Re: Remote code execution, git, and OS X

#273

Post by geofft » Mon, Apr 18, 2016, 3:20 PM UTC

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

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

Re: Remote code execution, git, and OS X

#274

Post by joushou » Mon, Apr 18, 2016, 3:31 PM UTC

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.

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 to the issue with git.

Re: Remote code execution, git, and OS X

#275

Post by ptc » Mon, Apr 18, 2016, 3:32 PM UTC

blub wrote: post #261

falcolas wrote: post #252

Earlier quoted context omitted.

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

No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.

@falcolas -- I think you mean machine code not bytecode. And w.r.t. Mercurial afaik the project's hot paths are all written in Cython extensions, and there's ongoing work to improve the Python part by working with the PyPy folks. So, there's definite technical advantages in using Python for greater developer productivity, but there's also a cost.

Re: Remote code execution, git, and OS X

#276

Post by smitherfield » Mon, Apr 18, 2016, 3:35 PM UTC

claudius wrote: post #199

joushou wrote: post #149

Earlier quoted context omitted.

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.

If you can change the name_path struct to a standard STL data structure (std::vector might work just fine), you can easily rewrite the function such that all memory allocation and all exploitable memory access is delegated to STL containers. If your STL std::string has a buffer overflow issue, you’re of course still in trouble, but the same is true if there are bugs in the STL/implementation of Go/Rust/Python/Java/Ha…

I think you have a typo in your first code block.

p += (dir + "/");

Re: Remote code execution, git, and OS X

#277

Post by satysin » Mon, Apr 18, 2016, 3:37 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…

Does OS X have something like update-alternatives on Debian?

Re: Remote code execution, git, and OS X

#278

Post by pjmlp » Mon, Apr 18, 2016, 3:40 PM UTC

blub wrote: post #261

falcolas wrote: post #252

Earlier quoted context omitted.

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

No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.

A command line tool like Git can be written in any programming language that has implementations capable of generating native code.

Even then, Mercurial is implemented in Python and quite usable

Re: Remote code execution, git, and OS X

#279

Post by claudius » Mon, Apr 18, 2016, 3:43 PM UTC

smitherfield wrote: post #276

claudius wrote: post #199

Earlier quoted context omitted.

If you can change the name_path struct to a standard STL data structure (std::vector might work just fine), you can easily rewrite the function such that all memory allocation and all exploitable memory access is delegated to STL containers. If your STL std::string has a buffer overflow issue, you’re of course still in trouble, but the same is true if there are bugs in the STL/implementation of Go/Rust/Python/Java/Ha…

I think you have a typo in your first code block. p += ( dir + "/");

Oh, yes, sorry and now it’s too late to fix (both that and the horrible formatting). Though I suppose it would have been a compile-time error, so at least it shouldn’t be exploitable :')

Re: Remote code execution, git, and OS X

#280

Post by TazeTSchnitzel » Mon, Apr 18, 2016, 3:45 PM UTC

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

AIUI /usr/bin/git, and various other utilities, are tiny wrapper programs which will either 1) prompt you to install the Xcode Command Line Tools if they're not installed, or 2) redirect to the actual binary in the Xcode Command Line Tools if they are installed. This means that if you don't have them installed, instead of an error saying that bash can't find git, you get a nice graphical prompt telling you where to get it.

It can't be removed because it's a file that comes with OS X and is therefore covered by System Integrity Protection, which prevents you from deleting or tampering with system components, even as root.