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

301–310 of 385 posts

Re: Remote code execution, git, and OS X

#301

Post by jordigh »

fauigerzigerk wrote: post #297
jordigh wrote: post #284

Earlier quoted context omitted.

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.

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

Bugs are a matter of perspective. If alleged bugfixes actually make you modify your currently working setup, then I don't consider that much of an actual bugfix, just something that makes me do work for no real benefit:

http://stevelosh.com/blog/2012/04/volatile-software/

I like Debian stable. Two years is an entirely reasonable amount of time to be able to have most software in my OS immutable except for security fixes. For the tiny amount of software for which I may want the bleeding edge, there are language-specific "package" "managers" (lol npm) or I can just backport the software myself.

Re: Remote code execution, git, and OS X

#302

Post by smitherfield »

claudius wrote: post #279
smitherfield wrote: post #276

Earlier quoted context omitted.

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 :')

No worries! :)

Re: Remote code execution, git, and OS X

#303

Post by fishywang »

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…

Imagine that you are a corp IT and managing a fleet of developers with Macs. You can push a newer version of git to them, and you can even change their default PATH so that the version of git you pushed are before the git comes with Apple. But you still cannot remove the one comes with Apple, and you cannot prevent it from being used.

Re: Remote code execution, git, and OS X

#304

Post by raimue »

mikegerwitz wrote: post #293

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.

What makes you think GPLv3 would forbid something like Apple's SIP? Which clause are you referring to?

Re: Remote code execution, git, and OS X

#305

Post by cosmotron »

tobylane wrote: post #150
atdt wrote: post #11

Earlier quoted context omitted.

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.

When would the order of $PATH vary?

To give a concrete example, OS X 10.9 (Mavericks) has `/usr/bin` listed before `/usr/local/bin` in `/etc/paths`. This was flipped in 10.10 and up.

Re: Remote code execution, git, and OS X

#306

Post by zaphar »

falcolas wrote: post #252
zaphar wrote: post #247

Earlier quoted context omitted.

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

I was not implying it did. I was responding to the C++ suggestion specifically.

Re: Remote code execution, git, and OS X

#308

Post by peff »

Minor nit: this post mentions v2.7.1 as safe from these vulnerabilities, but it is not. v2.7.4 is the first safe version (this mistake was inherited from the bogus oss-security post that is linked in the article).

Re: Remote code execution, git, and OS X

#309

Post by mikegerwitz »

raimue wrote: post #304
mikegerwitz wrote: post #293

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.

What makes you think GPLv3 would forbid something like Apple's SIP? Which clause are you referring to?

Please correct me if I'm misunderstanding, as I'm not familiar with the system.

GPLv3[0] introduced protections again Tivoization:

--

"“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM)."

--

[0]: https://www.gnu.org/licenses/gpl.html

You can install your own version of Git, yes. But Apple, as a distributor, cannot prevent you from installing a replacement for the software that it distributes. If, wherever they provide the source code to Git, they do provide a method to replace the currently install software, then that wouldn't be a problem.

Now, I did find this:

https://opensource.apple.com/source/Git/Git-17/Makefile

Which does indeed have an install target.

Can anyone tell me if this replaces the original program, or at least provides information necessary to remove it?

Re: Remote code execution, git, and OS X

#310

Post by fauigerzigerk »

jordigh wrote: post #301
fauigerzigerk wrote: post #297

Earlier quoted context omitted.

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.

> I understand that, but it means that debian inevitably distributes buggy software in a supposedly 'stable' distribution. Bugs are a matter of perspective. If alleged bugfixes actually make you modify your currently working setup, then I don't consider that much of an actual bugfix, just something that makes me do work for no real benefit: http://stevelosh.com/blog/2012/04/volatile-software/ I like Debian stable. Tw…

Many people are unhappy about living with old bugs or missing features for years, even if you are not. And as a result we get a proliferation of many different update mechanisms on the same system. Some of them interactive and unscriptable. Some less than secure. This is not an ideal situation by any stretch.

It's not a huge problem either as long as Linux is used almost exclusively by professionals and mostly on servers.

Post reply on HN