Musings

DHCP Vulnerability in MacOSX

Here’s a fun one: a remote root hole in MacOSX, just in time for Turkey Day. It’s not a “new” vulnerability, in the sense that rogue NetInfo servers were a potential problem way back in NeXTStep days. Now we can add rogue LDAP servers to the list, but the idea is the same. What makes the exploit “new” is the prevalence of MacOSX laptops, and WiFi, which make it far more likely that you’re going to boot up your MacOSX machine in “hostile” environment, where one of these rogue servers might be lurking on the same subnet.

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.

…

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 …

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.

The fix, as detailed in the “Workarounds” section of the Advisory is to turn off the automatic binding to a DHCP-provided NetInfo/LDAP server. “Off” shoulda been the default setting from the 'git go.

It is now …

Update (11/26/2003): Apple has posted a Knowledge Base article with the workaround.