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

8 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. My own DNS implementaion was never vulnerable by Ex-Linux-Fanboy · · Score: 5, Interesting
    You know, the ISC should have fixed this issue in 2001. This is an old known issue with DNS and DNS implementors who cared about security were never vulnerable to this particular hole.

    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

  3. Already submitted by rkanodia · · Score: 5, Funny

    I already submitted this; unfortunately, since I was using a Mac, I submitted it to Paypal instead of slashdot.

  4. No Shit by That's+Unpossible! · · Score: 5, Insightful

    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.
  5. Re:This exploitation, so far seems extremely unlik by eggboard · · Score: 5, Insightful

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

  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. Re:The patch that isn't a patch, eh? by wkcole · · Score: 5, Insightful

    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.