|
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) |
|
Privacy Statement |
> So the best protection is probably Propolice + non exec stack + write xor
> executable pages. Oh, surprise, this is just how OpenBSD works.
PaX is more strict in its W^R enforcement than OpenBSD.
> This is still not a magical protection against everything. A vulnerable
> application can still behave abnormally after an overflow. But this couple
> makes injection + execution of arbitrary code way more tricky.
Right there is no silver bullet. The only thing you can hope for is to raise
the bar high enough that noone can jump over it.
> The only way to sleep quietly is still to audit the code at the first place.
The only way to sleep quietly in fact is to feed your computer to a shredder.
Auditing code alone will not provide much security. In fact, it will lead to a
false sense of security. The problem is that a modern UNIX system is that it
contains millions of lines of code. Auditing this amount of code is simply
impossible. Furthermore, auditors are humans. Humans make mistakes, not only
when they are programmers, but also when they are auditors. So audited code
will still contain security bugs.
In fact, the amount of security in OpenBSD is only slightly less horrible than
that of most *NIX operating systems (which includes Adamantix for that matter).
Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/
[ reply ]