Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: Re: Buffer Overflow Help

Re: Buffer Overflow Help

From: Steve Bonds <kzzvt3302_at_sneakemail.com>
Date: Fri, 12 Nov 2004 15:05:29 -0800

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
Received on Nov 15 2004

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos