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



Penetration Testing: Re: [PEN-TEST] Crusoe chip.

Re: [PEN-TEST] Crusoe chip.

From: Bennett Todd <bet_at_RAHUL.NET>
Date: Tue, 7 Nov 2000 14:00:53 -0500

As Craig said, the good folks on Bugtraq have demonstrated that
preventing execution in the stack doesn't actually add important
protection, it just changes the way you have to mount your attack.

Furthermore, it would break various techniques that various language
implementations use, that legitimately require executing in the
stack. Some compilers like to generate code that installs trampoline
instructions into the stack (I believe this is mostly to help ease
interfacing between wildly different calling conventions); some
compile-n-go implementations might want to execute out of stack
storage.

If there were a real and important security benefit to a non-exec
stack, then the potential compatibility problems could be lived
with, as each could be fixed if the implementor chose. But they
point up a potential cost, and as the only benefit to a non-exec
stack is effectively security through obscurity --- if the attacker
knows you're doing it they can dodge --- it just doesn't seem worth
implementing. Of course the benefit would be greatest if you did a
private, one-off implementation. But implementation costs, and costs
of dealing with any resulting compatibility problems, are the
highest --- because they're not shared --- for such one-offs.

-Bennett

  • application/pgp-signature attachment: stored
Received on Nov 08 2000
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]