
Hidden backdoor API to root privileges in Apple OS X - mortenlarsen
https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-api-to-root-privileges-in-apple-os-x/
======
diminoten
> 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?

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

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

~~~
JustSomeNobody
To be even more fair, there's been a number of issues with Yosemite that make
some of us want to stick with Mavericks.

Just because something is free doesn't make it better.

~~~
wwweston
Yep. JWZ used to say that Linux is only free if you don't value your time.

OS X has many merits on this front, but since 10.3 I've found that the first
few dot releases of OS X have the same caveats often enough (both in terms of
bugs/hazards and in terms of gratuitous UI "progress") that it usually seems
better to wait past .x.4/5.

Now there's this, of course.

Since the problem showed up in 2011, maybe I should go back to Snow Leopard; I
can't think of a single valuable change to OS X since then...

~~~
sls
> JWZ used to say that Linux is only free if you don't value your time.

My reply to that has always been that Windows is only $300 if you don't value
your time. (Preserving archaic cost of Windows to match JWZ quote.)

The implication that the one system is free and time-consuming and the other
moderately in price but not time-consuming is entirely false. At the time, for
many requirements, configuring and administering a Windows machine would have
been more time-consuming than for Linux. It's also glossing over the fact that
you can't horizontally scale your $-per-cpu/server solution once you do have
the configuration worked out, without going back to the well for more money.

This amusing and glib quote also deliberately glosses over the "freedom" part
of free software, which is essential. For example, I wonder if Google would
exist today if not for a free unix workalike.

~~~
soup10
Linux desktop is and has been second rate for a long long time. Turns out
unless there are corporate sponsors paying for development, open source
software sucks. The OSS community is pretty much in denial about that.

~~~
Tiksi
That's funny, because I haven't managed to find a desktop OS that is up to par
with Linux for me. Preferences may vary, but second rate in your book is the
only viable contender in mine. Also turns out that Linux does in fact have
corporate sponsors, like oracle, red hat, etc. so I'm not sure I follow. Is
closed source software top notch without corporate sponsorship?

The sad truth is that _most_ software sucks, regardless of the license,
there's just a lower barrier to entry, use, and discoverability with OSS so
it's more visible. At least with OSS we can fix the issues instead of just
accepting the suckage.

~~~
utbabya
I'm probably biased.

After a year I find the only advantage of OSX are browser with touchpad
gesture experience and windows edge handling. Haven't tried any distro ever
since switching to MBP, wayland might have a better chance of replicating the
experience. Hoping for the camera driver to be done.

In Linux everything else is better, fuller implementation of base tools,
customizability, no crap like /var/folders..

~~~
72deluxe
"In Linux everything else is better"

This is entirely subjective; it is not a wise comment to make because it is
better FOR YOU, not for everyone. For me, I liked the configurability in Linux
desktop land but there comes a time when you want to sit in your office and
get stuff done instead of spending all the time moving the furniture around
and decorating; OSX doesn't let you do any decorating or move the furniture,
so you're forced to do work (to some extent).

I daily use Linux, yet my day-job is to write software on OSX and Windows, so
I get to use every system every day. They're all pretty much a muchness.

~~~
Snesker
Is your comment saying 'linux is amazing, I just can't stop ricing it and get
to work! OSX is better because it doesn't let me customize it'?

~~~
72deluxe
No, it's saying both are great but Linux constant desktop change and rewriting
of underlying systems to break upgrades between OSes isn't for me at the
moment (as a desktop system). It may be great for someone else though.

Great for servers.

Basically, each to their own. None is "better".

------
pquerna
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...](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man7/sandbox.7.html#//apple_ref/doc/man/7/sandbox)

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

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

~~~
AnthonyMouse
Memory protection is not silly. Not being able to bypass memory protection
(and therefore prohibiting all manner of debugging tools) _is_ silly, and that
is the appropriate analogy.

If a user correctly has permission to do a thing via a series of ugly hacks
then there is no reason not to just let the user do the thing directly.

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

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

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

~~~
kpcyrd
The parent comment and some of the child comments are implying you need to be
physically near the system, which doesn't seem to be true.

You still need to find a way to execute code on the target system (also called
"getting a shell"), but this can be done over the wire, too.

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

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

~~~
FooBarWidget
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++.

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

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

~~~
Animats
_There 's no way to tell for sure if something like this is intentional or
not._

Yes, there is. Sue Apple for willful negligence and subpoena the development
logs.

~~~
__david__
Sigh. No _practical_ way…

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

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

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

~~~
chaostheory
"I can't put enough RAM in it to run Mavericks (which is a memory hog)."

I'd upgrade to Yosemite today with the latest updates. They just freed up 4 GB
of ram for me. Sadly if I had known all of this beforehand I wouldn't have
gone out of the way to buy some old Mac Pro where I could upgrade the memory
to 32 GB or more, so I just wasted about $1500 for the whole setup.

Then again like you, I transitioned my work to an Ubuntu box, but even for my
personal stuff my Mac was just really slow unless you get an SSD drive which
is time consuming to install on an iMac.

~~~
Yhippa
You can't run Yosemite on a lot of older hardware:
[http://www.apple.com/osx/how-to-upgrade](http://www.apple.com/osx/how-to-
upgrade).

~~~
chaostheory
2007 is pretty old when it comes to Macs.

For 2009 and up Mac Pros, there are plenty of hardware options for upgrades;
and firmware as well for 2009.

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

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

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

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

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

~~~
mikeash
What do you call something that grants root access without authentication, but
wasn't intended to let arbitrary people or programs use it?

"Backdoor" isn't quite right, since that implies that the intent was to allow
unauthorized use.

"Security vulnerability" isn't quite right _either_ , since that usually
implies getting code to exhibit some sort of behavior it was never supposed to
have.

I can't think of any other term. Of the two, "backdoor" seems closer. Maybe
"unintentional backdoor"?

~~~
uxp
> What do you call something that grants root access without authentication,
> but wasn't intended to let arbitrary people or programs use it?

Local privilege escalation. In a huge number of established LPEs, the exploit
is by leveraging a weakness in checking who makes the call that allows
legitimate privilege escalation. This is a legitimate privilege escalation
(sshd binds to port 22, among others tasks), that can be exploited through a
weakness in checking who is making that request and if they can have that
granted.

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

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

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

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

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

~~~
jdmichal
Why not just some old-fashioned input guarding?

    
    
        if (input == nil)
            haltAndCatchFire();
    

Or whatever the Objective-C syntax for that is.

~~~
glhaynes
To make a scheme like that work, you'd essentially need to check before every
single method invocation in your entire program because the issue — such as it
is — is with method invocations being made against nil references, not with
nil parameters being passed in as arguments to method calls.

I was imagining something more like a modified version of the runtime's
objc_msgSend() C function (which Obj-C method invocations get compiled into)
that guarded against that, but you do make me realize that such checks could
conceivably be automatically tacked on at build time.

Anyway, I'm not entirely sure how useful such a thing would be, but I am
curious how often my code (unintentionally) makes calls against nil and I've
just never noticed because it doesn't cause harm.

~~~
jdmichal
Ah, I see. I think that at some point you have to trust something. The only
true way is to never trust any of your inputs. This is, after all, what the
JVM does in order to throw out kindly NullPointerExceptions on null
dereferences. But realistically that is extremely consuming and has little
payoff in most cases. I typically do not trust arguments, but do trust the
results of functions to be what the documentation says it will be.

Static analysis could potentially go a long way here to expose values that
could be potentially "infected" with nil. (And, for all I know, the JVM JIT
could do exactly this to skip checks on provably non-null values.)

------
towelguy
> 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?

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

------
mxfh
So is _Snow Leopard_ (Mac OS X 10.6.8) not affected?

~~~
avn2109
Still pretty much the best OSX.

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

~~~
avn2109
Preach.

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

~~~
kalleboo
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
>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:).

~~~
72deluxe
Ouch.

------
72deluxe
[https://support.apple.com/en-us/HT204659](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.

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

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

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

------
cmurf
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](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.

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

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

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

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

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

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

~~~
bdcravens
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?

~~~
cozzyd
If he published because Apple just patched, then I agree. If he published
because he said he was going to disclose it at a certain time, then I think
it's Apple's fault for dragging their feet. 6 months is an eternity.

------
yourad_io
> 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_io
I see there's no love for Zodiac puns. Oh well, I still love you guys.

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

~~~
Osiris
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
Yes! (although minus the thunderbolt monitor)

~~~
Osiris
I also have a problem with a Dual-link DVI adapter. If I sleep with it
connected, at some point it wakes up and "kernel_task" takes up 100% CPU (all
8 cores) until I put it to sleep and wake it up again. Sucks coming down in
the morning and finding my Macbook burning a hole in the desk.

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

------
williamstein
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...](https://medium.com/@mariociabarra/wifried-ios-8-wifi-performance-
issues-3029a164ce94) no longer works. Depressing. I miss my chromebook.

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

------
__m
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?

