Opinion: Apple’s unforgivable DNS delay

For the entire history of Mac OS X, Apple has had a grand time poking fun at Microsoft about a lot of things, but Cupertino has made a point of getting its licks in over Redmond’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 lifecycle, 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 POV, 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 towards 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 accidently discovered a technique wherein 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 “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 the URL, i.e. “http://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 URL. You’ll just get re-routed to the wrong place. This is not theoretical either—there are active exploits for this right now.

Considering that everyone using the Internet relies on DNS in a way that is the very definition of “Mission Critical”, this vulnerability and the relative ease with which it 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 United States 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.

By July 8, guess who was the only OS vendor to not have patched their DNS? If you guessed “Apple,” you’re sadly correct. To add to the frustration, inquiries by quite a few Apple customers only brought the standard PR boilerplate.

According to everyone I’ve talked to about this, the patch itself is trivial to apply. The only known complication is that it may slow down DNS for heavily used servers.

As I type this on Thursday, July 31, there’s still no patch from Apple. Even if one comes out just after this article is posted, it would still be almost three months since Apple was first notified of this issue. In that time, Apple has been the only vendor not to release a patch or clearly communicate the reasons for the delay to its customers. Unless you have back-channel contacts at Apple, you have only been told the standard “Apple takes security seriously” line, if you were told anything at all.

To put this into perspective, less than a week after launching MobileMe, Apple had not only apologized to customers for the problems with that launch, but issued extensions of service to help make things better. When Apple customers had some problems with consumer-grade e-mail and calendar synching, Apple took nigh-immediate action. Yet, given months of lead time on a vulnerability that makes every unpatched Apple DNS server dangerous to anyone using it, there was nothing. No mea culpa, no “here’s what we’re going to do to fix how we respond to vulnerabilities in the third-party products we use in Mac OS X to make sure this never happens again.” Just the standard “we’ll tell you what you need to know, when you need to know it, and you’ll like it” spiel from Apple. This is not a major update to apply, but Apple will be the last OS vendor affected to release a patch. Yet, Apple has managed to make major fixes to MobileMe and release an update to iTunes.

There is no level on which Apple’s conduct here is acceptable. It speaks of a security-vulnerability review process that is broken. It shows that either Apple is completely unaware of what is going on with the software it bases its OS on, or that the company knows, and just doesn’t care, because after all, iTunes users are having problems. Even if the patch is released today, that’s not going to be enough. Because if the underlying process is not fixed, this will happen again. And again. And keep happening until it causes Apple enough pain that it finally fixes the process.

Apple needs to not only release the patch, but issue a public mea culpa that apologizes, and outlines the way the process(es) that allowed this to happen will be fixed. If that does not happen, then as an IT professional, I will be required by my own professional ethics to begin a serious review of any uses of Apple hardware on my network that faces the public Internet, and see if those machines can be replaced by a similar product from another vendor that not only claims to take security seriously, but actually takes the actions to show it does. I would recommend that anyone else in my line of work do the same.

In the last few months, Apple has, by inaction, silence, and arrogance, shredded the security goodwill it had earned over the last few years. It will take years to regain that goodwill. Ask Microsoft how hard it is to regain goodwill once it’s gone.

The worst part of this is that had Apple not “been Apple about it”, the entire problem would have been a non-issue. Instead, it’s made a mockery of Apple’s claims of being responsive to security issues. I sincerely hope the Windows team is trash-talking the heck out of Apple and OS X over this, because in this instance, it’s absolutely justified.

[John C. Welch is a senior systems administrator for The Zimmerman Agency, and a long-time Mac IT pundit.]

Subscribe to the Apple @ Work Newsletter

Comments