--here is the offending code

                n = dn_expand(msg, eom, cp, (char *)data, sizeof data);
                if (n < 0) {
                        hp->rcode = FORMERR;
                        return (-1);
                }
                if (!ns_nameok((char *)data, class, NULL, response_trans,
                               domain_ctx, dname, from.sin_addr)) {
                        hp->rcode = FORMERR;
                        return (-1);
                }
                cp += n;
                cp1 = data + strlen((char *)data) + 1;
                memcpy(cp1, cp, dlen - n);

--

This implys three things.

firstly the format of the rdata section - it is important that u form this
correctly. in this case it is quite simple, a DNS domain name followed by
any arbitrary data :) Yes, even nulls ;)

secondly the buffer will already contain the data from the DNS domain
name from the first part of the rdata section, and the arbitrary data
appends this data, hence u must take account of this when calculating the
ret distance.

thirdly its just an ordinary stack overflow ('data' isn't declared
static), so it should be easy enough to exploit.

the buffer in this case is of size MAXDATA*2 which, if u follow the macros,
evaluates to 4140 bytes. There are 12 other temporary variables in the
stack, each of size 4 bytes so, making no assumptions about how the
compiler decides to arrange them on the stack, u must send approx 14
return addresses after the shellcode. note the buffer is fuqn huge so you
should have virtually no problems with the offset =)

So if you use a DNS domain name of length 6 (e.g. \006smiler\000 =)
since it starts at 'data + strlen (data) + 1' then u need to put 4140 - 7
= 4133 bytes in the buffer to start overflowing and u need to follow that
with 14 ret addresses (56 bytes). In total that comes to 4190 bytes =)

I haven't checked this out, but apparently u need to send this
data via tcp, because BIND refuses to read more than 512 bytes from a udp
packet, even if u fragment to allow it to be bigger than the MTU
(I managed to do this before, with an rpc call, to exploit rpc.mountd -
albeit only ~1100 bytes).


-smiler


----- irix

on irix the situation is exactly the same as on x86 (stack layout is the
same). though we have to use 64bit return addresses on the n32 binaries
and have to align the shellcode on a 4byte boundary.

-sc.

