Hacker News Reader

Comment by reedloden | Hacker News Reader

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.

View on HN

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?

When someone's changed it? Which people do _all the time_.

Mine is changed for Heroku, but it only prepends. I've never seen $PATH be rearranged.

If you prefix it with something already in there then it's effectively rearranged.

You wouldn't do this deliberately, of course, but it happens a lot - people end up with massive PATHs because they blindly prefix when something's gone wrong and it _may_ be the solution.

I was thinking prepending and appending aren't rearranging.

The important part of my above sentence was "with something already there".

If $PATH == 'a:b' and you do `export PATH=b:$PATH, then you've basically rearranged it. It may as well be 'b:a'.

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.

> Not to mention the fact that Homebrew itself uses the system git to install itself.

To me, this is the biggest problem, and it's not just Homebrew. Any source package manager that uses Git will potentially have this problem. With a vulnerable Git on your system, you have to second-guess every build script you ever run that might make use of Git, to make sure it obeys the path you set instead of choosing its own.

Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.

I'm pretty sure git isn't the only thing that is (or will be) vulnerable. Vulnerabilities happen, it's a fact of life. You will have to constantly update your systems no matter which OS you run.

Did you read the linked article?

Yes we did, and the author appears to be posting with the primary intent of spreading anti-Apple sentiments. The opening paragraph begins by insulting startups for being full of Macs. The rest of the post is full of snide comments. They go off on a tangent about System Integrity Protection and the fact that OS X is not Linux ("Apple... keeps you from twiddling", "Well, sorry. You also can't chmod", "I'll just strace it to see what it execs! Oh wait, this isn't Linux."). This could easily have been posted as a simple statement of the CVEs in question and the version of git shipped with latest OS X patch. Not difficult to post facts about a specific issue without insulting an entire operating system - and taking cheap shots at the people that use it.

>> If you rely on machines like this, I am truly sorry. I feel for you.

I don't feel sorry for myself. Odd that a stranger finds it necessary to offer me their sympathy, let alone condescending pity.

The opening paragraph reads:

"Sometimes I think about all of those pictures which show a bunch of people in startups. They have their office space, which might be big, or it might be small, but they tend to have Macs. Lots of Macs. A lot of them also use git to do stuff, perhaps via GitHub, or via some other place entirely. There are lots of one-off repos all over the place."

If you can see a cheap shot in that paragraph, then you are reading things that aren't there. A blog post gives a certain amount of freedom for the author to elaborate on a theme.

You seem a bit defensive. I'm not sure why, but I certainly don't think that Rachel was attacking those who use Macs.

I didn't get a negative vibe from the opening paragraph on its own. If you read the rest of the post, you find a lot of unnecessary negativity regarding the entire Apple ecosystem.

>> I know, I'll just strace it to see what it execs! Oh wait, this isn't Linux. Uh, I'll dtruss it to see what it execs!

Someone who is not in the process of bashing as much as possible would have simply said something like "I'll dtruss it (OS X's equivalent to Linux's strace) to see what it execs". All the exclamation marks and passive aggressive "Uh", "Oh wait", "Well, sorry" phrasing to drive home just how terribly awful the operating system is.

The closing section with the "If you rely on machines like this, I am truly sorry" sealed it. This clear dislike for the ecosystem adds - at least for me - new meaning to the opening paragraph. Typical startup bashing for "trying to be hip and trendy". It's hardware and an operating system. Everyone has a preference for the tools they use; there's no need for passive aggressive hostility.

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 says she's sorry because she was trying to administer a system that a. has vulnerable software she couldn't easily upgrade or even remove, and b. some of the common utilities that she uses to troubleshoot Unix systems just don't work and this makes a competent Unix admin's life harder than it needs to be.

And Rachel, by all accounts, is a very competent - no, scratch that - talented administrator. So she feels the pain of not being able to use commonly available tools and not being able to keep systems as secure as she would like.

If you feel offended by this, then it seems to me you are actively looking to be offended and you have your own agenda.

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 well. In other words, she has not done her homework. Which is fine, if you acknowledge what you don't know. But then the condescending tone would be totally out of place.

The sentiment is there, and it does not help in spreading the message, unless what you really want is to flare up all the emotions. Otherwise, it's not the best course of action.

Fun fact, since we're comparing default system installations, my Ubuntu apparently still has git 2.5.0. I suppose I should find some PPA or something to update it.

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

So what if there's a "sentiment against OS X"?

I've been using Macs for 30 years, including OS X since the 10.0 beta, and the recent changes have left me with a "sentiment against OS X" not unlike the "sentiment against Mac OS" that we had in the 90s when things went pear shaped.

There were people saying we shouldn't speak ill of System 7.5 back then, too.

OS X isn't a systemically marginalized group, it's a product that people are increasingly unhappy with. You may disagree as to why, or with the trade-offs involved, but we're not ignorant as you think we are; SIP likely isn't mentioned because it's obvious.

I just checked my Ubuntu 14.04 and got this as an output:

    $ git --version
    git version 1.9.1

Unacceptable.

14.04 is an LTS release, which is, by definition, stable. 2.8.0 (latest, what I'm running) is vastly different from 1.9.1.

Stability is not the same thing as insecurity. As long as a stable release is supported, the maintainer promises to keep it secure. If your version of git had that vulnerability, Ubuntu would have backported the patches/fixes and made it available to you.

The version number 1.9.1 is a release identifier, not a security status identifier.

That git 2.5.0 on your ubuntu was patched about a month ago (to be exact: March 21, the same day Ubuntu published the advisory).

So fun fact indeed :)

How do I replace /usr/bin/git?

I got the updated brew version downloaded already.

This is in the linked post.

Do this to disable it:

    sudo chmod -x /Applications/Xcode.app/Contents/Developer/usr/bin/git

    chmod: /Applications/Xcode.app/Contents/Developer/usr/bin/git: No such file or directory

I don't have Xcode installed, do I have to install it back to do this?

No, vulnerable git ships with Xcode.

If you don't have Xcode installed then you don't have git.

IIRC, you might have a /usr/bin/git executable but that's not actually git, all it does is shows a GUI that prompts you to install XCode

Thanks.

Yea, /usr/bin/git is still there:

    $ git --version
    $ git version 2.6.4 (Apple Git-63)

But glad to know it won't do anything.

Try:

    % xcrun --find git

> IIRC, you might have a /usr/bin/git executable but that's not actually git, all it does is shows a GUI that prompts you to install XCode

wat

If you do not have Xcode installed but do have the Command Line Tools, you will find the vulnerable git /Library/Developer/CommandLineTools/usr/bin/git

so the command would be:

  sudo chmod -x /Library/Developer/CommandLineTools/usr/bin/git

  sudo cp /Applications/Xcode.app/Contents/Developer/usr/bin/git /somewhere/to/backup/just/in/case
  sudo rm /Applications/Xcode.app/Contents/Developer/usr/bin/git
  sudo ln -s /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git

Is the git binary where the vulnerability is... or is it in one of these:

  $ ls $(git --exec-path)

Sure, as many other software with vulnerability, but with local software like brew (I wrote also [dotsoftware](http://g14n.info/dotsoftware) for the same reasons) you don't have it in your PATH so you are not using it. Using local software has many benefits, among others, a shorter release cycle.

As I said, one config mistake or running a script which uses /usr/bin/git and you're subject to RCE. For example, many GUI programs, such as Atom editor, when not launched from terminal, don't know your PATH.

To be fair, if you're pulling from a compromised repo, you're already in a bad spot. There's a good chance you're going to be making and running the code you cloned, at which point you'll execute whatever arbitrary code anyways. If it's executed from a random script, there's a good chance you're not checking the result either before building.

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 point where you apparently have control of the system already.

In comparison with linux, this vulnerability pales in comparison to the-common-void-that-shall-not-be-talked-about, i. e. the around 400 gems, npms, brews, pips, go(es?), roles and ppas installed & running on a typical dev workstation, no matter if it's Linux or Mac. It's just a matter of time until someone gets his version of leftpad installed on >100,000 workstations & servers before he flips the switch to turn them into cryptolocked hostages.

Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new <x>subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feels like work and at the same time provides those frequent little victories that can turn it into an obsession.

The stars don't really have to be aligned: any script could invoke system git directly.

Yeah, but a script that intentionally invokes /usr/bin/git has already achieved the non-privileged access the git vulnerability could provide. A script that unintentionally invokes (i. e. not to exploit) would then need to be combined with a malicious repository, which may be tricky.

But I don't want to dismiss this vulnerability – it's so easy to fix on Apple's part that they don't have an excuse. There are a few too many neglected corners of their OS where they seriously have to get their act together. But in practical terms, people focus too much on the technologically exciting or Apple/MS/<other divisive entity>-drama provoking vulnerabilities, while there's probably like one or two people working in software who actually verify every hash of every download and audit the source code for every version of every vim plugin they install.

> Yeah, but a script that intentionally invokes /usr/bin/git has already achieved the non-privileged access the git vulnerability could provide.

Or, in Old New Thing terms, "it rather involved being on the other side of this airtight hatchway".

https://blogs.msdn.microsoft.com/oldnewthing/20140529-00/?p=...

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Really? Talking about how homebrew is pretty painless is "Apple fanboyism at its best?" Sure it's another thing to do, but look at any thread about running Linux on a laptop. How many people are like X laptop runs great you just need to add Y kernel parameter to the boot options. Isn't that a "hoop to jump through" too? Or all of the people fighting to keep their Windows install from upgrading to Windows 10. Isn't that a hoop to jump through?

Installing homebrew is a hoop; in an ideal world, your OS vendor would provide a means for installing such packages safely (the Mac App Store would count if Apple cared about it).

This is also a bit weird since getting git installed on OSX in the first place requires it's own hoop: "buying" the free copy of XCode and installing it is required for the command line tools that homebrew relies on.

"buying" the free copy of XCode and installing it is required for the command line tools that homebrew relies on.

No, you can simply download the command line tools that Apple provides free of charge - which the homebrew install script in fact does.

Comparing with the hoops Linux or Windows require you to jump through doesn't make this less of a hoop.

Would much rather have a system that just worked but required a "hoop to jump through" in order to use git, vs the multitudes of hoops you have to jump to in order to get a Linux desktop system functional in a corporate environment.

At home when I'm futzing around I don't mind (and quite enjoy it). But at work I don't have time to diddle my device drivers and OMG the xorg.conf crap I had to deal with in the past that still give me nightmares...

I agree. But that doesn't make this less of a hoop.

It also doesn't mean I'm an Apple "fanboy".

"Everybody uses homebrew" until the new intern or college grad roots your production database.

> Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new <x>subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feels like work and at the same time provides those frequent little victories that can turn it into an obsession.

On the other hand. Once you master this (which is not such a huge intend), you know your system.

Which is a valuable "smart skill" when developing (even web apps). For example, knowing how to use awk and sed instead of having to start a node or ruby instance is a thing that shows a developer actually knows how to run linux and not only "how to run stuff on linux".

You'll also understand $PATH. Which apperently is a thing most MAC users do not understand. Having to start "docker-shell" because they don't know how to extens theyr $PATH is a freaking joke and a workflow killer.

I understand that MAC's are comfortable to use and maintain. But as developers we should embrace leaving the comfort zone and face the real deal. We shouln't be some bunch of kids who need mac because it's comfortable.

Lets grow from little kids that need "mama mac" to take care of our stuff and become grown up's that can handle a system, because they know the system.

Long time Mac user here, I use awk & sed on a regular basis. Been familiar with $PATH since the DOS days and am equally comfortable SSH'd into a CentOS box as I am on the Mac.

I don't think I'm special here, but I'm for sure a subset of Mac users. My point is, seeing a Mac at someone's desk shouldn't make you assume they're idiots, just like you don't assume someone's a l33t-ub3r-h4ck3r if they're walking around with a lenovo.

My point was exactly that 'knowing the system' isn't useful for a webdev when the system is the graphics subsystem. I'll gladly learn it when it becomes relevant - indeed I spend half the day in a console and can configure a linux cluster like the best of 'em. When there's time left, I prefer to choose the subject of my studies myself. Right now, I prefer to dabble in AI to triaging obscure linux bugs.

I don't get the idea that Mac users are attracted to the system because they cannot handle windows or linux – they just don't want to. Isn't it kinda obvious that the stereotype can't survive when you see >3/4 of all google employees using Macs?

But hey, maybe I should write an App that randomly introduces bugs into my stack to finally learn a bit more about it. And when my car breaks down, I'll be thankful for the learning experience.

While I agree with canonical being a pain the answer to that is simple just don't user Ubuntu.

I prefer Mint if I need a Ubuntu fork that's quite stable and has most things already configured generally used at work and as my personal desktop I use Arch mostly because compatibility with the hardware required the latest kernel at the time.

I like playing with the latest features and not having to install the OS every other year because some major update from canonical broke everything.

As far as fiddling with the kernel I never had to do anything like that to get the things you mentioned working the most I had to do is install some software and configure it correctly.

In the years I've been running Arch on the desktop it only breaks on average about 2 or 3 times a year which is quite decent considering it's a rolling release and I haven't had any major issues with mint since I started using it about 2-3 years ago.

I crashed the window manager a few times but that's about it in comparison Unity used to crash on me constantly and the entire experience of using plain Ubuntu as a desktop was awful so I understand why you would be against using it if that is all you knew of Linux as a desktop.

» Everyone uses homebrew

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

Why not replace XCode with brew version entirely:

  sudo cp /Applications/Xcode.app/Contents/Developer/usr/bin/git /somewhere/to/backup/just/in/case
  sudo rm /Applications/Xcode.app/Contents/Developer/usr/bin/git
  sudo ln -s /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git

I wonder what would happen if you did this and then tried to uninstall Xcode

or just

   sudo cp /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git

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.

Except that git is used specifically by users who are downloading and compiling software.

And at this point the first instruction for any OSX user who downloads and compiles anything is "Install Homebrew"

Except for those who have used it and refuse to use it again.

There are prebuilt binaries of up to date git distributed via .pkg. The yeast infection that is Homebrew is unnecessary

That's kind've harsh. What's the issue? Homebrew was about the best option that's existed on OSX for a few years now I thought...

The dependency management is a joke, compile-by-default means it's slow as hell.

I look forward to your release of something better

So your world view is that only those with a competing solution are allowed to identify issues in something?

If you're going to be that snarky and nonconstructive about it, you're going to get snarky and nonconstructive comments back. Or at the very least, you're not going to inspire any thoughtful and interesting observations from anyone.

Most commonly-used dependencies are bottled (precompiled) these days.

Except the dependency management solution is terrible, unless you want to compile everything yourself.

For example: https://github.com/Homebrew/legacy-homebrew/issues/35995

Personally I use MacPorts.

The Homebrew installation process uses the system git.

Yep, since Homebrew requires the Xcode Developer Tools to be installed (which of course includes the outdated Git).

Yes, but if Homebrew is malicious, you'd have more problems than a specially-crafted repository that exploits a git vulnerability. You are installing something that has all user access rights.

Can you inunstall XCode again once you have installed a compiler, toolchain, and git via Homebrew?

You can just install the command line tools without xcode. From those tools, most can be replaced with their homebrew versions so you only need them for bootstrapping. But if you want to do hardware- or OS X related development, you will need to keep the tools around. CUDA, for example, needs clang et. all.

They don't take much space, though, and the toolchain is treated a bit better by Apple than utilities like git, vim etc.

I don't know about homebrew, but macports has clang and other toolchain stuff, so I think it might be possible to uninstall Xcode after installing all necessary tools through macports?

You _could_ get recent git by some other means prior to installing homebrew. Anything short of compiling from source wouldn't require ever installing XCLT.

Xcode is distributed and released over the AppStore and can be rev-ed at any frequency, independently of the OS; Apple's update model not does prevent an expedient update.

Perhaps the main cause for delay is the associated QA efforts to make sure that other components in the stack which depend on git don't break in the case that git has broken binary compatibility (i.e. changed its public interface).

If things are tied up in QA, that is a problem in and of itself, because relevance is an important quality for a security bugfix to have. If my system is compromised today, it will do me little good that the bugfix Apple ships next month was tested extensively for compatibility with Xcode.

It is too late for there to be an expedient update from Apple. The vulnerability was disclosed to oss-security over a month ago, on March 15[0]. SUSE had a patch out the next day[1]. By March 24, Debian, Ubuntu, Red Hat, CentOS and Oracle had all issued fixes.[2]

[0]: http://www.openwall.com/lists/oss-security/2016/03/15/5

[1]: http://lists.opensuse.org/opensuse-security-announce/2016-03...

[2]: http://www.securitytracker.com/id/1035290

I should clarify that I don't know why an update hasn't been pushed. I was only speculating why it might be taking so long.

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

I'd argue that the the OS X user who use git are a subset of Mac OS X users. In fact, a similar subset to that which uses Homebrew...

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.

Reply on news.ycombinator.com