[25914] in bugtraq
Re: Apache Exploit
daemon@ATHENA.MIT.EDU (Ben Laurie)
Fri Jun 21 19:24:06 2002
Message-ID: <3D12EE9D.6000307@algroup.co.uk>
Date: Fri, 21 Jun 2002 10:15:09 +0100
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: Stefan Esser <sesser@php.net>
Cc: bugtraq@securityfocus.com, vuln-dev@securityfocus.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Stefan Esser wrote:
> Hi,
>
> i heard several people looking at the gobbles exploit and believing it
> can only be fake:
>
> here is my little explanation how bsd memcpy can be exploited:
>
> first a snipset of the bsd memcpy code:
>
> ...
> 1:
> addl %ecx,%edi /* copy backwards. */
> addl %ecx,%esi
> std
> [1] andl $3,%ecx /* any fractional bytes? */
> decl %edi
> decl %esi
> rep
> movsb
> [X] movl 20(%esp),%ecx /* copy remainder by words */
> shrl $2,%ecx
> subl $3,%esi
> subl $3,%edi
> rep
> movsl
> ...
>
> In Apache we trigger exactly this piece of code: bsd thinks the two
> buffers are overlapping and so it wants to copy backward.
> The problem is that you are able to overwrite the call to memcpy
> including the supplied paramters (dst, src, length). With up to
> 3 bytes ([1]) depending on alignment. if you align everything perfectly
> you can set the 3 high bytes of length to zero and so change how many
> dwords memcpy tries to copy in our case 0x000000??
> This is only possible because the code reads the length param again from
> stack [X]... This way you can easily survive the call and overwrite
> the saved instruction pointer before the memcpy call...
I should just point out the slight error in this analysis - in fact, the
exploit only overwrites two bytes of the length (incidentally, the
length is also constrained to be its own stack offset, leaving no room
for manouver at all) - so the length is initially -146 (ffffff6e), and
after overwriting becomes 0000ff6e, copying just under 64k onto the
stack, which is plenty for a standard stack-based shellcode exploit.
I've also checked, and FreeBSD is indeed vulnerable in the same way, but
the glibc implementation I have seen of memcpy is not, so if Linux is
vulnerable, its by another route. I haven't looked at Solaris.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
