Commit | Line | Data |
---|---|---|
b4588d5c GP |
1 | From b65be17a01f4be5ba90f030dcb7c43704c3c8e7b Mon Sep 17 00:00:00 2001 |
2 | From: Matthew Dempsky <matthew@dempsky.org> | |
3 | Date: Mon, 2 Mar 2009 04:46:05 +0000 | |
4 | Subject: [PATCH] djbdns misformats some long response packets; patch and example attack | |
5 | ||
6 | The DNS protocol restricts name compression to point into the first | |
7 | 16384 bytes of a packet. Line 18 of response.c from djbdns 1.05 | |
8 | directly references this, but response_addname() in the same file does | |
9 | not enforce this at all. The consequence of this is that names in | |
10 | very large DNS packets may be mangled, and clients may misparse the | |
11 | packet. | |
12 | ||
13 | Because this email is somewhat long, I'll state up front you can find | |
14 | a patch for this issue at the bottom of this email or at: | |
15 | http://shinobi.dempsky.org/~matthew/djbdns-bug/patch | |
16 | ||
17 | To help demonstrate this bug, I've constructed an example attack. In | |
18 | this scenario, there's a .foo TLD operated using tinydns and axfrdns | |
19 | (to support DNS queries over TCP; AXFR support is not required). The | |
20 | attacker has registered x.foo and is allowed to upload NS records for | |
21 | x.foo and A records for names within the x.foo domain. However, | |
22 | because of the aforementioned bug, this attacker can construct a | |
23 | record set that causes the .foo servers to respond to queries asking | |
24 | about names within the x.foo domain with poisonous records for names | |
25 | outside of x.foo. | |
26 | ||
27 | Using tinydns-data and tinydns-get from stock djbdns 1.05, you can | |
28 | reproduce this as follows: | |
29 | ||
30 | $ curl -O http://shinobi.dempsky.org/~matthew/djbdns-bug/data | |
31 | $ grep -c -v -e '&x\.foo::' -e '^+[^:]*\.x\.foo:' data | |
32 | 0 | |
33 | $ tinydns-data | |
34 | $ tinydns-get a www.x.foo | grep ': foo ' | |
35 | additional: foo 8388608 NS a.ns.bar | |
36 | additional: foo 8388608 NS b.ns.bar | |
37 | ||
38 | (With the patch I linked above, no records outside of x.foo will be | |
39 | served. It's also worth noting the printpacket_cat() routine | |
40 | tinydns-get uses for pretty printing the response packet is much | |
41 | stricter about parsing than dnscache's parser is; e.g., it rejects | |
42 | packets with extra trailing bytes and records with bad rdlength fields | |
43 | on known record types.) | |
44 | ||
45 | If a victim using dnscache now makes an A query for www.x.foo, | |
46 | dnscache will save the poisoned records, and begin contacting the | |
47 | attacker's nameservers for all .foo requests. (The response will be | |
48 | over 512 bytes long, so dnscache will have to retry the query over | |
49 | TCP, which is why axfrdns is necessary too.) | |
50 | ||
51 | Now, admittedly if you peek at data, you'll see the supplied records | |
52 | exceed what most TLDs probably allow: there are redundant NS records, | |
53 | there are very long names (but still within the allowed limits of the | |
54 | DNS protocol), names use non-printable characters, there are over 100 | |
55 | records totalling about 24K of storage. However, neither the djbdns | |
56 | documentation nor standard practice warn potential .foo administrators | |
57 | that their domain will be at risk for poisoning if they were to add | |
58 | support for glue record sets. (Standard practice only warns that such | |
59 | absurd records can negatively impact x.foo, not .foo as well.) | |
60 | ||
61 | A perhaps more reasonable scenario is that the .foo servers fetch the | |
62 | contents of the x.foo domain over AXFR (removing any records from | |
63 | outside of x.foo) and then serve the records themselves. axfr-get, | |
64 | the AXFR client from djbdns, would handle the above data set fine. | |
65 | ||
66 | In looking for a real life example of this latter scenario, I found | |
67 | freedns.afraid.org. They allowed me to register burlap.afraid.org and | |
68 | set it up as an AXFR slave to my personal server. I have not explored | |
69 | what limits they place on imported records, and their website states | |
70 | they're using BIND, but assuming they're not too limiting and were to | |
71 | instead use tinydns/axfrdns/axfr-get, it would be possible for me to | |
72 | trick any dnscache that queries for www.burlap.afraid.org into | |
73 | contacting another set of nameservers for all of afraid.org's DNS | |
74 | traffic. | |
75 | ||
76 | There's a similar service everydns.net. They do claim to use tinydns | |
77 | (and so I assume axfrdns and axfr-get) and also provide AXFR slave | |
78 | support, but they did not allow me to register burlap.everydns.net. | |
79 | If they did, it would probably be possible to similarly poison | |
80 | everydns.net. | |
81 | ||
82 | I've tried to search for previous reports of this issue more | |
83 | thoroughly than the last bug I mentioned to the list, and I haven't | |
84 | found any mention of it yet. I emailed Dan earlier today when I first | |
85 | began to suspect this bug was 'exploitable' to clarify his definition | |
86 | of a 'security hole' in djbdns. I think the afraid.org example is a | |
87 | reasonable use case where this bug would violate afraid.org's security | |
88 | constraints if they were to instead use djbdns. | |
89 | ||
90 | Any thoughts from the list on this bug? (Except from Dean Anderson; | |
91 | I'm sure he'll spend the next 3 weeks now arguing I'm a blackhat | |
92 | hacker while refusing to look at the patch or sample data file because | |
93 | my web server might hack his computer.) | |
94 | (cherry picked from commit 8df61658242b3af187544d6cae0f71e7b9034e68) | |
95 | --- | |
96 | response.c | 2 +- | |
97 | 1 files changed, 1 insertions(+), 1 deletions(-) | |
98 | ||
99 | diff --git a/response.c b/response.c | |
100 | index ba90c89..33b2fb1 100644 | |
101 | --- a/response.c | |
102 | +++ b/response.c | |
103 | @@ -34,7 +34,7 @@ int response_addname(const char *d) | |
104 | uint16_pack_big(buf,49152 + name_ptr[i]); | |
105 | return response_addbytes(buf,2); | |
106 | } | |
107 | - if (dlen <= 128) | |
108 | + if ((dlen <= 128) && (response_len < 16384)) | |
109 | if (name_num < NAMES) { | |
110 | byte_copy(name[name_num],dlen,d); | |
111 | name_ptr[name_num] = response_len; | |
112 | -- | |
113 | 1.6.2 | |
114 |