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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.