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?
This archive was generated by hypermail 2b30 : Mon Oct 29 2001 - 16:00:57 PST