> Apple indicated that this issue required a substantial amount of changes on their side, and that they will not back port the fix to 10.9.x and older.
What? So all OS X boxes are simply broken, privileges-wise, if they're not on 10.10?
Apple's model customer is one who upgrades often. If you want solid support for old products, stick with Microsoft, and accept that their products can be clunkier because of deliberate choices to maintain backwards-compatibility.
Title is a little generous about "hidden", the exploit revolves around API & Framework used to power the parts of the control panel, and its authorization scheme being broken.
I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing.
Code signing is not interesting. If normal people can get their code signed then so can the attacker and if they can't then it locks you out of your own computer. The only thing code signing is really good for is to verify that an update to a program the machine's owner installed was signed by the same author as the original program, and unfortunately it's rarely implemented that way.
But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing.
The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.
With physical access, one has been able to create admin accounts for as long as I can remember.
- Start up the Mac whilst holding down ⌘-S. This boots the Mac into Single-User Mode and provides a method of interacting with OS X via the command-line, with full root privileges.
- Then check the filesystem to ensure there are no problems: "/sbin/fsck -fy"
- Then mount the filesystem for it to be accessible: "/sbin/mount -uw /"
- Now remove this file so OS X will re-run Setup Assistant: "rm /var/db/.AppleSetupDone"
Now just restart, and enjoy the cool introduction animation as you create your admin account.
I really hate all the desktop IPC bullshit. IPC frameworks are pure fucking evil. COM, D-Bus, XPC, everything SUCKS.
If you want completely separate programs on one machine to talk, use UNIX domain sockets (with something like ZeroMQ or HTTP), FIFOs (named pipes), anything that you can chmod and chown, not a daemon that reinvents access control, badly.
While this is a significant vulnerability, I don't think the article is correct when it calls it a 'backdoor.' The term backdoor typically implies something that was intentionally left to allow illicit access, and while this is a significant bug, I don't see anything to indicate that's the case here.
OT but I have to say that the amount of Apple apologists in these comments is mind blowing. HN reader of all people should be the ones urging Apple to issue a fix for a very serious bug such as this one. Yet many comments here are saying that people should just upgrade while it might solve the problem for some, there are ones who can't upgrade machines at will.
Yeah, this is scandalous. I've heard enough things about Yosemite bugs that I held off upgrading, especially as I want to avoid software compatibility issues.
I hate Apple's new yearly release cycle. There's not enough time to stabilize and improve OS's.
This update just rolled out, but it indicates the admin fixes are only for Yosemite:
>Yet many comments here are saying that people should just upgrade while it might solve the problem for some, there are ones who can't upgrade machines at will.
It's dumbfounding how people here are simply shrugging this off and posting "So what? Just upgrade. Simples" type comments. This isn't acceptable. I know many people in creative industries alone who can't just upgrade immediately any time something comes out as they've to wait for their products to support the newer version. Similarly there are many who are using Macs in work whose corporate policies won't let them simply update immediately.
Then there's many who don't immediately upgrade versions as a point while bugs/other issues in that new version are found and resolved.
Hey, at least there weren't any of the 'Well, I don't care if anyone sees all my boring details anyway' variety. At least people are beginning to understand the most basic implications of loss of privacy.
I have to agree. I have an older macbook that if I upgrade to another above Snow Leopard, it runs pretty slow. But I do understand that support for older devices has to stop at some point.
Smells like an oversight to me. Some new developer got assigned to implement or tweak the SSH enabling switch (or whatever), and this was their solution, which never got reviewed.
As someone who loathes Yosemite, I was hoping to find another fix for this. However, the exploit code when run in my console already returns "You need an administrator password" prompt. Huh? I'm running 10.9.5.
Run the python script at the end of the article as non admin/non root user. The script allows you to create a copy of a binary in say /usr/bin with "set user ID execution" bit set and owned by root! This should not be possible without root privileges.
This is pretty bad, and trivially exploitable. Basically anyone that has non-root access to your computer can trivially become root and take over the system.
When Apple refuses to fix something that's good the public's interest, the best way to get Apple's attention is to make this a rootpipe gate by sending tips to all Apple focused media outlets like AppleInsider Macrumors etc. Talk about the power of press.
Null pointer dereferences do crash in Objective-C. Sending messages to nil is generally not nonsense in Objective-C, though. It has well-defined semantics and is useful in many cases. It isn't a "Don't crash when faced with nonsense" policy. I'm not sure the benefits are enough to justify its propensity to trip people up, but it's not like it's just some kind of crash prevention.
This is not considered "nonsense" in Objective-C is part of the issue: having "no receiver" do nothing is well defined behavior that has a long tradition at least back to Smalltalk. People use this to write shorter code, on purpose, causing an effect similar to Haskell's Maybe monad.
(Note: I, myself, do not ever rely on this functionality, and even disagree with it, but the context in which people use it is important to understand when judging it; and with that context, I consider my own objections mostly due to my biases and not something that I would argue is "correct".)
To be fair, calling a virtual method on a null receiver is undefined behavior (not necessarily a segfault!) in C++ too. The compiler is free to replicate Objective-C's behavior if it wants to.
(Of course, no compilers actually do precisely that, but it is possible for compilers to delete virtual method calls entirely if it can prove the receiver had to be null...)
I'm kind of surprised there's not a means (to my knowledge, at least) to crash/throw an exception upon sending a message to nil for people who want to better ensure their code doesn't have lurking issues like this. I suppose it'd have to be smart enough to filter out system frameworks to be useful, but I'd imagine that to be do-able.
Sometimes these things are easier to explain if you look at it like an attacker:
If you're a regular user of an OSX system before 10.10.3, and you want to become root (admin user), you can use this exploit to become root.
If you're an author of malicious OSX software, and a user without admin permissions installs your malware, you can use this exploit to make your malware run as root.
Once you have root, you can do anything on a system.
If the system you're attacking is 10.10.3 or later, you won't be able to use this exploit because Apple has a fix in 10.10.3.
Apple will not make the fix available to anyone on 10.9 or earlier.
So who wants to sell a patch for the now unsupported users of OS X 10.9, 10.8, ...? It could be as simple as changing the permissions on System Preferences so that now you must enter your password before running them (so that they always run as root). Then patch out the backdoor.
I also don't think this indicates malicious intent. It's as likely that some collection of junior engineers who were tasked with something other than system security, simply invented something that was both insecure and obscure. This happens all the time. It takes a lot of extra time and code to engineer security and it's historically been one of the first things that product managers and senior management will toss out the door when the schedule inevitably becomes the gating factor. Hey, they fixed it. And you know, some Day One bugs are simply very very hard to fix when you find out years later that there's all this other code that depends on it...
[+] [-] diminoten|11 years ago|reply
What? So all OS X boxes are simply broken, privileges-wise, if they're not on 10.10?
[+] [-] danielweber|11 years ago|reply
[+] [-] z-e-r-o|11 years ago|reply
https://support.apple.com/en-us/HT204659
[+] [-] JustSomeNobody|11 years ago|reply
[+] [-] myared|11 years ago|reply
[+] [-] olefoo|11 years ago|reply
[+] [-] akerl_|11 years ago|reply
https://support.apple.com/kb/DL1803 https://support.apple.com/kb/DL1802
[+] [-] pquerna|11 years ago|reply
I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing.
[1] - https://developer.apple.com/library/mac/documentation/Darwin...
[+] [-] AnthonyMouse|11 years ago|reply
But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing.
The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.
[+] [-] smackfu|11 years ago|reply
[+] [-] moey|11 years ago|reply
- Start up the Mac whilst holding down ⌘-S. This boots the Mac into Single-User Mode and provides a method of interacting with OS X via the command-line, with full root privileges.
- Then check the filesystem to ensure there are no problems: "/sbin/fsck -fy"
- Then mount the filesystem for it to be accessible: "/sbin/mount -uw /"
- Now remove this file so OS X will re-run Setup Assistant: "rm /var/db/.AppleSetupDone"
Now just restart, and enjoy the cool introduction animation as you create your admin account.
[+] [-] floatboth|11 years ago|reply
I really hate all the desktop IPC bullshit. IPC frameworks are pure fucking evil. COM, D-Bus, XPC, everything SUCKS.
If you want completely separate programs on one machine to talk, use UNIX domain sockets (with something like ZeroMQ or HTTP), FIFOs (named pipes), anything that you can chmod and chown, not a daemon that reinvents access control, badly.
[+] [-] jjarmoc|11 years ago|reply
[+] [-] po1nter|11 years ago|reply
[+] [-] graeme|11 years ago|reply
I hate Apple's new yearly release cycle. There's not enough time to stabilize and improve OS's.
This update just rolled out, but it indicates the admin fixes are only for Yosemite:
https://support.apple.com/en-us/HT204659
How worried should I be about not having updated? There's still a risk I may lose some program compatibility by updating.
[+] [-] borgia|11 years ago|reply
It's dumbfounding how people here are simply shrugging this off and posting "So what? Just upgrade. Simples" type comments. This isn't acceptable. I know many people in creative industries alone who can't just upgrade immediately any time something comes out as they've to wait for their products to support the newer version. Similarly there are many who are using Macs in work whose corporate policies won't let them simply update immediately.
Then there's many who don't immediately upgrade versions as a point while bugs/other issues in that new version are found and resolved.
It's not an acceptable answer whatsoever.
[+] [-] bougiefever|11 years ago|reply
[+] [-] thebouv|11 years ago|reply
If only it were that easy. Yosemite just seems to "break" some things and I've still been waiting it out.
[+] [-] evilduck|11 years ago|reply
[+] [-] rdudek|11 years ago|reply
[+] [-] jotux|11 years ago|reply
I don't see a single comment in this thread that says that.
[+] [-] rewqfdsa|11 years ago|reply
We do not allow developers to criticize our revolutionary and beautiful platform. Good luck ever getting an app featured again.
- Apple
[+] [-] bdcravens|11 years ago|reply
[+] [-] Nexxxeh|11 years ago|reply
[+] [-] 72deluxe|11 years ago|reply
[+] [-] raldi|11 years ago|reply
[+] [-] coldpie|11 years ago|reply
[+] [-] 27182818284|11 years ago|reply
[+] [-] ccvannorman|11 years ago|reply
[+] [-] super_mario|11 years ago|reply
This is pretty bad, and trivially exploitable. Basically anyone that has non-root access to your computer can trivially become root and take over the system.
[+] [-] jrochkind1|11 years ago|reply
[+] [-] devy|11 years ago|reply
Case in point: Antenna gate, Bend-gate etc.
[+] [-] mike_hearn|11 years ago|reply
Programs crash for a reason! Crashing when faced with nonsense is a good thing! Let us not forget this.
[+] [-] chc|11 years ago|reply
[+] [-] saurik|11 years ago|reply
(Note: I, myself, do not ever rely on this functionality, and even disagree with it, but the context in which people use it is important to understand when judging it; and with that context, I consider my own objections mostly due to my biases and not something that I would argue is "correct".)
[+] [-] pcwalton|11 years ago|reply
(Of course, no compilers actually do precisely that, but it is possible for compilers to delete virtual method calls entirely if it can prove the receiver had to be null...)
[+] [-] glhaynes|11 years ago|reply
[+] [-] kaoD|11 years ago|reply
[+] [-] towelguy|11 years ago|reply
>Philip tried patching that function (replacing sete with setne), with success:
How do you patch the binary without root or the admin user password anyway?
[+] [-] mxfh|11 years ago|reply
[+] [-] chc|11 years ago|reply
[+] [-] avn2109|11 years ago|reply
[+] [-] pbreit|11 years ago|reply
[+] [-] maqr|11 years ago|reply
If you're a regular user of an OSX system before 10.10.3, and you want to become root (admin user), you can use this exploit to become root.
If you're an author of malicious OSX software, and a user without admin permissions installs your malware, you can use this exploit to make your malware run as root.
Once you have root, you can do anything on a system.
If the system you're attacking is 10.10.3 or later, you won't be able to use this exploit because Apple has a fix in 10.10.3.
Apple will not make the fix available to anyone on 10.9 or earlier.
[+] [-] kalleboo|11 years ago|reply
Sandboxed apps (from the app storr) may be blocked from doing this, I'm not sure.
[+] [-] 72deluxe|11 years ago|reply
Impact: A local user may be able to cause a system denial of service
Impact: A local user may be able to cause unexpected system shutdown
These two made me laugh though.
[+] [-] sounds|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] ddp|11 years ago|reply
[+] [-] driverdan|11 years ago|reply