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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]