source:
npl/internetserver/djbdns/patches/0002-djbdns-misformats-some-long-response-packets-patch-a.diff
@
37aaf89
| Last change on this file since 37aaf89 was 37aaf89, checked in by , 3 years ago | |
|---|---|
|
|
| File size: 5.2 KB | |
-
response.c
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 100644a b int response_addname(const char *d) 34 34 uint16_pack_big(buf,49152 + name_ptr[i]); 35 35 return response_addbytes(buf,2); 36 36 } 37 if ( dlen <= 128)37 if ((dlen <= 128) && (response_len < 16384)) 38 38 if (name_num < NAMES) { 39 39 byte_copy(name[name_num],dlen,d); 40 40 name_ptr[name_num] = response_len;
Note: See TracBrowser
for help on using the repository browser.
