back to article Caching bugs exposed in second biggest DNS server

For years, cryptographer Daniel J. Bernstein has touted his djbdns as so secure he promised a $1,000 bounty to anyone who can poke holes in the domain name resolution software. Now it could be time to pay up, as researchers said they've uncovered several vulnerabilities in the package that could lead end users to fraudulent …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Dead Vulture

    Lazy Reporter

    If Dan would have bothered to read:

    http://cr.yp.to/djbdns/guarantee.html

    He would notice that forgery issues to *NOT* qualify for the security bounty. FAIL!

  2. Chris C

    Stupid question

    OK, so here's a stupid question -- if DNS caches can be poisoned so easily, why do we continue to use UDP connections for them? Wouldn't TCP connections, due to their stateful nature, prevent these issues (unless it was a man-in-the-middle attack, where the attacker would know the exact response to send)?

  3. alain williams Silver badge

    @ Stupid question

    ''if DNS caches can be poisoned so easily, why do we continue to use UDP connections for them?''

    Because UDP is so much faster, the DNS look up is done with one packet out and one packet back. To do that with TCP would require 3 packet setup, question, answer, 3 packet close.

  4. Destroy All Monsters Silver badge

    UDP vs. TCP

    >> why do we continue to use UDP connections for

    I would venture simply because you don't want to suffer the useless TCP connection setup overhead. DNS is just a directory lookup service and apparently suffers from lots of stupid optimization tricks that were relevant when a "DNS server" had to be 30-kg machine in the basement. Still, one wants to avoid the situation where hundreds or thousands of clients per seconds set up and tearing down TCP connections. So the correct way to do is to pack your queries and answers into the 64K offered by connectionless/fire-and-forget UDP. If a query or answer gets lost on the wy, you can simply query again. Perfect. UDP packets may even pass through a congested network where TCP won't even be able to work at all. This is also why SNMP for example uses UDP for short queries and notifications.

  5. Wyrmhole

    Bounty

    If the bounty is a measly grand I'm thinking Bernstein didn't have that much confidence in his software in the first place.

  6. Sam Liddicott

    like motorbikes

    It's faster but not as safe - but it probably won't be you gets pranged.

    Sam

  7. Anonymous Coward
    Anonymous Coward

    @alain williams

    "Because UDP is so much faster, the DNS look up is done with one packet out and one packet back. To do that with TCP would require 3 packet setup, question, answer, 3 packet close."

    That used to be a far more valid argument, when people were on slow networks and slow machines. but I'm not convinced that it still does. A (very) unscientific test gives me (averaged over 20 repetitions of the same query) timings of:-

    using tcp:

    real 0m0.076s

    user 0m0.007s

    sys 0m0.003s

    using udp:-

    real 0m0.044s

    user 0m0.002s

    sys 0m0.008s

    There are a number of advantages to using TCP, I don't think the speed issue is a sufficient disadvantage now.

  8. Brett
    Boffin

    using tcp

    Not really scalable when you have DNS servers serving multiple thousand queries of dns servers per second. The speed isn't the issue it's the overhead of setting up and maintaining those thousands of TCP sessions if you are running an auth server that is going to cause you headaches.

    Brett (Wondering why Paris hasn't commented on this thread)

  9. Destroy All Monsters Silver badge
    Boffin

    Fat TCP is fat!

    >> I don't think the speed issue is a sufficient disadvantage now.

    Think about what the kernel has to do whenever a TCP connection is opened: managed the initial packet exchange (possibly waiting for a long time in case of SYN w/o ACKs), set up queue buffers, set up the TCP state machines (whatever these are), finally hand the client socket to your application, which then has to proceed to do something special, hopefully not create two specialized threads to work with that socket.

    In case you don't need all that stuff and it is sufficient to regard the network as just a work queue with incoming 64K contextless packets, use UDP. The kernel will just have to copy the packet into userspace and you app can handle them as fast as they come in.

    Loadbalancers on high-traffic websites. They are there for a reason.

  10. Anonymous Coward
    Flame

    @Wyrmhole

    What?!

    He writes a piece of public domain software, doesn't charge for the software, doesn't offer commercial support directly, etc. He makes *NOTHING* off of the software, yet he's offering $1000 of his own personal money, and that isn't enough for you? How many other FOSS projects do you know of that offer a similar award? Go away, troll.

  11. Jon Bailey
    Stop

    djb's comments

    Copied from http://cr.yp.to/djbdns/forgery.html

    February 2009 comments

    I introduced UDP port randomization in the first dnscache release in December 1999. PowerDNS copied the same feature in 2006. As far as I know, between December 1999 and July 2008, all other DNS software on the Internet allowed blind attacks that were likely to succeed using fewer than 100000 packets.

    Many DNS software authors issued "emergency" UDP-port-randomization patches in July 2008. Some of these patches, and some subsequent patches, also attempted to stop colliding attacks, by combining "duplicate-query suppression" with various other mechanisms. Kevin Day issued a patch of this type for dnscache in February 2009.

    Day also issued a security alert ("CVE-2008-4392") stating that dnscache, without duplicate-query suppression, allowed a colliding attack using tens of millions of packets. Day failed to mention that exactly the same information has been available on this web page since November 2002. As far as I know, my July 2001 posting on the topic was the first publication of colliding attacks on DNS.

    (more at link)

  12. Tam Lin

    BCP 38

    Seriously. It would be much cheaper to simply hire Roland the HTG to enforce this.

  13. Matthew Dempsky

    Second bug not just a forgery issue

    "He would notice that forgery issues to *NOT* qualify for the security bounty. FAIL!"

    Right, and for this reason, I don't think DJB will award the $1000 to Kevin Day. However, the bug that I pointed out is an actual exploitable bug in how djbdns builds DNS response packets, which I believe is covered by DJB's security guarantee. You can read my BugTraq posting for more details (linked within the article).

  14. Andraž Levstik

    @Dustin Marquess

    Here's another piece of software that is doing that ;)

    http://www.dovecot.org/security.html

This topic is closed for new posts.

Other stories you might like