Re: djbdns misformats some long response packets; patch and example attack
Matthew Dempsky <[email protected]>
| Newsgroups | gmane.network.djbdns |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Feb 27, 2009 at 9:27 PM, Jeff King <[email protected]> wrote: > From your patch, the bug seems to be in response_addname. Your attack > scenario seems to be to get a victim tinydns server (which uses > response_addname when generating a response) to serve your bogus > records. Is the result a problem for all resolvers, or just dnscache? Sorry, yes, it affects all resolvers. The bug is in tinydns and axfrdns, not in dnscache. I mentioned specifically how dnscache would behave simply because I'm so familiar with its caching behavior. I understand some other DNS caches have more complicated behaviors, and so I chose to be accurate rather than general. > What if these bogus records are served by a patched tinydns (or another > authoritative server) to dnscache? It looks like dnscache uses > response_addname when sending the answer back to the original querier, > but _not_ when caching. There are record sets that can cause dnscache to serve bogus names, but the corruption is limited to the RDATA section, which is protected because dnscache will always set a proper RDLENGTH value in the record. The reason it can't affect the record names is that dnscache will use at most 17 distinct names in the record name position. The first 16 of these are possibly CNAME records, and the rest will all be the same name. Exploiting this bug in tinydns required taking advantage of the fact that it does additional section processing on NS records, so it's possible to introduce a new record name after the 16384 byte boundary that will then be used as a record name. Since there are at most 16 CNAMEs, and even theoretically a CNAME record can never take more than about 500 bytes (255 byte record name + 10 byte record header + 255 byte rdata), so you don't get any further than about 8000 bytes, and that's assuming there was no name compression at all. Installing this patch can still be useful for dnscache users, but it's not a security risk as far as I can tell.