Normally, I wouldn't post about an Apple security update, because they're relatively common and generally attack most of the issues within a period of time that everyone agrees is a bit too long. However, there was a lot of hubub about Apple's "delay" in getting the security patch out for the recent BIND issue that could allow for users to be sent to the wrong sites. This wouldn't have caused me to write, except that after Apple patched the problem, there have been a few articles (no links provided, so as not to give them advertising revenue) that indicate the patch did no good. This is UNTRUE. Full details in the rest of the article.

I understand this is a bit technical, but unfortunately, there's no way around that.

Description of the BIND problem

For starters, let's get out of the way that BIND stands for the Berkeley Internet Name Daemon and is basically the primary server that companies use on the internet to provide a mapping from the "easy to remember' domain names (like www.gaige.net) to not-so-easy-to-remember IP addresses (like 192.148.252.195).

Now that we know what BIND is, what was wrong with it? Well, this particular problem is what's called a "poisoning" attack. It takes advantage of certain predictable behaviors in the way that BIND works to send a massive number of unsolicited "responses" to the server in order to make it think that the IP address for a well-known service is actually a different IP address than is expected. This is mostly useful when you want to poison an oft-requested IP address (such as www.google.com or www.bankofamerica.com). If successful, the user is silently directed at a different Internet server that can do all sorts of nasty things, including steal your banking passwords or present viruses to you.

To get even more technical, there are a couple of numbers that the servers use, one called the sending port number and another called the Transaction ID, that are used to uniquely identify each request sent that is responded to by the server. The key bug was that both of these numbers were highly predictable. The transaction ID was increased by one for every request and the port number also was usually increased by one for each request. As such, an attacker (or "poisoner") could flood the server with a series of packets that used increasing Transaction IDs in order to try and fool the server into believing the responses were valid, hence "poisoning" the view of the internet for that server.

Why is this important?

It would seem on the face of it, that you'd have to try and aim at every single computer on the internet for this kind of practice to be effective. However, the truth is that most computers don't make very complex domain name requests themselves. Instead, they make requests of a "recursive server", which is usually run by their ISP and does the "heavy lifting" of communicating with every other server on the internet on an as-needed basis. As an added bonus, these "recursive servers" reduce the number of requests made to the other servers by storing the results in a cache, and are thus usually referred to as "caching servers." Basically, if 10 users of the same ISP that you're using all ask to go to www.maytag.com (c'mon, the poor guy is lonely!), the ISP's recursive server makes the query once and stores the result for a period of time and answers the other 9 questions without having to talk to maytag about it. As a convenience, every domain (like maytag.com) gets to choose the maximum amount of time that a server can keep the name around before it needs to ask again.

So, if a "bad actor" were to try to divert your ISP so that all queries for maytag.com went to bosch.com (a rival manufacturer of appliances), they could do so by flooding your ISP with faux responses that contain the information that they want to poison the cache with, along with a particularly long cache life. Thus, they could say "go to bosch.com for 5 days" and then every request from a user in your ISP to www.maytag.com would go to www.bosch.com for the next 5 days.

Obviously, this is really bad. Although this problem's been around for a while, the folks who discovered the new exploit had figured out a way to do it without having to try 4 billion tries (the number necessary if things are truly random).

So, Apple's patched the problem, right?

As of August 1, Apple released security updates for 10.4 and 10.5 (but not 10.3 for anyone still running that for purposes of a caching name server). This fixes the port randomization for OS X Server platforms entirely by including a more recent version of ISC's BIND software (the DNS Server used by OS X).

Fortunately, as pointed out in the comments section of Not A Guessing Game post by Paul Vixie, clients are not particularly vulnerable to this problem, because most of them don't cache or don't cache for long. However, he also pointed out that for caching hosts, putting yourself behind a NAT system (which most consumer internet services do, especially if you have a wireless network in your house connected to a DSL or Cable modem) can completely eliminate the benefits of the patches released in the last month. Thus, those with servers behind NAT, you'll need to be particularly careful. Fortunately, most computers behind NAT are neither servers nor caching clients, so they aren't vulnerable to the cache poisoning attack.

Why the "It isn't fixed!" claim?

Good question. Most of this centers around people observing what happens on their Macintosh clients (because I've manually tested 10.4 and 10.5 server and they do the right thing)--basically the Macintosh DNS resolver (the code that asks your next server to do the work for you) does not use port randomization and therefore would be more vulnerable.

Of course, they forget the fact that most people are behind NAT anyway, so it doesn't really matter. But, it would have been nice if Apple had made the change. As Apple's client actually does cache, it's theoretically possible for it to be affected. However, it's very unlikely.