Last week, Matthew Dempsky posted an attack against Dan Bernstein’s djbdns software. Djbdns is one of several alternatives for the popular BIND nameserver, and is backed by a unique security guarantee that offers $1000 to the first person to publicly report a verifiable security hole in djbdns. The problem found by Dempsky allows an attacker to poison DNS records:

The security hole here is that an administrator that uses djbdns 1.05 to serve DNS content does not expect that configuring his name server as above will cause it to send records for names outside of burlap.dempsky.org. I.e., an attacker can trick the administrator’s name servers to include arbitrary DNS records in response to queries for names within domains he controls.

Less than a week later, D.J. Bernstein has acknowledged that this was indeed a security issue:

Even though this bug affects very few users, it is a violation of the expected security policy in a reasonable situation, so it is a security hole in djbdns. Third-party DNS service is discouraged in the djbdns documentation but is nevertheless supported. Dempsky is hereby awarded $1000.

There will be a new release of djbdns soon that will fix this bug and will come with a new security guarantee. This is a big contrast with the way a supposed security issue in qmail was handled. In that case, Bernstein denied there was a security issue because “Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail’s assumption that allocated array lengths fit comfortably into 32 bits”.

While we’re waiting for a new release, users of djbdns are strongly encouraged (even by Bernstein himself) to install the patch provided by Dempsky. The same bug is also present in the dnscache component, but Matthew Dempsky thinks it cannot be exploited in a caching-only server, so even though users of that software should install the update as well, there’s less of a rush for them. Here’s a copy of the patch:

--- response.c.orig     2009-02-24 21:04:06.000000000 -0800
+++ response.c  2009-02-24 21:04:25.000000000 -0800
@@ -34,7 +34,7 @@
         uint16_pack_big(buf,49152 + name_ptr[i]);
         return response_addbytes(buf,2);
       }
-    if (dlen <= 128)
+    if ((dlen <= 128) && (response_len < 16384))
       if (name_num < NAMES) {
        byte_copy(name[name_num],dlen,d);
        name_ptr[name_num] = response_len;

Let’s hope this doesn’t affect the perceived security of the alternative for DNSSEC that Bernstein has recently proposed; so far DNSCurve appears to have some significant advantages over DNSSEC, both in terms of security and ease of administration.

Daniel Bernstein

Daniel Bernstein