As, yeah, stupid applications is hard to guard against Stupid applications aren't the ones to worry about. As an attacker, if I know that every mac has a git vulnerability, and all I have to do is to hard code a path to it, then I'm going to do that.
This seems to be a recurring topic: If you're writing an application, why bother hardcoding a path to a git version with a known RCE? You're already running on the machine. Hell, if you want to hide your fault, bundle a random tool or lib that you know have an issue and exploit that. It'll be much more stable than relying on a local binary.
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?
Why doesn't Apple use Linux !? And why doesn't people install Linux on their Apple machines!?
because Linux is GPL because driver support
It seems Apple doesn't care much about it's software. They would probably save billions. And we would probably see some nice contributions from Apple. And it would create a lot of goodwill for them.
> lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer As an ordinary user, this can be perfectly reasonable. I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user. Developers need a level of control over their machines and configurations that ordinar…
> I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user. I was speaking as a developer, too. What kinds of things do you count as needing "that level of control"? The things installed in my home directory include my text editor, clang and gcc, installations of Go, Node, and multiple versions of Python, etc.
> What kinds of things do you count as needing "that level of control"?
As a developer, I want complete control over everything on my development machine. It's not enough to just control my home directory. I want to be able to control exactly what system services are running, so that I can test services in the same environment they'll be running in in production. I want to be able to control exactly what versions of things are installed as system binaries, not just in my home directory, so that I can be sure there is no possibility of a version being there that I don't want there. I want to be able to control exactly what device drivers and kernel modules are running. And so on.
Perhaps not all developers take this attitude; it probably depends on what kinds of things you are developing.
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 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).
Wasn't sure if that's were you were going. So, who in this day and age, forbids the use of the standard library? That seems pretty bizarre. What would be the motivation behind such a policy?
The arguments against it are usually that it is too bloated, too slow, makes use of templates and exceptions. So any place that is against templates and exceptions, usually rules out the standard library on those arguments. Then you have the software houses, whose C++ code is actually C with a C++ compiler that use the bloat and slow arguments against the library. I don't remember them by heart, but there were a coup…
Whenever someone complains to me that the standard library is slow or "bloated" (whatever that means), I ask if they've ever profiled their code vs. the standard library version. 9 times out of 10 they have not, and are operating out of mythology rather than measurement.
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.
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…
I agree. But that doesn't make this less of a hoop.
Yes. (a) You are not a typical user; (b) disabling SIP takes five minutes plus whatever productivity loss is caused by rebooting; (c) it isn't actually necessary to disable SIP to make git inaccessible, as described later in the post; (d) even if it were, you would get most of the protection by just installing your own git in a different location and changing PATH; and (e) the vulnerability in question is incredibly…
It is not necessary to run anything except "git clone". An attacker can construct a repository such that merely attempting to clone it would execute arbitrary code. This is why the vulnerability was given a CVSS base severity score of 9.8 (out of a possible 10).
I know, but Git is mostly used for software development, and people mostly clone unfamiliar Git repositories with the intent to build and/or run the included software, mostly without performing a full manual inspection of the code beforehand; even if they only build, most build systems allow specifying arbitrary commands to run. Thus, in the common case, exploiting the vulnerability gives the author of a malicious repository only the power they would have gotten shortly afterward anyway. Of course, there are exceptions to all of those "most"s (especially the first one, I think), but my conclusion is still that the overall danger of that particular vulnerability is pretty minor.