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."
This exploitation, so far seems extremely unlikely (Score:5, Informative)
... 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.
Re:This exploitation, so far seems extremely unlik (Score:3, Informative)
The title is completely true, the clients are still vulnerable; regardless of the reduced risk, there is the possibility of an attack. I don't really find the submission to be very sensationalist, simply stating that there is still a risk. Thanks for informing the /.ers that don't RTFA.
So basically, you are saying... (Score:3, Informative)
So basically, you are saying that using a protocol which tells you the port you are supposed to respond to requests on, it's possible to "guess" the port on which responses are expected?
Uh, if you are close enough to see the request, why do you not just use the response port in the request instead of guessing it from the last request?
I'm not understanding how this is any more vulnerable, unless you can predict requests.
Also, what do Windows and Linux boxes do?
-- Terry
Re:I don't understand (Score:5, Informative)
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 ..
Rarer than hen's teeth... (Score:5, Informative)
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.
Re:Late then broke then YAY!? (Score:1, Informative)
Apple fixed BIND. BIND ships with OS X (client, not server) but is not enabled by default. The patch rolled out to the client updated the - usually dormant - BIND in case someone manually enabled it.
Apple never claimed the patch rolled out addressed client issues. You can disagree with the fact that it didn't, but the problem that Apple did patch is indeed fixed, if late.
Re:So basically, you are saying... (Score:5, Informative)
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.
Re:What's the exposure? Where's the hole? (Score:5, Informative)
The problem is this;
How does lookupd really KNOW it's talking to it's upstream nameserver?
The answer is, because it's replies match the query info and the transaction ID, and come to the right port from the right IP.
Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.
That's really no different than how this attack works against servers.
Dirty fix (Score:1, Informative)
Since Apple did patch the BIND server that comes with OS X client by default, but is disabled, you could work around this issue by enabling BIND and using localhost as the only DNS server.
To enable BIND, simply edit /System/Library/LaunchDaemons/org.isc.named.plist and change the 'Disabled' key from true to false (file is owned by root:wheel)
Generate the rndc key the default configuration is looking for and cannot start up without via 'rndc-confgen -a' with root privileges.
Follow the hint at http://www.macosxhints.com/article.php?story=20080725172011439 [macosxhints.com] to configure the system to ignore all DNS settings handed out to it via DHCP, and statically configure 127.0.0.1 as a DNS source.
I'm pertty sure the same is true for Linux... (Score:2, Informative)
The resolver logic in glibc has the same problem. Full Disclosure: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver [seclists.org]
The only way around it is to configure a local caching DNS server.
Oh, well, then you have bigger problems! (Score:4, Informative)
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.
Still broken (Score:3, Informative)