Hidden backdoor API to root privileges in Apple OS X

https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-api-to-root-privileges-in-apple-os-x/

by mortenlarsen • 11 years ago

920 351 11 years ago

truesecdev.wordpress.com

percept• 11 years ago

Related to this, how have people found running Yosemite compared to Mavericks, performance and compatibility-wise?

Are you sorry you upgraded? (I'm asking for a friend.)

Osiris3• 11 years ago

I upgraded. I haven't had any problems that I wasn't already having in Mavericks (Anyone else have kernel panics when sleeping with a thunderbolt monitor attached?).

Sevrene• 11 years ago

Yes! (although minus the thunderbolt monitor)

NathanKP• 11 years ago

I haven't had any issues with that, and I have two thunderbolt monitors attached in daisy chain mode.

The only kernel panics I've experienced so far have been Parallels Desktop bugs that crashed the system. I'm regularly stressing my Macbook Pro to the max running vagrant images through Parallel Desktop with full integration tests running inside, and this tends to be pretty effective at finding strange bugs in Parallels Desktop.

mrchucklepants• 11 years ago

I've been running with a Thunderbolt Display for a few years now with few problems. I've had zero problems on Yosemite.

jug• 11 years ago

Among other things upgrading (to 10.10.3) will do, it'll fix the issue in the article.

Alex3917• 11 years ago

My personal computer is a late 2008 MBP, and Yosemite runs fine on that. It's been upgraded to 8 gigs of ram, and that's enough to smoothly do dev work in vagrant environments.

fmela• 11 years ago

I have the exact same setup with 8GB of RAM, and it's still going strong. I wish I could upgrade to 16GB to extend its life even further.

btgeekboy• 11 years ago

If you're seriously concerned, why not use an external drive of some sort and install Yosemite to it? (Bonus points: clone your internal disk to it first, and upgrade that.) Boot it up, test out your critical functions, and then update your main volume if it works out for you.

Nexxxeh2• 11 years ago

Would using an external drive make it noticeably slower, making performance non-representative?

markcerqueira• 11 years ago

You need to do the Bonus points version of your recommendation. Running an OS off an external will just make everything feel sluggish (unless you have a lightning enclosure and spare SSD laying around).

lultimouomo• 11 years ago

I recently got a mac mini that shipped with Yosemite. It has the nice feature of completely killing the WiFi interface when you attach a USB hub - googling around it seems a Yosemite bug. I have been told that also using bluetooth devices (such as the apple mouse) can trigger the same behaviour. So I'd say I'm sorry that the mac shipped with Yosemite, except that at least I received the fix for the privilege escalation bug.

marcinx27• 11 years ago

I had this bug plaguing me for a while. My WiFi connection would drop every fifteen minutes or so, requiring me to turn off the WiFi and then turn it on again. I was able to fix it by doing a clean install of Yosemite (from a bootable drive).

julian_t• 11 years ago

It isn't just Yosemite... I had exactly this behavior with Mavericks on a new MacBook last year. Fired up a Bluetooth mouse, and next time I opened the lid wireless had completely gone.

I've managed to get it working after a fashion, although not reliably, and have come to the conclusion that Apple just don't do wireless well.

pquerna• 11 years ago

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.

[1] https://developer.apple.com/library/mac/documentation/Darwin...

smackfu2• 11 years ago

Isn't the "hidden" part related to them being a private API/Framework?

AnthonyMouse3• 11 years ago

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.

superuser2• 11 years ago

then so can the attacker

Maybe, but the attacker can also get their certificate revoked when their activities are discovered.

wfunction• 11 years ago

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

That's like saying kernel memory protection is silly when the user is an admin because he could just as well load a driver into the system to wreak whatever havoc he wants.

Yes, he could. No, it's not silly.

moey• 11 years ago

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.

KuchenKerze2• 11 years ago

Not possible if full disk encryption is enabled. And that is a default since a year or so.

nothrabannosir• 11 years ago

full disk encryption only protects you from passive snooping. If someone has physical access between two of your subsequent uses, no amount of any type of encryption will save you. Except maybe some entangled quantum bit collapsing mechanism. Maybe.

Think hardware keyloggers, fake MBRs, &c.

OP's trick won't work, but that's an "implementation detail;" there are plenty others that will.

EDIT: to clarify; that's not what you said, it's just a common enough misconception that it's worth being explicit about, here.

Archio• 11 years ago

Isn't the idea though that with physical access, the game is already over anyway? If an intruder has physical access to your machine they will eventually be able to get to anything they want.

If someone really wants to protect their data, they have to count physical access as a possibility and rely on encryption and/or remote wiping - the operating system login isn't going to do much anyway.

Vexs• 11 years ago

Yep, physical access is total access. However, this trick falls under cool-at-school-tech-labs, I'd hope enterprise systems would do something to prevent this kind of low-level shenanigans.

taumhn• 11 years ago

If you're paranoid enough to think someone you don't trust can have physical access to your Mac, it is possible to prevent this by setting up firmware password though.

See https://support.apple.com/en-us/HT204455

thudson• 11 years ago

Firmware passwords can be bypassed by a local user with a Thunderbolt Option ROM. The 10.10.2 fix for Thunderstrike left that hole open during normal boots: https://trmm.net/Thunderstrike_FAQ#Is_Thunderstrike_fixed_in...

matthewmacleod• 11 years ago

Yes, but that's not really a concern. Physical access with no disk encryption is always 'vulnerable'.

What's pretty bad here is that any user now has a backdoor to obtaining root privileges. That's an awful security flaw.

praseodym• 11 years ago

Even easier is running 'resetpassword' from Terminal in Recovery mode (boot with ⌘-R). This gets you a nice GUI tool where you can reset any account passwords.

But yes, this is not possible with a firmware password or with disk encryption (FileVault) enabled.

kpcyrd3• 11 years ago

If I understood the article correctly, this can be exploited remotely by anybody who has managed to get a shell on the system.

jrochkind12• 11 years ago

It's even worse than it seems if you talk about it as 'anybody'.

Most OSX boxes are probably single user devices. But you do not normally run as root/wheel, you need sudo (sometimes through a nice GUI) for software to get root privs.

It's not 'somebody' as if another person were logged into their own account. It's that malware running as you can now get root, to further compromise your system, without needing a sudo password.

mhurron• 11 years ago

That's how all local exploits work.

mattrepl• 11 years ago

Just to clarify, this is _not_ a remote vulnerability. If it was a means to create a remote shell, then it would be. An attacker would need to first find some way to gain remote access and then could use this bug to gain root privilege.

Osiris3• 11 years ago

The first Mac I ever got, the IT department forgot to give me admin access, so I couldn't install any software. Having never used a Mac before, it took a grand total of about 15 minutes of Googling to figure out how to boot into single user mode and give myself admin access.

cheald2• 11 years ago

Local privilege escalation is always bad because it means you're one malware payload or RCE away from being rooted and conscripted into someone's botnet (or worse). This isn't just a physical access concern.

andreyf• 11 years ago

What about without local privilege escalation? Is there no way for a malware payload or RCE to turn your computer into a botnet without root privileges?

wyager• 11 years ago

There's a huge difference between physical access vulnerabilities (which are basically impossible to prevent) and local privesc vulnerabilities (which can be exploited in software).

JorgeGT• 11 years ago

To exemplify, for instance, this vulnerability could be packed in a phishing mail executable giving the remote attacker root access if the user falls for the trap, no?

alexsop2• 11 years ago

About two months or three ago I stupidly changed my password to my only account to a password I promptly forgot. I was losing it when I realized what I had done. To make matters worse, I did this change a day before our office was scheduled to move to automated backups via Time Machine.

Luckily after some digging I came across this fix and was back in to my computer, albeit a little shaken up by the back door.

0x0• 11 years ago

That's not very interesting. You can do the same on a linux box, passing init=/bin/sh in the boot loader, and probably the same on windows (boot a WinPE CD or a Linux live CD with NTFS3g).

darkarmani• 11 years ago

With physical access

What malware requires physical access? This is a local privilege escalation to root. It's only local because you need an account on the machine to make it work, but it can be bootstrapped to a remote exploit.

diminoten5• 11 years ago

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?

danielweber2• 11 years ago

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.

e40• 11 years ago

What about developers that need to support customers on older systems?

matt40772• 11 years ago

To be fair, OS X updates are free and usually run well even on 5+ years old hardware. OS X has kinda gone the way of Chrome, with most users on the newest version.

driverdan2• 11 years ago

Or LTS versions of Linux.

tsieling• 11 years ago

Apple's model customer is one who upgrades often.

I don't know any tech company that doesn't have that idea of a model customer :)

To their credit, I can run the latest on a pretty old Mac Mini at home. It's not as fast as it used to be, but it is supported long after the form factor of the Mini has undergone big changes. I don't consider myself being squeezed to upgrade.

s_q_b5• 11 years ago

Or your IT department could force you to use a Golden Master of 10.9, and not let you update.

n_blom• 11 years ago

Holy Apple can't be wrong. Microsoft bad bad and clunky.

We're talking about a security issue!

gurkendoktor• 11 years ago

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.

It's not only about support for "old" products, it's also about having a roadmap to begin with. It used to be common wisdom that Apple releases major updates for the current version of OS X, and security fixes for the last two versions. Well, that common wisdom is outdated now.

Also, backwards compatibility and security fixes are not really the same, and I'd say that the correlation between backwards compatibility and software quality is completely overrated. I know I'd rather trust my life to Windows 7 (the epitome of conservative OS design) than to OS X 10.10 or iOS 8 (speaking as an iOS developer).

In raw numbers, 45% of OS X users are now vulnerable (and probably don't even know about it), and Apple doesn't care. That's an insane number. And I thought not patching the ~10% iPhone 4 in the wild was dangerous!

myared• 11 years ago

What better way to encourage people to upgrade.

hrayr• 11 years ago

or to abandon your product

larrys• 11 years ago

"What better way to encourage people to upgrade."

The majority of their user base doesn't know and wouldn't care about this type of thing even if they did.

emodendroket• 11 years ago

There are still organizations paying huge stacks of money for Windows XP support past EOL.

JustSomeNobody3• 11 years ago

If nothing else, they should feel a moral obligation to fix it in previous versions.

z-e-r-o• 11 years ago

They even released "Security Update 2015-004" at the same time, including many updates for 10.8 and 10.9, but not the admin framework.

https://support.apple.com/en-us/HT204659

zatkin• 11 years ago

The first item on their list of patches is this vulnerability.

akerl_• 11 years ago

Looks like they've released patches for Mavericks and Mountain Lion as well:

https://support.apple.com/kb/DL1803 https://support.apple.com/kb/DL1802

untog• 11 years ago

Unfortunately this fix is apparently not included.

olefoo2• 11 years ago

That's how I read it. And that's why I'm making plans to migrate away from Apple Desktop.

72deluxe18• 11 years ago

To what though? All the other offerings don't seem at the same state, unless Windows 10 can rescue us all?

I notice that Windows 10 has had new bits shoe-horned in (a new settings screen!) whilst still keeping ALL the old stuff there (MMC as written in 1998? Control Panel is still there despite this new Settings page, duplication much? None of the icons match etc. etc. what a hodgepodge)

raldi2• 11 years ago

I'm having a hard time understanding whether this is an intentional backdoor or just an accident.

coldpie2• 11 years ago

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.

raldi2• 11 years ago

In that case, I think "backdoor" is hyperbolic. That word is usually uses to indicate intentional secret security holes.

kazinator2• 11 years ago

Not closing the hole in old versions of the OS isn't an oversight, however.

27182818284• 11 years ago

The reading indicates a few times it was likely there for System Preferences, not for a government agency or anything like that.

towelguy• 11 years ago

Okay, so the systemsetup binary simply checks if we are running as the root user?
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?

nmc• 11 years ago

I think this is not part of the exploit, it was simply a step to ensure that their intuition about the assembly code was correct.

Hint: the first sentence you quoted ends with a question mark.

apendleton• 11 years ago

Pretty sure they did that as root, so they could get past that and explore how the program worked when being run as a non-root user. The final exploit doesn't depend on this program, though; it uses the same RPC interfaces this program does, from a separate program, so the patching was just part of their exploration, not part of the exploit.

AgentME2• 11 years ago

Just make a copy of the binary that's editable by the user. Or copy its code into a new program. There's nothing special about the specific root-owned systemsetup binary. (It's not setuid.)

Nexxxeh2• 11 years ago

Are Apple glad it wasn't found by a "You have 90 days before disclosure" outfit? Look at that timeline...

72deluxe18• 11 years ago

Pretty lengthy time! Let's hope he got a bounty or a free device as a reward

__m• 11 years ago

wait, you expected to find people at a security conference that weren't aware of the fact that even OS X can have exploitable vulnerabilities?

driverdan2• 11 years ago

Six months for a fix? I would have given them 90 days and released it.

mike_hearn• 11 years ago

Objective-C's "null pointer dereferences doesn't crash" behaviour rears its ugly horrible head again.

Programs crash for a reason! Crashing when faced with nonsense is a good thing! Let us not forget this.

kaoD• 11 years ago

Can you explain this to non Obj-C users? How does it not crash on null pointers?

pcwalton3• 11 years ago

Calling any method ("sending any message" in Objective-C terminology) on a nil receiver does nothing and returns the zero value of the method's result type (a value of the right size with all bits zeroed).

_cbsz• 11 years ago

The Obj-C function call [foo doSomething] compiles to the equivalent of objc_msgSend(foo, "doSomething"); (for the pedantic, I'm intentionally simplifying and leaving out objc_selfrefs)

The first thing objc_msgSend does is check if foo is nil and, if so, returns 0/nil/the all-zero bit pattern/whatever. It can be extremely convenient, but it can also be extremely inconvenient.

bitwize• 11 years ago

In Objective-C 'nil' is a special object (internally rwpresented by a null pointer). When the runtime is instructed to invoke any method on nil, the method does nothing and returns nil (rather than crashing). I think this is an artifact of Smalltalk behavior.

pcwalton3• 11 years ago

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...)

MichaelGG• 11 years ago

Why is that undefined? Seems like it should obviously cause a fault...

chc3• 11 years ago

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.

glhaynes2• 11 years ago

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.

jdmichal4• 11 years ago

Why not just some old-fashioned input guarding?

    if (input == nil)
        haltAndCatchFire();

Or whatever the Objective-C syntax for that is.

chc3• 11 years ago

There is a means to do that: http://ddeville.me/2013/06/ruby-like-nil-messaging-in-object...

I have a feeling it wouldn't work well in practice if you made the handler raise an exception. As the author notes, you're not the only one sending messages, and Cocoa will probably crash your program with a nil message send sooner or later. But you might be able to use it to find out where it's happening, at least.

mikeash2• 11 years ago

There was, in the form of the -fno-nil-receivers compiler flag. It looks like clang doesn't support this flag. I'm guessing nobody used it. You'd have to be really careful when turning it on, since you're effectively using a language that's similar but not quite identical to Objective-C, and which will crash on lots of legal and sensible Objective-C code.

saurik• 11 years ago

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".)

po1nter• 11 years ago

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.

thebouv3• 11 years ago

Same devs who just say "users should just upgrade their browsers" perhaps?

If only it were that easy. Yosemite just seems to "break" some things and I've still been waiting it out.

bougiefever• 11 years ago

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.

rdudek• 11 years ago

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.

graeme• 11 years ago

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:

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.

kentonv• 11 years ago

Is your mac a server or a multi-user desktop where some users intentionally don't have admin access? If so, you're in trouble. If not, this bug probably doesn't really matter to you.

For a single-user desktop machine, realistically, user/root privilege separation doesn't matter, because all your important data is in your home directory and not protected by root privileges anyhow. The root-protected stuff is actually the stuff that's easiest to replace, because it's just a bunch of software that you can re-install. Viruses don't need to infect your software to stay resident; they can just as easily register a login hook without root permissions.

(That said, some people will violently disagree with me on this.)

evilduck4• 11 years ago

What apologists? Were the comments deleted or something, because I really don't see anyone defending Apple in this thread.

baldfat8• 11 years ago

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.
To be fair, OS X updates are free and usually run well even on 5+ years old hardware. OS X has kinda gone the way of Chrome, with most users on the newest version.
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.
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.
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.
Referring to Snow Leopard now not secure > Still pretty much the best OSX.
Among other things upgrading (to 10.10.3) will do, it'll fix the issue in the article.

jotux6• 11 years ago

many comments here are saying that people should just upgrade

I don't see a single comment in this thread that says that.

bdcravens4• 11 years ago

Yeah, imagine if the same was true of say, Rails 4.0.

borgia• 11 years ago

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.

It's not an acceptable answer whatsoever.

jotux6• 11 years ago

It's dumbfounding how people here are simply shrugging this off and posting "So what? Just upgrade. Simples" type comments.

Zero people is dumbfounding to you? Because that's how many people are saying that.

rotten• 11 years ago

I have 3 macs. One of them is an older iMac. I can't put enough RAM in it to run Mavericks (which is a memory hog). It is a perfectly good computer, there is no reason to upgrade from Lion.

The next one is a 3 year old Mac Mini. I upgraded to Yosemite and it performs TERRIBLY. It has 16G of RAM. I've tried everything. Yosemite just sucks. The machine is now much slower than the 6 or 7 year old iMac with only 4G or RAM. If it was practical to back out to Mavericks I would.

The last one is a 2 year old Macbook. I rely on it for my job. There is no way I'm going to risk the crappy Yosemite performance to upgrade. I'll live with the security flaw.

Here is what I now know about Apple: They will not support you for the lifetime of the product. They consistently release buggy code these days. Unless you are willing to shell out more money for new hardware every time they come out with something new, you will be stuck "as-is (with bugs)" until you get rid of it.

No more Apple anything for me. I'm thinking I'll switch the Mac Mini to Ubuntu if I can get it to work there. I'll use the iMac until it doesn't work any more, and when my Macbook is ready for an upgrade (in another year or two), I'll be trading in that still-Mavericks based system for a Linux laptop or maybe I'll go back to Windows.

rewqfdsa• 11 years ago

po1nter,

We do not allow developers to criticize our revolutionary and beautiful platform. Good luck ever getting an app featured again.

- Apple

72deluxe18• 11 years ago

Haha reminds me of the article from the other week: http://www.elischiff.com/blog/2015/3/24/fear-of-apple

jrochkind12• 11 years ago

I am really pissed they are only releasing a patch for 10.10, and forcing me to upgrade to 10.10.

mxfh• 11 years ago

So is Snow Leopard (Mac OS X 10.6.8) not affected?

avn21092• 11 years ago

Still pretty much the best OSX.

72deluxe18• 11 years ago

Unless you want to resize windows from the left edge :-)

chc3• 11 years ago

I'd imagine Snow Leopard is vulnerable to the first exploit mentioned in the post.

antimora• 11 years ago

This article has a nice exploit code written in python down below for curious ones how works in code.

pbreit• 11 years ago

Could anyone summarize the implications of this finding in plain English?

kalleboo• 11 years ago

Any code running as any user on an unpatched version can become root (and do whatever it wants, E.g. install keyloggers)

Sandboxed apps (from the app storr) may be blocked from doing this, I'm not sure.

kybernetyk• 11 years ago

Sandboxed apps (from the app storr) may be blocked from doing this, I'm not sure.

Just tried. Sandbox lets this through. (As long as you pass nil to authenticateUsingAuthorizationSync:).

maqr• 11 years ago

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.

jjarmoc4• 11 years ago

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.

f3llowtraveler• 11 years ago

There's no way to tell for sure if something like this is intentional or not. Also, waiting to fix it until a researcher makes it public may have been intentional.

jjarmoc4• 11 years ago

There's no way to tell for sure if something like this is intentional or not.

Right, so the simplest explanation is that it's an unintentional bug. The absence of evidence that it was unintentional isn't evidence that it was intentional. If there were some magic string or default password or something, that'd be an obvious backdoor, but to me this looks like a pretty typical privesc bug, albeit in an undocumented api.

It was found through a chain of events that started with looking at the patch related to another privilege escalation vulnerability, one which no one seems to be claiming was a backdoor.

Also, waiting to fix it until a researcher makes it public may have been intentional.

I'm guessing it's more likely the the researcher waiting to go public until it was fixed.

This is evidenced both by the fact that it was patched alongside other vulns (ie. not a rushed out one-off patch) and from the article's disclosure timeline, which shows 'Full disclosure' occurring 04/09, while the 'Release of OS X 10.10.3' occurred 04/08. This is a pretty typical disclosure timeline; they couldn't begin to fix it until it was tracked as a bug, after all.

arielby• 11 years ago

A function named "createFileWithContents" is clearly intentional - through its creator probably just hadn't realised the security implication, making this a negligent, rather than malicious, backdoor, not unlike default router passwords.

jdmichal4• 11 years ago

This is a hole that exists because an Apple-written application needed a method to gain elevated access. This was done through unpublished APIs which, when used by another application in a similar way, also resulted in elevated access.

So, this was clearly intentional, because it's used by Apple directly. And it allows illicit access, because any program can use it to gain access.

3JPLW• 11 years ago

I'm not so sure. Unless I'm missing something, he doesn't demonstrate that this 'backdoor' is in use. It looks like they were using an escalation backdoor in `systemsetup`, but quickly patched a fix after 10.8.5. He just found a way around it.

Now, the fact that 'it takes too much effort' to backport would suggest that it was still in use. I don't see any other evidence, though. I'd be interested if someone found it!

anonbanker• 11 years ago

so... Anyone preparing OpenBSD to work on newer macbooks?

bdcravens4• 11 years ago

10.10.3 came out 2 days ago. This counts as reasonable disclosure?

cozzyd3• 11 years ago

He discovered it 6 months ago. Maybe he gave Apple 6 months to fix it before disclosing?

bdcravens4• 11 years ago

I get that, but surely you have to provide a reasonable amount of time for patches to be installed. Perhaps a 2-part blog entry, where he gives general details (to instill urgency) and then release exploit code a month later?

smackfu2• 11 years ago

Once the fix is out there, attackers can compare the new and old code and home in on the vulnerability very quickly.

ccvannorman• 11 years ago

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.

super_mario• 11 years ago

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.

devy• 11 years ago

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.

Case in point: Antenna gate, Bend-gate etc.

floatboth• 11 years ago

Of course this exploits XPC.

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.

catern• 11 years ago

Well, this is a very trivial "exploit" of XPC. The real problem is that such an API even exists at all. I mean, a method to create an arbitrary file in an arbitrary location with arbitrary attributes? That is completely braindead. That is clearly equivalent to root privileges, and therefore such an API shouldn't exist - sudo should be used instead, or other OS X methods of explicitly gaining root privileges.

This method wouldn't pass the most cursory of security checks. It's clear that it was never actually reviewed, and that the original programmer was relying on the proprietary nature of the OS X system for security. Something like this would never happen with Linux IPC - reviewing the methods published on dbus by services running as root by default is a basic check that any sane distro will do. Something as straightforwardly exploitable as this (literally just call the method while running as an admin user!) would never go in to Debian.

kenferry• 11 years ago

Hm? This wouldn't have been any better if implemented using sockets.

FooBarWidget• 11 years ago

Indeed, it wouldn't. It's just another typical example of someone who doesn't understand why a complicated IPC system exists, and thus blames all possible problems on its mere existence.

It's like users who encounter a random problem in a program, and then blame it on the fact that the program is written in C++, simply because they do not like C++.

asanagi• 11 years ago

Is this a systemd thread? This looks like a systemd thread!

awalton• 11 years ago

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

D-Bus does use UNIX domain sockets. Your ruthless hate should probably try harder at informing itself.

hellbanner• 11 years ago

OT but does anyone know how OSX bluetooth keyboards work? I thought I had BT disabled and a prompt popped up on hotel wi-fi asking me to enter the code for (not my) keyboard

sounds• 11 years ago

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.

yourad_io2• 11 years ago

The Admin framework in Apple OS X contained a hidden backdoor API to root access for several years (at least since 2011, when 10.7 was released).

Lion was cancer.

yourad_io2• 11 years ago

I see there's no love for Zodiac puns. Oh well, I still love you guys.

cmurf3• 11 years ago

It does explicitly say that Security Update 2015-004 only updates Admin Framework on 10.10+ (it does not require 10.10.3) to fix CVE-2015-1130 : Emil Kvarnhammar at TrueSec https://support.apple.com/en-us/HT204659

Quite a few other security related things are fixed with this update that do apply to older versions of OS X.

ddp• 11 years ago

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...

yuhong• 11 years ago

I wonder how long before malware that uses this will appear, given this is trivial to exploit.

thrownaway2424• 11 years ago

Couldn't they have made the update slightly smaller than 2GB? Apple sucks at distribution and their software update infrastructure is hosing.

williamstein• 11 years ago

I upgraded my 2014 15" rMBP and it killed the wifi, so now ping times have gone from about 12ms to several thousand or nothing. https://medium.com/@mariociabarra/wifried-ios-8-wifi-perform... no longer works. Depressing. I miss my chromebook.

arbitrage• 11 years ago

You could sell your rMBP and use the proceeds to buy like 4-5 chromebooks.

72deluxe18• 11 years ago

https://support.apple.com/en-us/HT204659 makes for depressing reading.

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.

Hidden backdoor API to root privileges in Apple OS X

Related Stories