|
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 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 |
> AFAIK all those combined do bring real security against generic exploits.
"Real security" is not the word.
PaX / Propolice / W^X / non-exec stacks don't solve bugs. What they do is
to _abort_ execution of a process when it behaves abnormally.
So instead of giving attackers the opportunity to run arbitrary code, you
only give them the ability to cause a denial of service.
This kind of protection should be coupled with tools that automatically
restart daemons when they crash (ex: daemontools and monit) to actually keep
the service running when under attack. Still, all of this is a couple of
unreliable band-aids.
--
__ /*- Frank DENIS (Jedi/Sector One) <j (at) 42-Networks (dot) Com [email concealed]> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/
[ reply ]