Mac OS X Local Privilege Escalation Vulnerabilities

Question

Yes this has happened to me
I found out about it on this site:
http://projects.info-pull.com/moab/MOAB-15-01-2007.html
It effects desk utility.
If you have the below when you check you disk permissions
Determining correct file permissions.
Group differs on ./Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool, should be 80, group is 0
Group differs on ./Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy, should be 80, group is 0
Group differs on ./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool, should be 80, group is 0
There is a work around but I am not sure if I know how to do it. Can any one write me a step by step guide. IE open terminal cd into so & so that sort of thing. Also is their work around sound or just some other vulnerabilities.
Please check out the link before answering.
Thanks in advance
PS Am I worried no not really we can only learn from these things

Answer 1

This "exploit" or whatever you want to call it is absolutely ridiculous, in my opinion.
"Multiple binaries inside the /Applications directory tree are setuid root, but remain writable by users in the admin group (ex. first user by default in a non-server Mac OS X installation), allowing privilege escalation. A malicious user can overwrite the binaries and perform a disk permissions repair operation via the diskutil tool, effectively setting back the default ownership and permissions (root setuid)."
The file at "/Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool" is indeed a SetUID root helper tool which the Activity Monitor uses. It's owner is root, with a group of admin. Its parent folder is owned by root with a group of admin.
A "Standard" non-privileged user, or in other words, a user for whom the "Allow user to administer this computer" checkbox isn't checked in System Preferences, cannot do anything to alter the pmTool. When that checkbox is enabled, the user is part of the "admin" group. Since the pmTool is only writable by its owner "root", or by a user who's part of the "admin" group, a standard user can do nothing to alter it. Since the parent directory, /Applications/Utilities/Activity Monitor.app/Contents/Resources/, is only writable by its owner "root", or by a user who's part of the "admin" group, a standard user cannot remove, add, or replace the contents, including the "pmTool".
So what's left of this "exploit" is that a user that's an administrator could replace or modify the pmTool and use Disk Utility's Repair Permissions feature to "blindly" turn this malicious replacement executable into a SetUID root tool. They could then use this tool to wreak havoc on the system.
My only comments are:
1) Duh.
2) Why the heck would you want to go through this convoluted procedure just to create a (malicious?) SetUID root executable? If you're an admin, there are much simpler methods available.
If a user is an administrator, all they need to do to create a SetUID root tool is enter the following in the Terminal:
sudo chmod 4755 /Users/mdouma46/Desktop/myMaliciousSetUIDTool; sudo chown 0:0 /Users/mdouma46/Desktop/myMaliciousSetUIDTool
Just as effective, without all the convoluted "psuedo-exploit" stuff.
So, where exactly is the exploit now?
Dual 2.7GHz PowerPC G5 w/ 2.5 GB RAM; 17" MacBook Pro w/ 2 GB RAM -   Mac OS X (10.4.8)