Re: Buffer Overflow Help

["Steve Bonds" <kzzvt3302 () sneakemail com>]

On Fri, 12 Nov 2004 09:38:40 -0700 (MST), sin sin-at-nosec.net wrote:
> That doesn't really look like randomization to me- its um, not incredibly
> random. I think your environment is changing. It just looks like the
> stack frame is being incremented.

I agree, hence my comment that there was a pattern to the changes.  It
increments, reaches an upper limit, then cycles around.

Regardless of the source or quality of the "randomization" the stack
pointer changes during each invocation.  I have no idea why there's
this difference between RH8 and RH9.

Also, since I have no way to predict the next stack location (even
though it's predictable based on the previous one) I can't hit my
shellcode without a large NOP sled.  In the exploit I'm working on,
there's only about 50 bytes of NOP sledding available, after tight
shellcode and I get one chance or the app crashes.  The stack pointer
ranges across about 30k, so my odds of hitting the NOP sled are not
good for a one-shot deal.

On the off chance that perhaps this was really a gcc problem, I
compiled the sample code I posted earlier on statically linked on RH8
and tried it on RH9.  I saw the same stack variations, so it's
probably not gcc or library related.

Anyone know why Red Hat 9 has this strange stack behavior?  How to disable it?

  -- Steve