by Greg Neagle
Recently, the site "rixstep.com" published an article
purporting to expose a major security flaw in OS X. The article has since been softened in tone and now acknowledges the additional security that Tiger adds. In reality, this "vulnerability" is nothing new, and nothing to get overly concerned about
Rixstep's claim is that Apple's SystemStarter mechanism, which runs items at system startup, is an attack vector for malware - that "anyone" could install code that runs as root on the next restart.
Let's look at that claim. SystemStarter runs specially constructed Startup Items that can live in one of two places:
Prior to Tiger, /Library/StartupItems didn't even exist in a default OS X install, though installation of third-party software could create this directory. By default, /Library is not modifiable by non-privileged users, so to create this directory, one would need to use sudo or authenticate as an administrator.
Rixstep claims that "anyone" could add items to the /Library/StartupItems directory that would run with root privileges on reboot. This is generally not the case.
On Tiger, /Library/StartupItems exists by default and is modifiable only by root. (Or indirectly by admin users; that is, after authentication.)
Prior to Tiger, /Library/StartupItems does not exist by default, but its parent directory (/Library) does exist, and again, is modifiable only by root. So the /Library/StartupItems must be created by an admin user, or when an admin user authenticates an installer that does so.
Only if the admin or the installer creates /Library/StartupItems with insecure permissions would it be possible for "anyone" to add items to /Library/StartupItems without admin credentials. This is not beyond the realm of possibility, as there are many poorly-written installers that install all manner of files and directories with insecure permissions. But this does not represent a fundamental insecurity in Mac OS X.
Tiger not only provides default secure permissions for /Library/StartupItems, it refuses to run Startup Items that do not have user 0, group 0, and mode 0755. Read this article for more on Tiger's improved security for Startup Items.
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.
Even the additional security provided by Tiger can be circumvented by a poorly-written (or malicious) installer. When you provide your admin credentials to an installer, you are giving it carte blanche to do _anything_ to your system. It could install malware, or simply set the permissions on key directories that would allow malware to be more easily installed by other processes in the future. This "vulnerability" is not limited to or unique to the StartupItems mechanism - once you give an installer root privileges, there's nothing stopping it from modifying /etc/rc, /etc/rc.local, installing LaunchDaemons under Tiger; adding Login or LogoutHooks, or several other ways of running code as root. In fact, many of these things might be necessary depending on what you are installing -- that's why the installer needs those privileges.
The only real defense against poorly-written or malicious installers is vigilance - ultimately you must know what changes to your system an installer has made. Apple's own "Repair Permssions" option in Disk Utility can reset permissions to Apple's recommendations. Tools like radmind make it easier for an administrator to identify the changes made by software installers (or users with admin rights) and to reverse them.
Ultimately, it boils down to the old saying, "Trust, but verify." Don't install things from sources you don't trust, and verify what you do install.
Apple Documentation on startup items and other startup processes on OS X