bugtraq - Re: djbdns misformats some long response packets; patch and example attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d791b8790902281041s32be9375h5bcf18a7494d1ed@mail.gmail.com>
Date: Sat, 28 Feb 2009 10:41:46 -0800
From: Matthew Dempsky <matthew@...psky.org>
To: bugtraq@...urityfocus.com
Subject: Re: djbdns misformats some long response packets; patch and example 
	attack

On Thu, Feb 26, 2009 at 3:34 PM, Matthew Dempsky <matthew@...psky.org> 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.)