BIND infoleak bug details?

[Bruce Leidl <brl () SECURITYFOCUS COM>]

> Synopsis: We have a working BIND TSIG exploit that we're looking for a
> little help to improve.
>
> The NAI advisory on the BIND TSIG bug states that:
>
> ``The "infoleak" bug, discovered by Claudio Musmarra, and described in
>   CERT advisory CA-2001-02, permits an attacker to remotely retrieve
>   stack frames from named''
>
> Then, according to ISC:
>    http://www.isc.org/products/BIND/bind-security.html
>    ``It is possible to construct a inverse query that allows the stack to
>      be read remotely exposing environment variables.''
>
> Does anyone have details of the exact specifics of this vulnerability, or
> exactly what type of malformed iquery will trigger this bug? The CERT
> advisory, as usual, is completely useless..

  Send an IQUERY request properly formed with a single answer record.  The
answer RR needs to contain a domain name, type, class, and ttl.  Any values
are fine for these, just make sure that the domain name makes sense to
dn_skipname().  Set the data length for the RR to some _large_ value which
will make the resource data terminate somewhere beyond the maximum packet
length.  req_iquery() will notice that this doesn't make any sense and return
a format error, but it first increments the end-of-packet pointer (cp) by
whatever value was in the resource data length field.  After req_iquery()
returns, ns_req() will fire off a (cp - msg) byte format error message.
If this length happens to be larger than the size of the packet  buffer the
response will contain contents from memory beyond the end of the buffer.

  All of the important details are in the first 40 lines of req_iquery()
in ns_req.c

cheers,

--brl