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.
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.
> 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
Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacceptable. I want full root access to my development machine, not a dumbed down version of "root" that doesn't let me mess with certain things. This is one of the key reasons why I will not use a Mac as a development machine.
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.
> 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.
People like Richard Stallman have been warning about this sort of thing for decades.
Any GNU/GNU, GNU/Linux, or GNU/anything system could do exactly the same thing without violating any terms of the GPL. Requiring a reboot into a special "I know I'm messing with the system" mode in order to mess with important core binaries is not an unreasonable way protect the user from malware, and does not in any way abridge any of the core freedoms Stallman promotes.
(and yes, you literally can run a command and reboot your Mac to be able to make changes to the protected stuff, and the process to do this is well-documented)
Router companies have the exact same problem. They package software that will probably be out of date by the time it ships to the customer and there is rarely a mechanism to update it except "buy a new one."
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.
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.
> 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.
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.
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.
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.
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.
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.
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).
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.
> 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.
If you're going to rewrite in any case surely it's worth going to Rust (or Ada, or another language that simply doesn't have the myriad unsafe possibilities that C++ does).
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.
(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.)
Rewriting in any language won't help with this one unless the language has builtin integer overflow checking.
The solution here is actually quite trivial: just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.
You'll need to put an updated subprocess.py in your Python path, editing the one provided by OS X is prevented by the System Integrity Protection... ¯\_(ツ)_/¯
Are you not using virtualenv? I always use virtual environments as much as possible to avoid being locked in on an older version (for example Python in this case).
For those of us who have only installed the Command Line Tools, you will find the Apple supplied git at /Library/Developer/CommandLineTools/usr/bin/git
so the command to disable this vulnerable version is:
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!
There's a security feature on El Capitan that essentially makes certain files and directories on your host system immutable. Presumably it's some set of filesystem flags, but not even root can change them. There's a magic nvram command you can use to disable the security feature (which if you're a developer you'll have to do eventually since you can't touch anything in /lib or /usr/bin or /bin). The command in question is:
nvram boot-args="rootless=0"
It seems to me that this is related to that feature. Although, I don't get why it looks like the two files are hardlinked but you can modify one -- maybe it's because this magic was only applied to the /usr/bin directory (and thus a hardlink to the file can still be modified). That's a bit dumb IMO, but I can imagine this being a bug in the OS X kernel.
Unfortunately, I'm not sure how to actually create such files (maybe if I disable System Integrity Protection, create a file and hardlink to it and then re-enable SIP). If I figure it out on my friends' MacBook I'll comment below.
EDIT: Okay, so it might not be what I said earlier. If I do something along the lines of:
1. Disable SIP (csrutil disable in recovery).
2. Create a file in /usr/bin and hardlink it to a non-SIP location (like $HOME).
3. Re-enable SIP (csrutil enable).
4. Try to change the permissions on either of the hardlinks.
It will fail. So presumably SIP correctly propagates permissions to all dentries. I'm not sure what's happening then.
> It will fail. So presumably SIP correctly propagates permissions to all dentries. I'm not sure what's happening then.
/usr/bin/git is a small wrapper that invokes the actual git from either the command line developer tools or from xcode (whatever you have selected with `xcode-select`)
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.
I have a macbook with command line tools installed and I have homebrew installed. I think I installed Python on brew, but which git tells me I'm using /usr/bin/git for that.
Is there a list somewhere of dangerously old software Apple have shipped to me that I should reinstall with brew immediately?
Starting in OS X El Capitan there's a framework to protect sensitive system files which disallows even root from modifying them. The only way to make changes is to (as root) disable that framework, then reboot, make the changes, re-enable and reboot again.
On my Chromebook, a linux system, the root filesystem is mounted read only. To modify a file in /usr/bin I would need to activate developer mode then remount it rw. I expect this is probably something similar and done for similar reasons.
The big market isn't developers but end users who have no idea how to protect themselves from real threats and who don't use git. And for them sandboxing, signed executables, verified boots and other measures make life far better.
If you are a developer using a Mac you most likely use brew or some sort of vm/container system anyway.
So what Apple have designed is a "system integrity protection" system that actively prevents you from mitigating security issues.
Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".
Readit News
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.
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.
Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacceptable. I want full root access to my development machine, not a dumbed down version of "root" that doesn't let me mess with certain things. This is one of the key reasons why I will not use a Mac as a development 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.
Any GNU/GNU, GNU/Linux, or GNU/anything system could do exactly the same thing without violating any terms of the GPL. Requiring a reboot into a special "I know I'm messing with the system" mode in order to mess with important core binaries is not an unreasonable way protect the user from malware, and does not in any way abridge any of the core freedoms Stallman promotes.
(and yes, you literally can run a command and reboot your Mac to be able to make changes to the protected stuff, and the process to do this is well-documented)
Sure, Apple should ship a fix, but there are ways around it for now.
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.
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.
I got the updated brew version downloaded already.
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).
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.
> 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.)
A lot of Linux C utilities would benefit from such a treatment.
http://harmful.cat-v.org/software/c++/linus
(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.)
The solution here is actually quite trivial: just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.
You'll need to put an updated subprocess.py in your Python path, editing the one provided by OS X is prevented by the System Integrity Protection... ¯\_(ツ)_/¯
For those of us who have only installed the Command Line Tools, you will find the Apple supplied git at /Library/Developer/CommandLineTools/usr/bin/git
so the command to disable this vulnerable version is:
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!
Deleted Comment
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.
Unfortunately, I'm not sure how to actually create such files (maybe if I disable System Integrity Protection, create a file and hardlink to it and then re-enable SIP). If I figure it out on my friends' MacBook I'll comment below.
EDIT: Okay, so it might not be what I said earlier. If I do something along the lines of:
1. Disable SIP (csrutil disable in recovery).
2. Create a file in /usr/bin and hardlink it to a non-SIP location (like $HOME).
3. Re-enable SIP (csrutil enable).
4. Try to change the permissions on either of the hardlinks.
It will fail. So presumably SIP correctly propagates permissions to all dentries. I'm not sure what's happening then.
/usr/bin/git is a small wrapper that invokes the actual git from either the command line developer tools or from xcode (whatever you have selected with `xcode-select`)
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.
Deleted Comment
Is there a list somewhere of dangerously old software Apple have shipped to me that I should reinstall with brew immediately?
Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths.
Not even root is enough to do it.
Can someone explain it to me?
The big market isn't developers but end users who have no idea how to protect themselves from real threats and who don't use git. And for them sandboxing, signed executables, verified boots and other measures make life far better.
If you are a developer using a Mac you most likely use brew or some sort of vm/container system anyway.
Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".
https://www.syscan360.org/en/speakers/