« Why Windows, and the “Task - based interface” doesn't work the way its fans think it will | Main | On Women... »

Well, thanks to William Carrel, and his advisory, the Mac community is now getting slings and barbs from the PC community, who are now starting to say "See...Macs are vulnerable too, ha-ha!" In fact, there's been one article in PC World that has almost that exact Title: "Eureka, Mac's are not invulnerable", by Lance Ulanoff. Lance has a fine time dishing up all the crow he expects Mac users to eat. In fact, he ends his article with "...How cocky are you feeling now, Mac elite? Hmm. Suddenly it's gotten pretty quiet around here."

Lance's apparent inability to deal with the proper use of an apostrophe aside, he's missing many points in his "neener-neener" article. First of all, the Mac community has never, (Well, not the sane members) claimed that Macs are invulnerable to crackers. What they have claimed, and correctly so, is that the Mac OS is far harder to crack than Windows. But since Lance and some others are having a good time with their new-found realization that the Mac OS is a computer operating system, not a magic spell, let's take a look at the problem, something Lance and a few others haven't bothered to do.

The heart of the problem is that by default, the ability to bind to an Open Directory system that is discovered via DHCP is enabled in Mac OS X. This is nothing new. Being able to bind to a directory with no manual configuration out of the box has been a feature of Mac OS X since it was still NeXTSTEP. This is something that is a great convenience to any network administrator, the ability to have a machine be a part of your directory structure with as little work as possible. Since DHCP allows for the integration of LDAP as a part of the spec, Apple takes advantage of this, and so you have LDAP binding via DHCP, automagically.

That's an important point, so let's stress it.

Apple's implementation is in compliance with RFC 2131, the DHCP RFC.

They are not doing anything non-standard, nor are they extending the standard in a proprietary fashion, ala Microsoft and Kerberos. The reason this is important is because it points out the real source of the vulnerability. Not Apple's code, or really even their implementation.

It's the DHCP standard itself. DHCP, as defined by RFC 2131, has no security. None. In fact, I'll quote you the entire security section of 2131, section 7:

"7. Security Considerations DHCP is built directly on UDP and IP which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure. Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems. Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients."

Just in case you aren't getting the deeper implications of this: Anyone running DHCP has a security hole on their network. Now, there are ways of restricting who can get a lease from a server. But that's not security. That's access restriction. That's no more security than not allowing people in the door who don't work there.

It's kinda security but not really. You still aren't verifying that the server you're getting your configuration information and settings from is the server you're supposed to be getting them from. You plug into the network, (virtually in the case of wireless) and get your configuration from the first server you find. If it's the right one, hooray! If it's the wrong one, you're screwed.

Any competent network administrator knows this, or should. That's why you make sure that your users know there are dire consequences for setting up a rogue DHCP server. It also doesn't take long to find a rogue DHCP server on a network. Usually, about five minutes after it goes up, you get calls from users complaining the Internet is broke. (Amazing how a human being can crawl three miles after their arms are ripped out, but five seconds without Amazon, and you'd think they were on the wrong end of the Spanish Inquisition.) So, who's at risk from this lack of security?

Well, everyone using DHCP is. No, really. I'm serious. The only difference to Apple is that they also use DHCP for LDAP discovery. But even if all you use DHCP for is IPv4 addressing, and DNS, you're still at risk on a rogue server, because that server now has your IP address, and your MAC address, which can be of great convenience to a cracker.

But the truth is, Apple's not that unique in using DHCP for more than just assigning TCP/IPv4 information. Microsoft does it too, in particular for RIS, or Remote Install Services. This is a process by which you can boot from your network card, and if you have a properly configured DHCP / RIS server on your network, the network card, (NIC) binds to the RIS server, and commences to installing software. This can include the OS. RIS can repartition your drive, and format your drive too. It can set the Active Directory domain your PC binds to. It can do this all unattended. All it needs is a DHCP server with the right settings. There's no picking the DHCP RIS server. You don't verify that you're on the right server. You reboot your machine from a PXE-Enabled NIC, and you're RIS'd.

Why would anyone do this? Heck, why doesn't Apple do this now? I mean, NetBoot's almost there. Look, I've used RIS. It rocks. It's amazingly handy. As a network administrator, I always cringe at what PC vendors decide I need on my machine by default. But face it, even with a fast external drive, reconfiguring a hundred machines sucks. You can only do one or two at a time. Not with RIS. WIth RIS, you boot from the NIC, and go start the next machine. RIS lets you customize a hundred machines in the amount of time you can do one manually. What network administrator doesn't love RIS? Only the ones who don't know about it. But what happens if someone inserts a rogue DHCP RIS server on your network, and you don't realize it?

Well, you're screwed. Not only does the cracker own that machine, but they have their own custom OS installed. All it takes is for that machine to be set up for real evil, and your network could be quickly hosed, hard. So do you never use RIS or take advantage of PXE booting? Don't be silly. You simply spend some time making sure that you don't have rogue servers on your network. You do the basic security things you should have been doing before the Carrel warning.

So now we have Microsoft, (and Intel too, PXE is their baby) creating a potentially bigger problem. So how do they fix this? Well, honestly, right now they can't. The problem isn't DHCP, RIS, or Open Directory. It's that DHCP, the basis for all this convenience is insecure. Now, Apple, or Microsoft, or Intel could create a bunch of proprietary extensions to DHCP to provide for authentication of the server to the client. Of course, that creates multiple incompatible DHCP implementations, and the advantages of DHCP quickly die off. There is a proposed standard for securing DHCP. It's RFC 3118, and its been in work since 2001. It is designed to allow for authentication of servers to clients and vice versa. Now, 3118 isn't the ultimate answer, but it's a darned good idea.

However, even if it were ratified the second you read this article, it would still take a massive effort on the part of hardware and software manufacturers to rewrite and update both DHCP server and client software and implementations, along with management software. So it would be a year at best for updates, and that's assuming that there would be no bugs, etc. I'm pretty sure that Apple is taking a hard look at this, but in all honesty, the best thing they can do is work with the IETF and other standards bodies to fix the real problem, aka the lack of security in DHCP. What they should not do is create some bizarro DHCP implementation that only works right with Mac OS X - based DHCP servers. They've correctly pointed out the simple way to disable the DHCP discovery of LDAP servers. They may consider turning that off by default in the future, but that's got implications of its own as well.

Look, if you use DHCP, you need to read RFC2131 and understand the risks. You need to communicate with your peers and keep up on new techniques of discovering ways to subvert DHCP networks. You need to prod your DHCP server and client vendors to help get RFC 3118 ratified and implemented. Carrel didn't find anything "new". They found something that has always been there, but they hadn't thought about. So while they may get points for highlighting the computing world's reliance on an insecure protocol, they lose points for acting like they're some kind of hero. Because if Apple has a "massive security hole" because of DHCP, then so does Microsoft, Intel, and everyone else. And they always have.

Comments