|
Apple has, it seems, always been willing to sacrifice security for the sake of user-friendliness. The earlier Mac OS releases didn't have any sort of login security at all. Turn on the machine and you were automatically in control, with the equivalent of administrator privileges from the get-go. Later, they made some attempts at improving their security, most of which were somewhat half-hearted and often easily defeated. OS X appeared to be a big step in the right direction, with support for required logins, network login authentication, encryption, etc. The Mac hardware even enabled the owner to setup a firmware password to lock the machine down further. This article describes an attack which, under the right set of (probably common) circumstances would give someone complete and total control over someone else's Mac (and potentially their data!)...
This information has been tested on Power Mac G4 systems configured without a firmware password and with the Mac OS X 10.4 installation DVD. It may apply to Mac OS X 10.3 and earlier but this has yet to be investigated. If the computer in question is on a network that supports NetBoot or Network Installs of Mac OS X 10.4, gaining root access to a machine is as simple as the following steps: - Restart the machine.
- Hold down the "N" key to boot from the network. (If NetBoot isn't available or is secured properly, insert the OS X 10.4 installation DVD and hold down the "C" key instead of holding down the "N" key.)
- When the OS X Installer screen appears, go to the "Utilities" menu and select "Reset Password".
- Click the icon for the machine's startup disk.
- Select the account you want control of (e.g., "root").
- Enter a password of your choice to be assigned to that account.
- Enter the password again in the confirmation box.
- Reboot the machine from the original start up disk. You can now login as the account selected in step 5 using the password you chose in Step 6/7.
If there is a local "root" or "administrator" account on the machine (which is likely to be the case a majority of the time), you'll have full and complete control of the machine and its data - except that which is stored in the FileVault and encrypted. Protecting Against This Vulnerability on a Personal Mac
For personal machines, setting a firmware password can provide sufficient protection against the vulnerability. An attacker would need to be able to erase the firmware password in order to be able to boot the machine from a CD/DVD or the network. An attacker with that level of skill and access to the machine is probably going to get into it anyway, apart from this flaw.
Further protection can be provided by using the FileVault software and a strong encryption password. This should lock down your critical data and make it very difficult, if not impossible, for the data to be accessed. Protecting Corporate/Lab/School Macs
It's not very practical to employ firmware passwords in a corporate or network setting, since there is only one firmware password for the machine. Anyone who needs to be able to boot a machine will need to know that firmware password in order to boot it. The more people who know that password, the more people who can make use of the exploit mentioned above.
The FileVault software can protect the data on the machine from theft, but won't prevent someone from using the above exploit to damage the machine or otherwise compromise its integrity. The NetBoot function on the server can be secured by locking down the images so that they're only accessible if the user has the right ID/password combination. Unfortunately, this still does not stop an attacker from inserting the CD/DVD and booting from that. For some organizations, removing the CD-ROM or DVD drive could further secure the machines, but even this won't stop an attacker who boots the machine from a USB or Firewire device. Another option is to ensure that there are no local accounts on the machine, and that all login is authenticated through some more-secure external source such as a Windows 2003 Server Active Directory Domain, a UNIX NIS Server, etc. If there are no local accounts (or at least no local administrator/root accounts), this vulnerability is less severe, since an attacker can at best only get into a local account. But this isn't a very practical solution either, since it would mean the machine is inaccessible until it's hooked to a working network that is configured properly to provide the needed authentication. If the authentication server goes down, the clients are all effectively locked out.
Related Blogs:
Related Links:
|
