1 files changed, 53 insertions, 0 deletions

diff --git a/exploits/7350bindnxt/vulninfo b/exploits/7350bindnxt/vulninfo
new file mode 100644
index 0000000..ce794e4
--- /dev/null
+++ b/exploits/7350bindnxt/vulninfo
@@ -0,0 +1,53 @@
+--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
+