Dan Kaminsky's Blog

Apple should be held accountable just like any other company would be. Macworld wrote an excellent article on the subject:

http://www.macworld.com/article/134793/2008/07/apple_dns.html

Chris Crocker – LMAO!

Why the stupid Britney Link?

Well…it appears that Apple DIDN’T patch BIND after all, on the client side at least with no firm answer on the server side…nice Apple…really nice.

@Mando

This is the point of the blog… Dan is saying to leave apple alone because they did the server at least. Unfortunately, it’s not clear from Dan/CERT/ISC what the risk is from the client not being patched compared to the server unless you read/understand the gory details of how Dan’s attack actually works.

I’m with Mando on this one. I also own several Apple products, such as an iPod and a Mac SE/30. Right now, I’m afraid to even listen to my music. (Note: I’m always afraid to listen to music, mostly because I am afraid of man-in-the-middle attacks. I am so disturbed by the idea that someone might be intercepting my music requests and playing back subtly altered songs that I can’t sleep at night. This will be night 241.)

Still, I think I can forgive Apple for forgetting to patch the OS X client and my iPod, given how they raced to get the server patch out the door.

Let’s make sure we all understand what Apple did, since clearly Storms, Kelzer, and others have failed to understand it but published anyway…

They ship all versions of MacOS with some version of BIND. For client versions of the OS, it is switched off but can easily be set up by anyone capable of setting up BIND. They make it relatively easy to switch on and configure in the Server version.

Apple put out updates that included the new ‘P1’ versions of BIND with port randomization for both the desktop (aka “client” ) and “Server” versions of MacOS 10.4.11 and 10.5.3. If you’ve installed the update and need to confirm this, just run ‘/usr/sbin/named -v’ in a shell. Apple did not change the OS stub resolver and they did not implement port randomization in the socket subsystem. This is why the stub resolver is still using sequential ports: it uses a new socket for each query and does not specify the port. That’s not anywhere near as dangerous as having a recursive resolver using a single port or easily predicted ports.

Dan has said that the problem is in the design of DNS and that port randomization is not really a fix, it just makes the guessing game a lot harder. That guessing game has to be made hard with randomization for recursing resolvers because it is fairly easy for an attacker to get a recursive resolver to send him some query packets to look at and analyze for a pattern. There is no way with a stub resolver such as Apple’s to send queries anywhere but where its own config files (usually a simple standard /etc/resolv.conf, but potentially a more complicated setup) say to send queries. The stub doesn’t do recursion, so it doesn’t send query packets (with its predictable port numbers) to arbitrary bad guys based on what a user tries to resolve.

The vulnerability Dan discovered is not that query source port numbers are not randomized. The vulnerability is that DNS queries can be answered credibly by anyone who knows a small number of details about the query (a design flaw in DNS) and that an attacker could reduce that to just brute-forcing the 16-bit transaction ID for a recursive resolver with a fixed query source port because discovering that fixed port is easy and DNS itself tells the world where all of the recursive resolvers will be expecting to get answers from.

Attackers may well get around to targeting stub resolvers, but it is hard to see how using sequential source ports on stub resolver queries really helps an attack based on forged replies. The attacker still would need to get some sample packets from the stub resolver to know where in the sequence to target and what IP address to spoof in the replies, and getting those packets is usually tantamount to have the query packet you want to spoof a reply to, in which case the variability of the source ports does not matter.

Piggy backing off of Bill Cole’s comments, of which I agree – if in a corporate/organization environment, keeping a firewalled local caching server, forwarding downstream, should make the sequential ports on the clients moot – the only way to intercept stub queries, heading to your internal LAN DNS server, would be to breach the network itself. This was also a measure recommended by CERT. Also from CERT:
“Stub resolvers are also vulnerable to these attacks, so system administrators should patch stub resolvers that issue queries in response to attacker behavior and that may receive packets from an attacker.”

As Bill eluded to, most stub resolvers aren’t in positions to issue queries responding to attackers, or receiving packets from them, since they never touch the outside world for requests. This means you only have to worry about the downstream DNS server that your local server is getting responses from and passing onto your resolvers.

I would like to see it patched on the client..but this may be more difficult to rework lookupd and its dependents.