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 / 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 - 08:46:22 PST