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."
... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...
From later on in TFA...
[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch" ,,, where is the word 'small' in the /. title... ?
Simon.
Physicists get Hadrons!
I think one of the reasons MaraDNS (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
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.
.. with the low hanging fruit disappearing, we should be wary of giraffe hackers. So if you see someone with an exceptionally long neckbeard, you should inform your local police.
I already submitted this; unfortunately, since I was using a Mac, I submitted it to Paypal instead of slashdot.
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
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.
DNS generally runs over UDP, which works slightly differently to TCP. If you send a UDP packet out, and want a reply, you have to listen for that reply, which means you have an "open port", though in the case of DNS, hopefully only to your local network. TCP is connection based and will discard packets which do not appear to part of the connection; UDP isn't and therefore can't.
If someone can inject packets into your local network, they can try to spoof a reply to any queries you make to a recursive DNS server or forwarder (e.g. on your xDSL gateway device.) But if they can do this, you have more substantial security issues anyway. There might be something clever that could be done to attack people who've left their WiFi unsecured, but you'd still need to force them to generate multiple queries for unknown subdomains - perhaps a targetted HTML email with embedded IMG tags? Still sounds like too much work compared to emailing trojans to naive Windows users, unless you happen to work for the security services ..
Also, by default, BIND is disabled in OS X clients.
From Apple's security advisory:
"The Berkeley Internet Name Domain (BIND) server is distributed with Mac OS X, and is not enabled by default. When enabled, the BIND server provides translation between host names and IP addresses. A weakness in the DNS protocol may allow remote attackers to perform DNS cache poisoning attacks. As a result, systems that rely on the BIND server for DNS may receive forged information. This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1. Credit to Dan Kaminsky of IOActive for reporting this issue."
The original \. article (http://it.slashdot.org/article.pl?sid=08/08/01/1215209&tid=172) neglected to include the first few sentences of the above.
Because you're racing against the real DNS server, trying to beat it to providing a response. It's a lot easier to do that if you can start sending your faked responses as soon as you know the target's going to be listening. If you have to wait to see the target's request, you're starting the race already behind by the amount of network latency between you and your target. But if you can guess from the first request what port's going to be used for the second, you can start sending faked responses as soon as you know the target's sent it's request (you don't need to see the actual request to predict that timing in a lot of cases).
It's like winning a drag race. If you can time the sequence of the lights on the starting pole you can get on the gas and start to release the brakes before the light goes green, timing it so you'll start moving when the light will have turned green. That gives you a big jump on the guy who waits for the light to go green before starting to shove the gas pedal down.
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.
"Sufferin' succotash."
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!
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.
If there's an attacker on the public wifi with you who can use this attack on you, then they have already used something like an ICMP redirect spoofing attack to get you using them as the upstream router, and they can see and modify every packet you send and receive... so they don't need to *guess* the magic numbers you're using: you're giving them to them anyway.
Even though most of the affected servers have been patched, DNS is still broken. The patches thus far only make it slightly harder to exploit. Before the patches, you had a 1/(2^16) chance of guessing the sequence number. With the patches the likelihood of guessing the correct combination of port and sequence number has decreased to approximately 1/(2^32). Given there were reports that were reports of successful attacks in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes. With a fast enough internet connection, a successful attack could still take only minutes to succeed. DNSSEC or some other alternative may be the only way to avoid this issue completely.
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.