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."

5 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: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 ..

  3. 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.

  4. 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.

  5. 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.