|
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.
Even though PaX is better than W^X, it is far from being perfect.
> 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.
You could say they trade availability for integrity.
> 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.
A better way to deal with would be to automatically warn someone with enough
information to easily find and fix the problem. Restarting the daemon makes the
problem managable, but it won't solve the bug.
Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/
[ reply ]