Com.apple.SystemLoginItems.plist Exploit

From MacShadows KB

History

A poorly documented feature of the OS X login process involves the system launching applications listed in the file /Library/Preferences/com.apple.SystemLoginItems.plist with root privileges. At the time of writing, the file itself does not exist by default on all versions of OS X through 10.5.5 and the directory /Library/Preferences is writable by members of the admin group. When a new Mac is first used, the automated setup process requires the user to create a user account for normal operation of the system. That account is a member of the admin group by default. As a result, most Macs are susceptible to a locally run trojan exploiting this vulnerability to gain root privileges without user authentication. No trojan is required however - any person with access to an already logged in admin group member's user account session via GUI or command line can create the file.

Exacerbating this issue is the lack of any automatic notification to the user when or that the file has been created or modified or a reference to a program has been added to the file. The entries in the file are not displayed where a user might expect to see such information such as in System Preferences > Security or System Preferences > Accounts even though user login items are found in System Preferences > Accounts. As system login items have no comparable feature users may never see how programs referenced in the file are run (as root) during login.

This 'feature' was previously used by utilities such as Timbuktu; it was still a vulnerability back then too.

This vulnerability was mentioned as one method of escalating privileges during a discussion at the MacShadows forum about creating a Trojan horse. Various members participated including Lokin; Oktane; andrewistheshit; and callmenames. That discussion resulted in functional shell script and AppleScript programs exploiting this vulnerability, among others.

Usage

The file does not exist by default. A member of the admin group may create the file /Library/Preferences/com.apple.SystemLoginItems.plist

Example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>AutoLaunchedApplicationDictionary</key>
    <array>
        <dict>
            <key>Hide</key>
            <true/>
            <key>Path</key>
            <string>/Library/Caches/.trojan.app</string>
        </dict>
    </array>
</dict>
</plist>

The plist file can be in either text or binary format. The file can be edited manually (with a text editor and plutil) or with programs such as Apple's ADC application "Property List Editor" included in development software found on OS X install media.

Solutions

Because the directory /Library/Preferences remains writable by members of the admin group (and should for proper operation of some current software) there is no simple fix for this issue if users continue to routinely use an account which is a member of the admin group as the account for regular operation of their computer. A new 'standard' user account can be created via System Preferences > Accounts and which will not be a member of the admin group by default and thus even if the user were to run a trojan attempting to create or modify the file, it should not have sufficient privileges to do so. However, users should keep in mind that any program which they run may intentionally or otherwise alter or delete any files owned by their own account. Regular reliable backups, preferably rendered read-only after creation, are the best defense to data loss or corruption.

One suggested workaround - given the vestigial nature of the com.apple.systemloginitems.plist file on modern systems - is to create an actionless file of that name, that does not start any applications, or perhaps is completely empty. Make this file read-only, or chown it to root, and no malware should be able to edit or replace it without at least resulting in an authentication dialog.

But this suggestion does not work either because deletion of the file cannot be prevented unless the directory /Library/Preferences is protected. Making an empty plist that's read-only and owned by root does not help at all. [It seems that setting the user-immutable [uchg] and system-immutable [schg] flags on the file using `chflags` prevents it from being deleted.]

Those who suggest this workaround - even here - are fooling themselves and this false sense of security may be more harmful than the original situation.