Description: djbdns misformats some long response packets
 The DNS protocol restricts name compression to point into the first
 16384 bytes of a packet.  Line 18 of response.c from djbdns 1.05
 directly references this, but response_addname() in the same file does
 not enforce this at all.  The consequence of this is that names in
 very large DNS packets may be mangled, and clients may misparse the
 packet.
 .
 Because this email is somewhat long, I'll state up front you can find
 a patch for this issue at the bottom of this email or at:
     http://shinobi.dempsky.org/~matthew/djbdns-bug/patch
 .
 To help demonstrate this bug, I've constructed an example attack.  In
 this scenario, there's a .foo TLD operated using tinydns and axfrdns
 (to support DNS queries over TCP; AXFR support is not required).  The
 attacker has registered x.foo and is allowed to upload NS records for
 x.foo and A records for names within the x.foo domain.  However,
 because of the aforementioned bug, this attacker can construct a
 record set that causes the .foo servers to respond to queries asking
 about names within the x.foo domain with poisonous records for names
 outside of x.foo.
 .
 Using tinydns-data and tinydns-get from stock djbdns 1.05, you can
 reproduce this as follows:
 .
     $ curl -O http://shinobi.dempsky.org/~matthew/djbdns-bug/data
     $ grep -c -v -e '&x\.foo::' -e '^+[^:]*\.x\.foo:' data
     0
     $ tinydns-data
     $ tinydns-get a www.x.foo | grep ': foo '
     additional: foo 8388608 NS a.ns.bar
     additional: foo 8388608 NS b.ns.bar
 .
 (With the patch I linked above, no records outside of x.foo will be
 served.  It's also worth noting the printpacket_cat() routine
 tinydns-get uses for pretty printing the response packet is much
 stricter about parsing than dnscache's parser is; e.g., it rejects
 packets with extra trailing bytes and records with bad rdlength fields
 on known record types.)
 .
 If a victim using dnscache now makes an A query for www.x.foo,
 dnscache will save the poisoned records, and begin contacting the
 attacker's nameservers for all .foo requests.  (The response will be
 over 512 bytes long, so dnscache will have to retry the query over
 TCP, which is why axfrdns is necessary too.)
 .
 Now, admittedly if you peek at data, you'll see the supplied records
 exceed what most TLDs probably allow: there are redundant NS records,
 there are very long names (but still within the allowed limits of the
 DNS protocol), names use non-printable characters, there are over 100
 records totalling about 24K of storage.  However, neither the djbdns
 documentation nor standard practice warn potential .foo administrators
 that their domain will be at risk for poisoning if they were to add
 support for glue record sets.  (Standard practice only warns that such
 absurd records can negatively impact x.foo, not .foo as well.)
 .
 A perhaps more reasonable scenario is that the .foo servers fetch the
 contents of the x.foo domain over AXFR (removing any records from
 outside of x.foo) and then serve the records themselves.  axfr-get,
 the AXFR client from djbdns, would handle the above data set fine.
 .
 In looking for a real life example of this latter scenario, I found
 freedns.afraid.org.  They allowed me to register burlap.afraid.org and
 set it up as an AXFR slave to my personal server.  I have not explored
 what limits they place on imported records, and their website states
 they're using BIND, but assuming they're not too limiting and were to
 instead use tinydns/axfrdns/axfr-get, it would be possible for me to
 trick any dnscache that queries for www.burlap.afraid.org into
 contacting another set of nameservers for all of afraid.org's DNS
 traffic.
 .
 There's a similar service everydns.net.  They do claim to use tinydns
 (and so I assume axfrdns and axfr-get) and also provide AXFR slave
 support, but they did not allow me to register burlap.everydns.net.
 If they did, it would probably be possible to similarly poison
 everydns.net.
 .
 I've tried to search for previous reports of this issue more
 thoroughly than the last bug I mentioned to the list, and I haven't
 found any mention of it yet.  I emailed Dan earlier today when I first
 began to suspect this bug was 'exploitable' to clarify his definition
 of a 'security hole' in djbdns.  I think the afraid.org example is a
 reasonable use case where this bug would violate afraid.org's security
 constraints if they were to instead use djbdns.
 .
 Any thoughts from the list on this bug?  (Except from Dean Anderson;
 I'm sure he'll spend the next 3 weeks now arguing I'm a blackhat
 hacker while refusing to look at the patch or sample data file because
 my web server might hack his computer.)
Author: Matthew Dempsky <matthew@dempsky.org>
Date: Mon, 2 Mar 2009 04:46:05 +0000
Last-Update: 2020-07-26

diff --git a/response.c b/response.c
index ba90c89..33b2fb1 100644
--- a/response.c
+++ b/response.c
@@ -34,7 +34,7 @@ int response_addname(const char *d)
         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;