Re: question on remote overflow

From: Dave Aitel (daitel@atstake.com)
Date: 10/29/01 

Message-ID: <3BDDB8EE.7D6C351A@atstake.com>
Date: Mon, 29 Oct 2001 15:15:42 -0500
From: Dave Aitel <daitel@atstake.com>
To: Minchu Mo <morris_minchu@iwon.com>
Subject: Re: question on remote overflow

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?

Relevant Pages