Home » Industry Watch » Coldspots
AdminAuthorizationGetting root without authorisation on OS X? It's not new.
[Many thanks to Brian for providing the link.]
The .SoftwareUpdateAtLogout behaviour of both Safari 4.0.5 and OS X 10.6.3 has caused a great deal of concern. But it turns out this is not something new. Adam Knight wrote about it back in September 2006.
The Installer.app AdminAuthorization key is not the same as the RootAuthorization key.
'The distinction between the AdminAuthorization and RootAuthorization keys is, simply, whether or not the admin user is prompted for a password; the end powers are exactly the same and it is up to the creator of the package as to if he will be kind enough to ask for a password.'
The implication is clear: Apple can 'get root' without the help of the local user or administrator. And they've had this ability for quite some time.
But those keys are in text files which any user with any privilege level (or lack thereof) can hack into.
'A secondary problem is that even packages that have been created with the RootAuthorization key as a precaution can be modified afterwards to use AdminAuthorization and can then be installed without the administrator's password if the account has been left logged in.'
How can this work? Adam explains the procedure.
'When a user opens an installer package set to require administrative privileges to install, Installer will check and see if the current user is an administer of the computer. If so, the Installer program will run the entire install process, including any pre- and post-flight scripts/programs as the root user without prompting the user for the administrator account's password.'
The implications are severe - much more so than most people have heretofore realised.
'By using this method, an individual could open a properly-formed Installer package and open themselves up to attack. Similarly, an individual could sit down at any logged-in station and circumvent local password requirements for creating a new account by using a script in the package to create the account, even if the user is using the option in the Security preferences to lock System Preferences when first opened in order to prevent such behavior as this comes in from another angle entirely.'
In plain English: anyone at any time has been able to hack into any Mac anywhere as a root user.
Adam went on to create a 'proof of concept' to make sure he'd understood the implications correctly.
'To demonstrate this, I created an installer package set to require only Administrator access that echoed its user ID to a temporary file in both the pre- and post-flight scripts, replaced the /etc/sudoers file with a version that requires no password for any existing admin to become root, and then added a new account and added it to the admin group. I opened the package and was able to run to the end of the package with no prompting at all while logged in as an administrator and all the scripted actions were performed as root.'
The reported user in both scripts was root.
Adam also used nicl to add a new user to the wheel group. It worked.
He was also able to hack the sudoers file without authorisation.
'This demonstrates that a properly-formed Installer package could be used to insert user accounts with administrator rights and change root-owned system configuration or binary files without prompting the vast majority of Mac OS X users for a password of any kind.'
Adam recommends not using the admin account unless absolutely necessary. Also: be very careful of installer scripts and always inspect their contents.
[Apple technology has since changed but Installer.app configuration files still reveal what's going on and Apple can still 'get root' without authorisation.]
Why This Matters
Adam's summary.
- All promotion of power to root must require a password. This is a fundamental security rule.
- The user's presumption for Installer packages is that if no password is required then it's not changing root-level items. In this case, a package can be created that gives the appearance to the majority of users of installing a user-specific package but then is able to run a post-flight script as root to open the machine to attack or otherwise alter system files.
- In high-security environments where root access is restricted with a custom sudoers file, but junior administrators are given administrator GUI access for various reasons, this method could enable privilege escalation for those junior administrators by allowing them to replace the sudoers file.
- Users walk away from their computers regularly for bathroom breaks or coffee. During that time someone could approach with a USB key and run a specially-crafted package to add an administrator account and then leave, never needing the administrator password to gain access to the machine.
- Buggy, malformed, or malicious installer packages can wipe out entire drives without authorisation of any kind.
Apple keep telling the world that they take security very seriously. When have they done this?
Special Links
Rixstep Coldspots: .SoftwareUpdateAtLogout
Digg: How a Malformed Installer Package Can Crack Mac OS X
Mac Geekery: How a Malformed Installer Package Can Crack Mac OS X
'I didn't have to enter my password to update. Is this typical for everyone?'
- 'zapblast' at the MacRumors forums
'The media buzz over Opener went on the better part of a month and was then forgotten, but the fact remains that it is the single biggest security hole ever in the history of modern operating systems. No other operating system has ever offered such effortless escalation to superuser.'
- Rixstep Industry Watch on Opener 3.9
|