|
BugTraq
Re: Buffer overflow prevention Aug 14 2003 05:26PM Mariusz Woloszyn (emsi ipartners pl) (6 replies) Re: Buffer overflow prevention Aug 14 2003 11:27PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 15 2003 06:48PM Crispin Cowan (crispin immunix com) (1 replies) Re: Buffer overflow prevention Aug 17 2003 11:09PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 17 2003 10:42PM Crispin Cowan (crispin immunix com) (2 replies) Heterogeneity as a form of obscurity, and its usefulness Aug 21 2003 02:00AM Bob Rogers (rogers-bt2 rgrjr dyndns org) (1 replies) Re: Heterogeneity as a form of obscurity, and its usefulness Aug 22 2003 03:56AM Crispin Cowan (crispin immunix com) (1 replies) Re: Heterogeneity as a form of obscurity, and its usefulness Aug 22 2003 06:21PM Nicholas Weaver (nweaver CS berkeley edu) Re: Buffer overflow prevention Aug 18 2003 06:07PM Mark Handley (M Handley cs ucl ac uk) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:37PM Theo de Raadt (deraadt cvs openbsd org) (3 replies) Re: Buffer overflow prevention Aug 14 2003 09:14PM Gerhard Strangar (gerhard brue net) (1 replies) Re: Buffer overflow prevention Aug 14 2003 09:43PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:17PM Timo Sirainen (tss iki fi) (1 replies) Re: Buffer overflow prevention Aug 14 2003 06:47PM Jedi/Sector One (j pureftpd org) (2 replies) Re: Buffer overflow prevention Aug 15 2003 09:41AM Peter Busser (peter trusteddebian org) (2 replies) Re: Buffer overflow prevention Aug 16 2003 01:36AM Mark Tinberg (mtinberg securepipe com) (2 replies) |
|
Privacy Statement |
> Also, you can use chpax, and turn on a non-executable stack, and with a small
> amount of voodoo (in tracking down the binarys and .so's that need the stack,
> wich typically is only a single binary or .so file, wich you can find with
> ptrace, strace, or ltrace) you can have all of your stuff run with a
> non-executeable stack, thus making stack smashing impossible. Nothing can
> execute off your stack so a malicous person can override all the addresses he
> wants, his code cant run off your stack.
>
It's been proved many times that non-executable stack adds NO security at
all.
Every single class of vulnerabilities exploitable with executable stack
can be also exploited with non-executable stack.
See for example our article (http://www.phrack.org/show.php?p=56&a=5)
which shows how to bypass a stack protector even with a non-executable
stack.
What we're discussing here is an internal structures and data protecting.
IMHO the ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/),
is the best protection in this kind, even comparing to "two stack"
approach.
Beside that it's an existing, well tested and wide used (for example
OpenBSD uses it by default now).
I see no real reason why the major Linux companies are not using it for
its products.
Best regards,
--
Mariusz Woloszyn
Internet Security Specialist, GTS - Internet Partners
[ reply ]