Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apple Clients Still Vulnerable After DNS Patch

Posted by kdawson on 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."

12 of 94 comments (clear)

  1. This exploitation, so far seems extremely unlikely by Space+cowboy · · Score: 5, Informative

    ... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...

    From later on in TFA...

    These clients pass their requests along, and it seems unlikely that they could be attacked directly unless an attacker had a computer on the same local network segment as the exposed system. In that case, the attacker would have a panoply of other network information poison available, and could disrupt DNS in a more efficient manner

    [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!
  2. Re:This exploitation, so far seems extremely unlik by s.bots · · Score: 2, 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.

  3. So basically, you are saying... by tlambert · · Score: 2, 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

    1. Re:So basically, you are saying... by Todd+Knarr · · Score: 4, 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.

  4. Re:I don't understand by stevied · · Score: 4, 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 ..

  5. Rarer than hen's teeth... by Anonymous Coward · · 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.

  6. Re:Late then broke then YAY!? by Anonymous Coward · · 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.

  7. Re:What's the exposure? Where's the hole? by gatekeep · · 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.

  8. Dirty fix by Anonymous Coward · · 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 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.

  9. I'm pertty sure the same is true for Linux... by bledri · · 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

    The only way around it is to configure a local caching DNS server.

    --
    Some privacy policy Slashdot.
  10. Oh, well, then you have bigger problems! by argent · · Score: 3, 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.

  11. Still broken by deAtog · · Score: 3, Informative

    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.