Opinion: Apple's unforgivable DNS delay

Macworld - For the entire history of Mac OS X, Apple has had a grand time poking fun at Microsoft about a lot of things, but the company has made a point of getting its licks in over its rival's track record with security. The malware problem, the effortlessness with which Windows XP was attacked via Internet Explorer and other vectors -- oh, what a fun time Apple had.

However, through the Windows XP and Windows Server 2003 life cycle, a funny thing happened. Microsoft really listened to the criticism, took it to heart, and started not just saying it took security seriously, but showing that it did. We can argue about how annoying some of the implementations have been, but the fact is, Microsoft learned. While the idea of a "Patch Tuesday" may seem odd to a home user, for a network administrator, having advance notice of upcoming patches is a good thing.

But what about Apple? Well, on a very basic level, Apple got lucky. The flavors of BSD Unix have always had a good level of security, Unix itself is designed reasonably well from a security point of view, and, up until Mac OS X 10.4, Mac OS X was not able to really handle high-end server roles. So, Apple's default stance of "We'll tell you what you need to know, when you need to know it, and you'll like it" wasn't a big deal. But it wasn't good. When you report a security issue, you want -- no, you need -- open communication. Getting told, "We're looking into it" or "It's already been reported," or worse, "Apple takes security seriously, but we don't comment about unreleased products" is... well, frustrating is the best word that I can use in a family publication.

A lot of people in my line of work had been predicting that, at some point, Apple's attitude toward security and the company's opaque nature were going to eventually bite it in the keister -- and hard. It was just a matter of when. But when it happened, it would put a severe hurt on the goodwill Mac OS X had created over the years.

Welcome to "when."

As reported by Rich Mogul and Glenn Fleishman in TidBits (and hundreds of other sources around the Internet), security researcher Dan Kaminsky accidentally discovered a technique whereby an attacker could compromise DNS servers, (part of the essential functionality of the Internet), via what is known as cache poisoning. This technique allows an attacker to change, or "poison," the caches where DNS servers store the data that allow you to use, for example, www.apple.com to get to 17.112.152.32.

So, let's say you want to get an update to an application. You enter in a URL, say www.goodvendor.com, and connect to that site to download the update. The problem is, the DNS server you use -- say, your ISP's or your own -- has had its cache "poisoned," so while you explicitly typed in the proper URL, you end up at some other server; instead of downloading the correct, safe update, you download a Trojan horse and install it, because you think it's safe. While attacks on DNS servers have been around for a while, this vulnerability made such attacks far easier to pull off than they previously had been.

This kind of attack makes most of the ways you detect phishing sites useless, because the URL will be the correct one, not some "almost" correct one. You'll just get rerouted to the wrong place. This is not theoretical either -- there are active exploits for this right now.

Because everyone who uses the Internet relies on DNS in a way that is the very definition of the term mission critical, and given the relative ease with which this vulnerability can be exploited, Kaminsky and other people -- like Paul Vixie, who helped create BIND, the software that pretty much every Unix-based OS uses for DNS -- took immediate action. Kaminsky, Vixie, and others, including the U.S. Computer Emergency Response Team (CERT), privately notified all affected vendors, including Apple, by May 8; Apple was specifically notified on May 5. They then waited two months until July 8 to publicly notify the rest of the Internet community.