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

231–240 of 385 posts

Re: Remote code execution, git, and OS X

#231

Post by developer2 »

pitkali wrote: post #217
chris_wot wrote: post #179

Earlier quoted context omitted.

All that first sentence points out is that Rachel was more familiar with Linux than OS X, and mistakenly thought that strace would be on the system, and then reverted to using dtruss. She's just showing her process for trying to troubleshoot Unix processes to see what is going on under the hood, in a conversational tone. As for the "If you rely on machines like this, I am truly sorry" - I don't really blame her. She…

The sentiment against OS X might not show that strong, but it is clearly there. She doesn't even mention that what protects /usr/bin is System Integrity Protection, or that it can be disabled. The very idea that people might not be using system git is not even mentioned. All in all, it really feels as if it was written from the perspective of someone that does not usually work with OS X and does not know the system w…

That point about Linux distros such as Ubuntu is something I was looking to mention, but I'm not 100% sure I have my facts straight. That said, here's what I believe is the case. ;)

The repositories can be similar to OS X in terms of providing really outdated versions of many packages. The same day Ubuntu releases a new version of the OS, packages can already be over a year out of date from the releases made by the software's developer.

The distros won't update the official repositories with newer versions of software once the version is pinned during the testing phase of the OS, due to the extensive amount of quality assurance that goes into ensuring system-wide stability. Their reasons are justified, but the end result still means you're typically not running the best and latest of anything.

Things are a little more difficult to understand with versioning in Linux. You may have git 2.5.0, but if you're on a release of the distro for which support is still ongoing, those CVEs are probably fixed due to backported security patches that don't bump the software's version number. In this manner, official repositories on Linux distros usually give you outdated software in terms of new features, but keep you entirely up to date in terms of security.

Information for Ubuntu in particular: https://wiki.ubuntu.com/StableReleaseUpdates

And then... TIL about the backports repository: https://help.ubuntu.com/community/UbuntuBackports

Re: Remote code execution, git, and OS X

#232

Post by chris_wot »

acdha wrote: post #224
chris_wot wrote: post #213

Earlier quoted context omitted.

Yeah, it's looking increasingly that way. I'd still love to know their thinking behind put git into a directory that SIP makes deliberately hard to update! I mean, git is additional software and not even part of their base operating system, my understanding about SIP was that it was meant to prevent people from tampering with the underlying system software and installing rootkits. git (and ssh for that matter) aren't…

I think the idea is that they protect everything which they ship, so you can add other things but not replace Apple-provided components. From a sysadmin's perspective this makes a lot of sense: beyond malware, I've seen security and stability problems caused by installers from large companies, developers cowboying up with “sudo make install", etc. but it definitely puts the onus on Apple to ship updates promptly.

That's the issue I have - not so much an immutable part of the filesystem (though I find that bizarre and flawed), but that Apple don't do enough updates fast enough.

I basically think that if Apple want to lock down their ecosystem and prevent folks from updating their own software, then they have a duty to provide timely updates that address security bugs. Currently they don't seem to be doing that.

Re: Remote code execution, git, and OS X

#233

Post by ascagnel_ »

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

Yes, indeed, but Mac OS X users who use Homebrew are a subset of all Mac OS X users. The problem is in the default software. Apple's update model isn't good for this type of software, so the fact that it is possible for a user to install secure versions from Homebrew (or compile their own) doesn't matter.

Git is not part of the default configuration on OS X. You need to install XCode first.

Re: Remote code execution, git, and OS X

#234

Post by yxhuvud »

chris_wot wrote: post #95
benley wrote: post #89

Earlier quoted context omitted.

So ... has anybody actually checked to see if Apple has patched the vulnerability in git without bumping the version number, like pretty much every linux distribution does for their stable releases?

You're joking, right? When I use software and I look at the version number, I like to know that it is what it says it is. If they are going to patch the vulnerability, then I want to know if they have done so. Besides which, this whole question is missing the point somewhat. There is no easy way of updating the system supplied tools like git, even if you wanted to. The latest version of git is v2.8, and I think it wo…

Welcome to the wonderful world of distros. The big ones backport stuff and lie about version numbering, and somehow that is a feature.

Re: Remote code execution, git, and OS X

#235

Post by chris_wot »

zamalek wrote: post #212
chris_wot wrote: post #200

Earlier quoted context omitted.

Windows has UAC that does something similar, and the Windows\System32 directory can't be written to by an ordinary user. The malware I see doesn't install in this directory, but in Program Files - and they can't really lock this down. The way that folks get themselves into a mess and get malware installed are largely via programs with network access. Locking down the /usr directory isn't going to prevent this sort of…

> the Windows\System32 directory can't be written to by an ordinary user. You need to be able take claim ownership from TrustedInstaller, so administrators only: yes (you'll need to acquire a UAC token, but the GUI prompts you automatically). You'll also need to turn off installation integrity to prevent Windows from replacing the file. All documented. It isn't obfuscated in any way whatsoever and I figured it out fi…

Yep, I know. What you are basically saying is that you need to turn off some settings and security mechanisms to bypass the integrity of the system. Which is precisely what most folks are doing on OS X - except they have to reboot their system, which I personally find insane. But given this, I don't see the point you are making.

Isn't this security through obfuscation precisely what Apple are doing right now?

Re: Remote code execution, git, and OS X

#236

Post by cs702 »

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 thing for decades.

Re: Remote code execution, git, and OS X

#237

Post by chris_wot »

amake wrote: post #218
chris_wot wrote: post #211

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. There is nothing hugely special about their tools - every other app apparently has to install into a different location as best practice, so I don't understand why Apple don't follow their own guidelines!

> 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 includes this directory already.

You state that plenty of comments explain where the Xcode git actually is, but that misses the point entirely. Why is it linked into /usr/bin?

Re: Remote code execution, git, and OS X

#238

Post by athenot »

matt4077 wrote: post #140
Fuxy wrote: post #110

Earlier quoted context omitted.

It's times like this that prove I made the right choice sticking to Linux. There's nothing I hate more than the inability to fix things that are broken on my system or the fact that I would have to jump trough a lot of unnecessary hoops to do it. The few small advantages are just not worth it in the end for me.

There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…

» Everyone uses homebrew

Some of us prefer MacPorts. (Not that this changes anything to the argument you're making.)

Re: Remote code execution, git, and OS X

#239

Post by chris_wot »

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…

Watch out! I made that point and I got flayed alive for it.

Re: Remote code execution, git, and OS X

#240

Post by joushou »

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 machine without the system integrity features. You can boot back to normal after the modification.

It is inconvenient that these dev tools are not updated frequently (bash, zsh, and many other command line tools are terribly out of date), but it is not terribly difficult to install a fresh version in parallel.

Post reply on HN