Does this create a local root exploit for Mac OS X using Finder?

August 30, 2009 7:01 AM

Why does Apple's Finder bypass some group permissions?

A directory /Games is owned by the Games user and Games group and has mode 750. The Admin user may not access /Games from unix programs, like say bash. But said Admin user may happily access /Games from Finder! wtf?!?

I imagine this means Finder is running as gid 0, which seems like a major security risk. I noticed that /Games isn't accessible from Finder if the group is changed to wheel, group 0, which mitigates the most obvious security risks. But a buffer overflow in Finder could surely give gid 0 access! wtf?!?

posted by jeffburdges to Computers & Internet (15 answers total)

Response by poster: I verified that Admin isn't a member of the Games group, just _lpadmin, admin, com.apple.access_ssh and it's own user group, nor does /Games have any ACLs according to ls -le.
posted by jeffburdges at 7:06 AM on August 30, 2009

FWIW, on this mac (running Snow Leopard), my Finder process is running as me, with GID equal to my primary group. You can check what GID the finder is running as with this command:

ps -AfO gid | less

HTH.
posted by genehack at 8:06 AM on August 30, 2009

Response by poster: Finder is running as gid 501 but must have setgid access to gid 0, normal programs like bash definitely can't open /Games. I'm running Leopard not Snow Leopard, btw.
posted by jeffburdges at 8:13 AM on August 30, 2009

Doing a google search for OSX local exploits shows a number of hits. In general privilege escalation is a very common kind of bug for every commonly used OS (even openbsd gets them, though they have not discovered one in about 6 years).

This is a usability issue because desktop users expect to be able to muck around with every part of their system at their discretion through the standard WIMP interface. Given the fact that the finder is closed source and does not typically deal with arbitrary user input, I hazard a guess that the OSX devs may take away the setgid bit if an exploit is found in the wild, but will leave things as is otherwise.
posted by idiopath at 8:22 AM on August 30, 2009

Response by poster: I already checked that Finder is not setgid, nor is Finder's parent process launchd, and launchd has gid 501 too. So we're talking some kernel "feature" here.
posted by jeffburdges at 8:35 AM on August 30, 2009

I'd love to get to the bottom of this one.


Can you show us the actual output of these:

ps -AfO gid |grep Finder |grep -v grep

ls -le /


Also - can you tell us- was this a fresh Leopard install, or an upgrade from 10.4?
posted by TravellingDen at 10:36 AM on August 30, 2009

Response by poster: I think it was a clean install of 10.4 when the drive died, but stuff got restored from time machine, which then required much messy crap remerging the old and new admin users. I think the smb or afp server still shows two identically named home directories for the admin user. I imagine the original upgrade to Tiger was merely an upgrade.


An edited ps -AfO gid command gives :

UID PID PPID C STIME TTY TIME CMD GID TT STAT
501 82 1 0 0:00.09 ?? 0:00.12 /sbin/launchd 501 ?? Ss
501 102 82 0 0:01.25 ?? 0:02.98 /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -p 501 ?? S

ls -le / gives :

drwxrwxr-x+ 119 root admin 4046 Aug 30 10:11 Applications
0: group:everyone deny delete
-rw-r--r--@ 1 root admin 3584 Jun 22 17:46 Desktop DB
-rw-r--r--@ 1 root admin 2 Mar 4 20:16 Desktop DF
drwxrwxr-x@ 16 root admin 544 Mar 4 01:58 Developer
drwxr-xr-x@ 11 nyarlathotep nyarlathotep 374 Aug 26 22:35 Downloads
drwxr-x--- 19 games wheel 646 Aug 28 11:18 Games
drwxrwxr-t+ 60 root admin 2040 Mar 18 08:12 Library
0: group:everyone deny delete
drwxr-xr-x@ 2 root wheel 68 Sep 23 2007 Network
drwxr-xr-x@ 10 nyarlathotep nyarlathotep 340 Jul 19 10:59 Public
drwxr-xr-x@ 4 nyarlathotep nyarlathotep 136 Dec 30 2008 Sites
drwxr-xr-x 14 nyarlathotep admin 476 Apr 10 23:50 Software
drwxr-xr-x 4 root wheel 136 Aug 16 12:42 System
drwxr-xr-x 6 root admin 204 Mar 27 23:00 Users
drwxrwxrwt@ 3 root admin 102 Aug 30 23:18 Volumes
drwxr-xr-x@ 40 root wheel 1360 Aug 16 12:38 bin
drwxrwxr-t@ 2 root admin 68 Sep 23 2007 cores
dr-xr-xr-x 2 root wheel 512 Aug 30 22:16 dev
lrwxr-xr-x@ 1 root admin 11 Jan 1 2001 etc -> private/etc
dr-xr-xr-x 2 root wheel 1 Aug 30 22:16 home
-rw-r--r--@ 1 root wheel 10367028 Aug 11 10:48 mach_kernel
-rw-r--r--@ 1 root wheel 10822172 Aug 11 10:48 mach_kernel.ctfsys
dr-xr-xr-x 2 root wheel 1 Aug 30 22:16 net
drwxr-xr-x@ 4 root admin 136 Oct 2 2007 opt
drwxr-xr-x@ 7 root wheel 238 Mar 3 22:23 private
drwxr-xr-x@ 66 root wheel 2244 Aug 16 12:39 sbin
lrwxr-xr-x@ 1 root admin 11 Jan 1 2001 tmp -> private/tmp
drwxr-xr-x@ 14 root wheel 476 Apr 14 14:15 usr
lrwxr-xr-x@ 1 root admin 11 Jan 1 2001 var -> private/var
posted by jeffburdges at 2:53 PM on August 30, 2009

Response by poster: What happens if you make yourself a /foo, chown blah:blah /foo, and chmod 750 /foo where blah is a non-admin user & non-wheel group on your system? You won't be able to access /foo from bash, but can you still access /foo from Finder?
posted by jeffburdges at 2:57 PM on August 30, 2009

I've just tested this on a couple of Leopard systems, and a Snow Leopard system, and the folder shows up with a red 'no entry' badge in the Finder, and if you try and open it you get an error dialog saying, 'The folder "testpermissions" could not be opened because you do not have sufficient access privileges.'
posted by chrismear at 2:59 PM on August 30, 2009

drwxr-x--- 19 games wheel 646 Aug 28 11:18 Games

The directory's group owner is the wheel group, which has read and execute access, so as a user who is also in the wheel group it's expected behaviour that you should be able to list the contents of the directory.
posted by chrismear at 3:01 PM on August 30, 2009

Oh no, wait, that's a red herring, because a standard Administrator account isn't part of the wheel group. Ignore my last comment.
posted by chrismear at 3:10 PM on August 30, 2009

Response by poster: Oops! I had /Games owned by games:wheel when I did ls -le /. It now reads :

drwxr-x--- 19 games games 646 Aug 28 11:18 /Games

But holy shit! I just rebooted after installing Apple's newest security update and the problem disappeared! I swear I checked all the above commands, restarted finder, and rebooted, all to no avail. I've had all sharing except bluetooth and sshd disabled too, btw.

Any chance this involves some funky Apple caching which got cleaned by the upgrade? Oh, but Finder now responds immediately to chmod 755 /Games and chmod 750 /Games.

I did kinda notice this security update seems highly non-specific, maybe somebody just fucked up adding this "feature", but they just now removed it.
posted by jeffburdges at 3:13 PM on August 30, 2009

Response by poster: Yes, I get exactly that error not that I've installed the security upgrade.

I'd previously noticed that Finder sets the group to wheel if you disable group access from the command-I menu, which incidentally proves that Finder has wheel group access somehow. I'm sure that's why the group said wheel when I did ls -le /, btw. I'm curious if Finder no longer does this post security upgrade.
posted by jeffburdges at 3:19 PM on August 30, 2009

Response by poster: Ahh, no, Finder still sets the gid to wheel if you delete the group entry from the command-I menu, but doing so requires your admin password, so no security issues there.

Oy! It seems it still doesn't know the nyarlathotep group is the group of the admin user! I must have missed even more stuff when I merged those two admin accounts. :(
posted by jeffburdges at 3:26 PM on August 30, 2009

Response by poster: Finder, System Preferences, etc. obviously have this whole sudo like system for executing commands as root. So maybe I'd previously given it sudo access which it hadn't dropped correctly and the security update fixed that bug.
posted by jeffburdges at 3:29 PM on August 30, 2009