Slashdot Mirror
Apple Clients Still Vulnerable After DNS Patch
Glenn Fleishman sends word that SANS Institute testing indicates that, even after installing Apple's latest patch for the DNS vulnerability, Leopard desktops (not servers) are still vulnerable — or at least perpetuate risky behavior that makes exploitation easier. This matters because "With servers rapidly being patched worldwide, it's likely that the low-hanging fruit disappears, and vectors [will be] designed to attack massive numbers of clients on ISP networks."
Since Apple themselves stated the patch was for BIND, and that only people running Mac OS X Server would likely benefit from it, I am not surprised that it didn't change the workings of the client.
Ironically, the word ironically is often used incorrectly.
Um...I wrote the article, Space Cowboy? This article was revised after initially being posted as I received more information. Dan Kaminsky is the only one who currently knows the full scope of client weakness, but it's out there, so we revised our article to be clearer about the known knowns and the known unknowns!
Freelance tech journalist for the Economist, MIT Technology Review, Macworld, and others
The Apple updates include a patched version of BIND for all 4 versions (standard and Server for both 10.4 and 10.5) but it is rather uncommon for non-server machines to be running BIND. Instead of having a local caching-only daemon running, they use the system's resolver library and the lookupd daemon that aggregates multiple name services and provides a unified cache (kinda like Solaris' nscd but not broken.) The system resolver uses ephemeral port numbers picked by the system for its DNS queries, and like all classic BSD systems, MacOS assigns ephemeral port numbers sequentially. This means that while Apple could have put port randomization into their libresolv, that would be a 2nd-rate solution. The right solution is to change the socket subsystem so that ports handed out when bind() is called with the port set to 0 are selected pseudo-randomly instead of sequentially. That change is easier said than done, and FreeBSD proved it a couple years ago. It looks like Apple decided not to push out that level of change fast or to hack up a temporary fix just for the resolver.
That's a perfectlyrational choice. The attack Kaminsky has described requires that the attacker trigger the target resolver to send DNS query packets to somewhere that the attacker can see them and hence find out the port number being used for queries. The canonical example of this is to have IMG tags on a web page pointing to a hostname resolved by a DNS server under the control of the attacker. That sort of approach is useless against the MacOS resolver, because it is a non-recursing stub. It only makes DNS queries to the recursive nameservers that it is configured to use, so it cannot be drawn into sending packets off to random bad guys for inspection. An attacker without a tap into the packet flow between the target and his nameservers has it just as hard as he would in attacking a patched nameserver. In addition, it may be that the lookupd cache that the stub resolver feeds may not be subtle enough to be vulnerable to the Kaminsky attack.