So OS X El Capitan sucks. As evidenced by removing from (advanced) users the control necessary to secure their systems.
Is it feasible for Mac users to downgrade to older OS X?
Remote code execution, git, and OS X
151–160 of 385 posts
Re: Remote code execution, git, and OS X
#152Earlier quoted context omitted.
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…
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/-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.
Re: Remote code execution, git, and OS X
#153If you execute csrutil disable && reboot, you will be able to disable System Integrity protection and do what you want including fixing /usr/bin/git. What is the problem?
The problem is that System Integrity protection was put in place for my benefit and marketed to me as a feature that had been "designed to help prevent potentially malicious software from modifying protected files and folders on [my] Mac", and now that I have it and paid money for it (or the Apple hardware it runs on), I find out that it is making me less secure by preventing me from removing a software component whi…
Disable it, reboot, fix the problem, reboot again with it enabled. Big f'ing deal.
I'm far from a fan of Apple's protectionism, and yet this doesn't seem like anything to be up in arms about.
Re: Remote code execution, git, and OS X
#154Earlier quoted context omitted.
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…
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.
Re: Remote code execution, git, and OS X
#155Best part: > 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).
Re: Remote code execution, git, and OS X
#156So OS X El Capitan sucks. As evidenced by removing from (advanced) users the control necessary to secure their systems. Is it feasible for Mac users to downgrade to older OS X?
"Advanced" users would know how to turn off System Integrity Protection if they wanted.
It makes absolutely no sense to downgrade OS X versions to avoid SIP. It's quicker to just disable SIP than to downgrade the OS.
Re: Remote code execution, git, and OS X
#157Earlier quoted context omitted.
The problem is that System Integrity protection was put in place for my benefit and marketed to me as a feature that had been "designed to help prevent potentially malicious software from modifying protected files and folders on [my] Mac", and now that I have it and paid money for it (or the Apple hardware it runs on), I find out that it is making me less secure by preventing me from removing a software component whi…
Disable it, reboot, fix the problem, reboot again with it enabled. Big f'ing deal. I'm far from a fan of Apple's protectionism, and yet this doesn't seem like anything to be up in arms about.
Sometimes I think that Apple are increasingly trying to lock down OS X to prevent anything from being installed outside of its own walled garden.
The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature that is preventing the security vulnerability from being fixed.
In other words - by making system files immutable even to root, it's not exactly making the system any more secure.
Re: Remote code execution, git, and OS X
#158Earlier quoted context omitted.
No, I'm just bored of faux-outrage and agenda pushing. If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it. [edited to add] It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?
You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway. https://github.com/gdbinit/rootfool Incidentally, calm down a bit - you sound pretty outraged yourself! You m…
> Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software.
I can imagine git might be necessary for applying some updates (on FreeBSD svn is a critical part of the base system, because one way to update is by svn updating the source and rebuilding).
Re: Remote code execution, git, and OS X
#159I Clicked on the link expecting to read about a vulnerability. This is actually about blasting OS X for not having updated versions of software. Software updates are super important of course, and apple should be better at pushing the latest software updates, but I wish the title reflected that.
I disagree that it is clickbait. There is a schema people use for announcing security vulnerabilities (" in version through "), and the RCE issue was recent, so to those familiar it was clear that it was exposition rather than disclosure. For those unfamiliar, now you know
Rachel is a widely known and reputable author. I doubt she aimed it as clickbait.
Re: Remote code execution, git, and OS X
#160Best part: > 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.
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.