Exploit for pre-Tiger systems?

On the heels of recent Mac OS X worms and exploits--some of which have been recently patched--a newly revealed Mac OS X exploit in pre-Tiger systems may allow an application to gain root access after the computer restarts. "Rogue code and trojans resident on OS X boxes prior to Tiger don't have to work overtime to 'get root'. If they're patient and wait, they get it on next boot with no privilege escalation whatsoever. Any process running in an admin account (and sometimes below) can corrupt the OS X boot sequence on such a machine to get arbitrary code to run as root in single user mode." The site provies a "proof of concept" that demos the exploit, which takes advantage of the operating system default settings to check for a (usually non-existant) StartUpItems folder in the local user's Library folder. [updated]

According to the site, the user's Library folder can include information about which items to launch during startup, allowing any trojan application to create that 'StartUpItems' folder and execute arbitrary code. The exploit has been fixed in Apple's latest Tiger OS, but remains in previous versions. The site recommends 'hardening' the user's 'Library' folder to protect pre-Tiger systems.

"The best you can do is to harden /Library/StartupItems as Apple have done in later releases. /Library should be owned by root:admin and have 1775; /Library/StartupItems must exist, be owned by root:admin, and have 0755.

"If anything is found in /Library/StartupItems on boot and the ownership and mode are incorrect, the Tiger boot sequence will refrain from running the code and ask your advice how to proceed. You can defer your decision, disable the item, or go ahead and fix it. If you decide to fix it, it might fix you - so be careful."

Echoing warnings noted here previously, the website warns that Apple's patch for the Mac OS X Zero Day exploit only protects users running Safari and other Apple applications, leaving users of third-party software--such as Firefox, Camino, etc.--vulnerable to execution of code disguised as a "safe" file. Meanwhile, the newly launched Mac OS X Security Challenge, inviting hackers to compromise a designated Mac on the internet, is still in progress, without any compromise, following a previous challenge in which a user was able to compromise the system within 30 minutes using a (provided) local user account.

The new challenge saw many different types of attacks in the first 38 hours, including web exploit scripts, ssh dictionary attacks, and scanning tools such as Nessus as well as two DoS attacks. However, the site notes that "there were no successful access attempts of any kind, including during the 38 hour duration of the test period, nor have their been any claims of success. The host is still the same host and configuration used for the test."

Update: The MacEnterprise project has posted a response to the claimed exploit: "The only scenario in which there is a possibility of installing code that runs as root _without_ having to authenticate as an admin is if a previous admin or authenticated installer has created or modified /Library/StartupItems with insecure permissions, and additionally under Tiger, only if files with root/wheel owner/group and 0755 mode are moved into this directory. While this is a potential scenario, it is not a common one. You can protect yourself now by either upgrading to Tiger (which has been available for almost a year), or ensuring /Library/StartupItems is owned by root, has group wheel, and has mode 0755."

Filed under: troubleshooting