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 / ghandiat_private / www.dopesquad.net "Bein' Crazy is the least of my worries." - Jack Kerouac C439 2B06 D8D2 A2D8 1ABB 0A55 A61D 9057 63F5 9B1F
This archive was generated by hypermail 2b30 : Tue Oct 30 2001 - 09:09:51 PST