Apple Clients Still Vulnerable After DNS Patch 94
Posted
by
kdawson
from the try-try-again dept.
from the try-try-again dept.
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."
My own DNS implementaion was never vulnerable (Score:5, Interesting)
I think one of the reasons MaraDNS [maradns.org] (my own DNS server) is as good as it is is because I paid attention to DJB's writings. You know, a lot of people don't like DJB and his software is very polarizing. His confrontational behavior towards BIND and Sendmail was, at best, very unprofessional. I also don't like his dishonesty about the security issues both DjbDNS and Qmail have, pretending that these programs have no security problems. That is also fanboy behavior and not behavior a responsible software developer should have. The license was an issue for years, also; when the license was finally made reasonable late 2007 it has been too long to really develop a community of developers around either DjbDNS or Qmail (or Publicfile or...).
That said, he had some good ideas. The idea of randomizing both the query ID and the source port came from DJB and I implemented it in MaraDNS because I took the time to read what he had to say about DNS before implementing MaraDNS.
It is unfortunate that the bad blood between DJB and the BIND developers made it so BIND didn't implement source port randomization back in, say, 2001. It was known and a good idea then; it's essential today.
- Sam
The patch that isn't a patch, eh? (Score:1, Interesting)
I'm not sure I 'get' it!
Re:What's the exposure? Where's the hole? (Score:3, Interesting)
Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.
Out of curiosity, what about public Wi-Fi? Wouldn't people (normally) expect their https connection to their bank to be okay?
So appearantly articles writers don't read TFA... (Score:3, Interesting)
Putting bad cache entries in a DNS server is bad for lots of people.
Apple fixed BIND (if a bit tardy).
End of story.
If you are in the position to spoof DNS responses, you don't have to wait for the SECOND request to feeding bad results, so whether or not the client ports are predictable isn't important. But there's no way you can make the client start asking your server for DNS results, and that's the known part of the vulnerability: Injecting foreign servers into the DNS system and giving them responsibility for things they shouldn't have.
Not to defend Apple, but they're not the only ones (Score:4, Interesting)
I'm no Apple fanboy (never had a Mac and likely never will), but I feel that I have to stand up for them here.
The author seems to have a personal vendetta against Apple here, since I'd guess most Linux clients are at least as vulnerable.
Let's see what's going on here: If your DNS server recurses and caches, then it will accept glue records and you really need to patch your server.
m
However, stub resolvers which ost clients use simply ask your local DNS server directly, which does all the recursing. As a result they will only accept responses from the local DNS server (which is probably harder to spoof in practice) and further more they probably won't (at least the Linux libc resolver doesn't) accept any additional records. In particular this means that the attack as currently described can't work - you only get one chance to spoof a response to a DNS query rather than as many as you like (and in practice you can't trigger a DNS query from a client whenever you like - they'd have to visit your website or similar). Essentially this new attack gives you nothing new when it comes to attacking clients (and as has been pointed out if you're on the same local network segment as your victim, then there are many other attacks to try). That said of course, we may not know the full extent of the attack found by Dan Kaminsky and he may also have found an awesome attack on stub resolvers. But he wants his glory at the BlackHat conference, so the rest of us have to sit in the dark hoping there isn't more to come!! Of course it's still recommended that stub resolvers are patched, although they don't need to be so urgently, so yes indeed Apple should release a complete patch as we don't know what other attacks may be possible, and we're better safe than sorry. But certainly it's not something to panic about. Panic about the large number of unpatched servers still out there!
But what really annoys my about this article is that it also applies to Linux. Take Debian Stable - a quick test shows that it actually uses a fixed port for its queries! They fully admit they haven't yet patched the glibc stub resolver yet (look up DSA 1605-1). In newer kernels (>=2.6.24) the glibc resolver uses an unspecified port, so it's essentially chosen by the kernel, so it is fixed. But any Linux system prior to this is probably still vulnerable.
I can't actually quite believe I'm posting this as a Debian fan, and Apple hater, but this sort of shoddy journalism really annoys me.
Yes Apple have been slow to patch this. Yes they should have done a complete job. But much as we might despise them, lets at least be fair about this!
Re:Apple's Disgrace (Score:3, Interesting)
Not really, it's better than loads of other crap they've done.
Re:Not to defend Apple, but they're not the only o (Score:1, Interesting)
Both you and the grandparent are misinformed. All clients which are capable of resolving hostnames have a stub .. gasp .. resolver, which is what this is about. It has nothing to do with caching nameservers. The grandparent is wrong because the original attack requires user interaction in the first place.
The core of the vulnerability has been known for years and years, and was always possible. The new bit is just an interesting spin on it: reduce attack time by averaging over a number of sub-domain queries that you control (e.g. through a web page).