Apple Clients Still Vulnerable After DNS Patch 94
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."
Re:This exploitation, so far seems extremely unlik (Score:1, Insightful)
Really ? Troll ? For pointing out that content *within* the article counters the sensationalism of the /. submission ?
Or is that one of those 'I hate Apple' moderations, or perhaps 'I disagree with your point of view' moderations ?
Hmm. Let me think...
Simon
What's the exposure? Where's the hole? (Score:5, Insightful)
Unless lookupd is doing something really weird, this is a non-issue.
Lookupd only talks to the nameservers specified by the settings in netinfo, provided by DHCP, and possibly flat files. Unless your immediate upstream nameserver isn't recursive (which is really stupid) or it is compromised there's no mechanism to get lookupd to query any other nameservers.
Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.
And if he is then this is the least of your worries.
No Shit (Score:5, Insightful)
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.
Re:This exploitation, so far seems extremely unlik (Score:5, Insightful)
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!
Apple's Disgrace (Score:1, Insightful)
Re:Don't worry (Score:5, Insightful)
It was secure from day one since BIND isn't enabled. Fancy that. It's almost like they purposely disabled it by default to be secure.
That would be a bug in Leopard. (Score:4, Insightful)
So you're saying that on Leopard the resolver ignores the DNS server settings you give it (regardless of how you give them to it, or what database it stores them in) and goes groveling around doing name resolution starting at a.root-servers.net and working down?
Because unless the client resolver does something daft like that (and, yes, that would be daft, and a bug in Leopard) the result is the same as if it was still using lookupd: the requests would have to be sniffed for a potential attacker to get a transaction or port number to use in the attack, and if the attacker is in a position to do that they don't need to predict the numbers, they just have to respond quicker than the real nameserver.
Re:This exploitation, so far seems extremely unlik (Score:2, Insightful)
Agreed. I was afraid I might make it past more than 4 or 5 posts without the word Kaminsky in them. But I think a better title would have been "Kaminsky DNS Flaws Still Plague Apple".
Only if you're referring to Kaminsky's blunder... (Score:3, Insightful)
Admittedly the details of the hack were leaked out in the most stupid manner possible
That's what you get for waiting for a $1000+ convention to do so. A leak and some code for Metasploit.
Karmic justice for his secrecy.
Re:My own DNS implementaion was never vulnerable (Score:3, Insightful)
Source port randomization does NOT fix the fundamental flaw of being able to change existing records in a caching DNS server with glue fields. Source port randomization is simply a workaround to mitigate the risk by making someone guess two 16 bit numbers instead of only one (source port AND txid). The core flaw remains unfixed because it's going to take a whole lot longer than 6 months to get anyone to agree on how to proceed.
djb is much, much harder to exploit, but if he implemented the spec, he should be vulnerable to the main bug, though in all honesty I haven't seen anyone saying he is, or you are.
Re:The patch that isn't a patch, eh? (Score:5, Insightful)
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.
Re:This exploitation, so far seems extremely unlik (Score:3, Insightful)
Until then these stories are just one big yawn.
Re:What's the exposure? Where's the hole? (Score:3, Insightful)
If you were to whisper in your friend's ear in public in a code only you two thought you knew would you be 100% sure it was secure? Normal people might think so. Reality may be different.