Vulnerability Development mailing list archives
Re: question on remote overflow
From: Dave Aitel <daitel () atstake com>
Date: Tue, 30 Oct 2001 04:56:46 -0500
I find register windows messing me up more often than not. On a recent overflow I had to be lame and for (i=-256; i<256; i+=8) { buffer[saveretplace+i]=return_address; buffer[saveretplace+i+4=frame_ptr; } just to make the exploit happen reliably. And that wasn't even a case of the debugger changing the effects of the overflow - just simple randomness. Another good trick is to simply do a call -4 and have the exploit send the program into an eternal loop, which you then connect to with GDB. Minchu's email box is full, so we'll probably never know the answer. :> -dave ghandi wrote:
I doubt that the register windows not being flushed is the problem. You'll only find the SAVE instruction not causing an overflow trap very low inside the kernel, it's basically guaranteed to happen in any userland process. The case where the overflowed function not returning to its caller (calling exit(), for instance) is a problem, however (but that doesn't seem to be the case here). It seems to me that the return address is working with the remote program in the debugger, but is different when it is not being run as an inferior process. I would agree with Dave that you should increase the size of your overflow string. Find out just how many NOPs you can cram in there. Also check for the shellcode failing. Replace the first instruction of the shellcode with a breakpoint trap: "\x91\xd0\x20\x01" /* ta 0x1 */ The RPC daemon should obviously die somehow, if it dies with a Trace/Breakpoint trap, it obviously began executing what would be the correct shellcode. Doing this also has the added bonus of allowing you to run it under GDB and have it break just when the shellcode starts executing :). On Mon, 29 Oct 2001, Dave Aitel wrote:What's probably happening is that your overflow doesn't actually occur (meaning - doesn't overwrite the saved return address on the stack) unless the cpu switches register windows at the right moment. Try loading the machine down and giving that a shot. Also try making your overflow string larger, if possible. Remember that SPARC register windows are 64 bytes...so sometimes exploits that are quite easy to do while the process is being traced are impossible in real life. Your second comment: "trussed/debugged processes run differently than non-debugged processes" is indeed true. As a side note: What do you mean by "the process seems to skip the hacking code in the heap?" Do you mean the process crashes or the process just happily hums along? -dave Minchu Mo wrote:Mailer: SecurityFocus I am doing a remote overflow experiment on solaris 2.7 /w sparcV9. my RPC server have a buffer overflow bug in stack, my rpc client will pass a long binary code(with hacking code inside) to the server. Part of the binary will overflow the buffer and overwrite the return address, the other part of binary contains the hacking code downloaded from lsd-pl (findsck and shell code) and resides in the heap area. Once the overflow happen, the control supposed to be transfered to the heap area and run from there. With adb/truss tracing the RPC server, I can see the control was indeed transferred to the heap and run from there, but if I let the RPC server run freely, the process seem to skip the hacking code in heap. My questions are: Why control didn't transfer? IS heap also disable from running code? Or process under adb run differently from realtime?-- ghandi / ghandi () mindless com / www.dopesquad.net "Bein' Crazy is the least of my worries." - Jack Kerouac C439 2B06 D8D2 A2D8 1ABB 0A55 A61D 9057 63F5 9B1F
Current thread:
- question on remote overflow Minchu Mo (Oct 29)
- Re: question on remote overflow Dave Aitel (Oct 29)
- RE: question on remote overflow Golden_Eternity (Oct 29)
- Re: question on remote overflow ghandi (Oct 30)
- Re: question on remote overflow Dave Aitel (Oct 30)
- Re: question on remote overflow Dave Aitel (Oct 29)