View Single Post
ShadowOfGed
Travels via TARDIS
 
Join Date: Aug 2005
Location: Earthsea
 
2008-06-22, 20:27

Let's put "Big" in context:

First: this hole uses AppleScript. Thus, because of how AppleScript works, it will only grant root access to the current console user (whoever's physically logged in at the computer). If you fast-user-switch to another account, the original user cannot even use ssh to exploit this; AppleScript will fail.

Second: this "hack" is not specific to ARDAgent.app. It will work on any AppleScript-able application that is installed setuid. If you make Adium setuid root and then:

Code:
tell application "Adium" to do shell script "/some/executable"
Adium will then exhibit the same behavior. That is, any setuid application (root or otherwise), will do shell scripts as the user owning the file; perhaps root, perhaps someone else.

Third: There's probably a very good technical reason that ARDAgent.app is setuid root; Apple does not distribute setuid binaries lightly. As such, the proper fix is to restructure ARDAgent.app such that it no longer requires setuid root. This sounds like the kind of change that is impossible to make in a lightweight security update.

As a fun exercise, anyone with a lot of free time should go count the number of setuid binaries (particularly root) on the latest unmodified installations of 10.3, 10.4, and 10.5. My guess is they're decreasing, because anything setuid root can present this kind of hole, and there's nothing to be done about it*.

Fourth: This is a privilege escalation exploit, but put in perspective, it's not as bad as everyone wants. Sure, you don't have to enter a password as with sudo. However, this requires authenticated local access (someone who belongs on the machine). Any local user who's also an admin can get root access through sudo anyway, so it's only at risk of granting non-admin users root access they couldn't otherwise get.

Finally: since AppleScript requires you to own the console (/dev/console), you're looking at a user who already has physical access to your box. This won't even work through SSH if you're not currently logged in at the machine itself. So, if they have physical access, most bets are off already.



EDIT: Yeah, it sucks, but it's not a remote exploit, and frankly it's not exploitable unless you run some schmuck's devious AppleScript from out on the Internet. As I saw mentioned elsewhere, this could be exploited by installer scripts to gain root access sans authentication dialogs, which is indeed ugly. On the other hand, if you're downloading software that (clearly) you shouldn't trust, you'd probably have typed your password into the prompt anyway. Though it makes trojan horses… easier, the main problem is still that you downloaded and installed a trojan horse without thinking twice.

I'd like to see it fixed, sure. But (see below, after enough edits) I'm not sure it's possible to fix it in the short term.

---

*Here are a couple fun scripts for those of you curious enough to check. Yes, you're going to need sudo so that find can scan the entire hierarchy as root, to avoid encountering "Permission denied" errors.

All SetUID binaries on /:
Code:
sudo find -x / -type f -perm +0111 -perm +4000
All SetUID root binaries on /:
Code:
sudo find -x / -type f -perm +0111 -perm +4000 -user root
To count the files listed in the above outputs, just append this to either command:
Code:
| wc -l

Apparently I call the cops when I see people litter.

Last edited by ShadowOfGed : 2008-06-22 at 22:07. Reason: Have fun with shell scripts, kiddies!
  quote