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
This archive was generated by hypermail 2b30 : Fri Jun 21 2002 - 16:15:09 PDT