|Home » Industry Watch
Apple's 'Unix' Runs Arbitrary Code on Boot?
Why should a trojan try to 'get root' on OS X? Can't it just wait for the system to restart?
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.
Apple have a number of folders they recognise on system startup, all with the name 'StartupItems'. This folder can be found in several different locations. The one found in the login user's home area is not applicable here: it won't be touched until a user actually logs in.
The one in the system area ('/System') is locked down tight. No one but root can get in there and modify things. Others can be found in the local network.
But the one in /Library is another matter. On systems prior to Tiger, it doesn't exist by default and can be created by an admin account. And then an executable can be placed there to run as root on the next system start.
This means that any halfway clever trojan on such a system needs only to be patient.
Saved by the Tiger?
Apple changed the system configuration with Tiger. /Library/StartupItems is created by default, is owned by root:wheel, and is marked 0755. The parent directory /Library is owned as before but now gets a sticky bit, meaning only items created by the user may be removed.
This effectively prevents code not owned by root from entering the directory and prevents users other than its owner (root) from removing it (in order to create it again).
Systems without this new configuration are still vulnerable: code running at this point of the boot sequence is effectively 'single user mode'.
What's amazing is that in all these years no one bothered to attempt an attack: every OS X box on the planet could have been owned. A great many still can be.
Proof of Concept
The following download will demonstrate if you are vulnerable.
Consult the 'README' inside the package.
- Place the contents of the 'StartupItems' directory in /Library/StartupItems. Do this from a command line: if you get any resistance at all, you're protected. If not, proceed to the next step.
- Reboot if you were able to perform the copy without privilege escalation. On reboot you should find the file 'rooted.txt' in /Users/Shared. The ownership of the file (root) indicates what account created it. If you open the file, you will also see several items listed that only root is capable of listing.
In such case - YOU'VE BEEN ROOTED!
What To Do?
If you're running Tiger, you don't need to do anything. The issue has been fixed for now. /Library/StartupItems is already on your disk and both it and its parent directory are protected.
If you're not running Tiger, then you should do something. 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.
Postscript: Love Letter
Thank you for forwarding this issue to us. Apple takes every report of potential security problems very seriously.
Regarding the content provided at:
As you note, this issue was resolved in Mac OS X 10.4 Tiger.
If there are any issues regarding /Library/StartupItems that are not addressed, please let us know.
What's amusing about the above is that Rixstep never contacted Apple. Read between the lines yourself.
> If there are any issues regarding /Library/StartupItems that are not addressed, please let us know.
Yes, one: people would like to know if you alerted them of this vulnerability any time in the 23 months between March 2003 and the fix in April 2005. They seem to think you did not. If you had a URL that went out we could publish it to get you off the hook.
But there is no such URL. And therefore there could be no reply. And '23 months' is really cutting slack: there are corroborated reports Apple were aware of the vulnerability for at least five years.
Learning Curve: Input Managers — The Cure
Apple: Mac OS X 10.4: About startup items security