BugTraq
djbdns misformats some long response packets; patch and example attack Feb 26 2009 11:34PM
Matthew Dempsky (matthew dempsky org) (2 replies)
Re: djbdns misformats some long response packets; patch and example attack Mar 05 2009 06:05AM
Matthew Dempsky (matthew dempsky org)
Re: djbdns misformats some long response packets; patch and example attack Feb 28 2009 06:41PM
Matthew Dempsky (matthew dempsky org)
On Thu, Feb 26, 2009 at 3:34 PM, Matthew Dempsky <matthew (at) dempsky (dot) org [email concealed]> wrote:
> Some caveats: this bug only affects domains that serve DNS content
> using tinydns and axfrdns (only for DNS queries over TCP; clients do
> not need AXFR permissions) from djbdns 1.05 and allow untrusted users
> to include arbitrary records (at least about 100 records, totalling
> about 30KB of space) within some zone.
>
> In summary: if you use tinydns/axfrdns from djbdns 1.05 to serve
> authoritative DNS content and give untrusted users control over
> records you serve, I strongly suggest you install this patch.  I don't
> believe other users are at risk, but they are encouraged to install
> this patch as well to be safe.

There was a request for clarification about this on the djbdns mailing
list, so I thought I should include it here: this bug affects dnscache
as well, but I do not think dnscache can be exploited using it.

Rationale: exploiting this bug in tinydns/axfrdns required forcing
djbdns to misformat a name in the owner position of the record, which
can be done using additional section processing. dnscache doesn't do
additional section processing, and there are at most 16 CNAME records
preceding the answer records (which even assuming no name compression
could not take up more than about 8000 bytes of space). Therefore, if
an owner name is compressible, any previous occurrences will
necessarily have been within the first 16384 bytes of the packet.

It's possible for dnscache and tinydns/axfrdns to mangle names in the
record data sections, but the rdlength fields will still be correct,
so reasonable parsers should be protected. I know the packet parsers
in djbdns are safe from this, but I can imagine other parser
implementations that wouldn't handle this safely. (Hence why I
encourage everyone to install the patch to be safe.)

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus