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?
> 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
[ reply ]