Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

November 27, 2003

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.

Posted by distler at November 27, 2003 12:24 AM

TrackBack URL for this Entry:

0 Comments & 0 Trackbacks

Post a New Comment