DARPA and the network
Henning Brauer
hb-nanog at bsws.de
Tue Sep 6 19:07:07 UTC 2005
* Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> [2005-09-06 20:04]:
> On Tue, 06 Sep 2005 11:35:22 +0200, Henning Brauer said:
> (Off-topic, but needs correcting...)
well, then please correct correctly...
> > so if the BSDs are en par with preventive measures, why is OpenBSD (to
> > my knowledge) the only one shipping ProPolice, which prevented
> > basically any buffer overflow seen in the wild for some time now?
> Not familiar with ProPolice, but much of Fedora is compiled with the
> FORTIFY_SOURCE option, which presumably does similar stuff?
FORTIFY_SOURCE seems to be closer to our -Wbounded than PorPolice,
ProPolice goes way further. please check
http://www.openbsd.org/papers/auug04/index.html for an overview of
exploit mitigation techniques in OpenBSD. I didn't even mention
stackgap, stackghost (on sparc and sparc64) and some others yet.
More in-depth inofrmation about ProPolice can be found at
http://www.trl.ibm.com/projects/security/ssp/
but note that there's some more modifcations in OpenBSD, for example we
have the stack smash handler in libc.
> > Why is OpenBSD the only one to have randomized library loading,
> > rendering basicaly all exploits with fixed offsets unuseable?
> > Why is OpenBSD the only one to have W^X, keeping memory pages writeable
> > _or_ executable, but not both, unless an application fixes us to (by
> > respective mprotect calls)?
> See the ExecShield stuff in RedHat/Fedora, or the Pax patch in grsecurity,
> which both address these two points.
well, again, they're not even rmeotely going as far as W^X goes.
> There's probably more systems running a Linux with one of these than OpenBSD.
I am pretty certain this is not the case, not even remotely. But since
neither you nor I have numbers to back this I don't see the point in
speculating further.
--
Henning Brauer, hb at bsws.de, henning at openbsd.org
BS Web Services, http://bsws.de
OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
More information about the NANOG
mailing list