Mac Geekery

There exists a pretty significant interface problem with the Apple Installer program such that any package requesting admin access via the AdminAuthorization key, when run in an admin user account, is given full root-level access without providing the user with a password prompt during the install. This is even explained in Apple’s Installer documentation as proper behavior. 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.

By creating a malicious package and setting the authorization level to AdminAuthorization in the package, an attacker can modify root-owned files, execute commands as root, or install setuid-root programs without alerting the user that such actions are taking place. The problem is compounded when you consider that over 90% of Mac OS X users run as the administrator user because it’s what the default user created by the system is.

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 and Why

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.

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.

Demonstrated Damage

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.

UID Results

In both of the scripts the reported user was root:

$ cat /tmp/uid 
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 80(admin)

Admin Creation Results

In the post-flight script, I used nicl to add a user and then add the user name to the wheel group, and it worked:

$ nicl . -read /groups/wheel users
users: root haxxor

Sudoers Results

The sudoers file before the run, compared to the version in the package:

$ diff /etc/sudoers sudoers 
20c20
< %admin        ALL=(ALL) ALL
---
> %admin        ALL=(ALL) NOPASSWD: ALL
$

And then after the run:

$ diff /etc/sudoers sudoers 
$

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.

Immediate Solution

Read my previous guide to securing Mac OS X and do not run as an admin user for daily activities.

Moreover, if you must run as the administrator, do not install packages from non-reputable sources without cracking open the package and reading the pre- and post-flight scripts, if you know how. If not, research the product more.

Normally, programs requesting such rights have to obey rules in /etc/authorization to do so. Indeed, it looks like the system.install.root.admin rule is the one that should cover this. However, in the installer.log file there’s a line that indicates it already has the proper rights:

Sep 14 23:43:57 Macintosh : admin auth received to install

I altered the Installer’s stanzas to require the wheel group instead of the admin group and restarted the machine, but the behavior remained the same. Thus, I believe no hacking of /etc/authorization will resolve the issue. I would love to be proven wrong in this regard.

Real-World Use

Parallels is an honest and valid product from Parallels, Inc. It installs itself with an Installer package that uses AdminAuthorization to gain root access to install needed files. However, what it does do, without a password, is install the kernel extensions Pvsnet.kext, hypervisor.kext, and vmmain.kext. Then the postflight script reloads the kernel extension cache and then starts dhcpd for the network interface sharing.

The upside is that they do very well to not require a restart after installing the software. The downside is none of this required a password to get root access.

Long-Term Solution

Apple needs to prompt for a password before any raise in power to root, and the installer is no exception. It would appear that the foundation to do so is in place, but the Installer is going around the normal means and doing something else. That’s unacceptable from a security standpoint. Mac OS X has a powerful security framework in place to protect the users, but it’s only as good as every program that uses it. If someone goes around it and lets someone run arbitrary scripts and programs as root then the whole system becomes insecure.

Run as a normal user. Open files you trust. Stick to that and you’ll be fine.

Why This Matters

1. All promotion of power to root must require a password. This is a fundamental security rule.
2. 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.
3. 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.
4. 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.
5. Buggy, malformed, or malicious installer packages can wipe out entire drives without authorization of any kind.

Why This Doesn’t Matter

1. In a default install, administrator users can gain root access in Terminal by providing their account password to sudo. Since the account already has the power to gain this access, this issue is only bypassing what could be seen as a redundant step, if not for the greater implications mentioned above.
2. It requires user intervention.
3. It requires a malicious package of presumably dubious origin, which should throw warning flags to begin with.

Credit

This was reported in July, 2006, on the Apple Discussion Boards and was brought to my attention by Mac Geekery user pixelslut. The Apple Discussion board states that the issue was reported to Apple and marked as a duplicate/known issue well over a month ago. The tests done here were performed on an iBook G4 running Mac OS X 10.4.7 with all available updates applied.

How a Malformed Installer Package Can Crack Mac OS X