Since the modern military runs on networks, DARPA funds various
programs to make networks better and more secure. One of these
was CHATS. Here is the business case taken from the DARPA
budget justification:
Michael, there is nothing 'rigorous' about OpenBSD's audit process. If you substitute 'vigorous' or 'enthusiastic' we might agree with you... but 'rigorous' it is not. OpenBSD's zealotry makes me wonder if the same phenomenon is also commonplace amongst our most beloved router manufacturers.
- Tim
A large number of the "security initiatives" we see are actually useless or
worse for security, and are intended merely to give the appearance that
"we're doing something" or more nefarious reasons.
This is true for both governments and corporations.
ObNANOG: When these "security initiatives" show up in your software images,
it becomes your problem, not the problem of the people who created the initiative...
* Michael Dillon:
So why did OpenBSD succeed in their rigorous audit process?
Have they? The list at <http://www.openbsd.org/security.html#37>
continues to grow, and nowadays, it seems that only a fraction of
those issues have been discovered by the OpenBSD audit process.
Searching for "isakmpd" on that page is pretty instructive as well.
It's all in the public relations and public perception.
I'm one of the developers for NetBSD. From what I can see, on average, all
the BSDs are about the same when it comes to addressing vulnerabilities.
They're almost on par when it comes to preventative measures (but remember,
some preventative measures can go too far: OpenBSD has fallen victim to
that more than once). The real end-of-the-day tangible difference wrt
security is how vocal the project's security team is.
OpenBSD "wins" some security discussions only because it's being shouted
from rooftops. The act of shouting doesn't make something better by itself.
* Todd Vierling <tv@duh.org> [2005-08-05 00:26]:
I'm one of the developers for NetBSD. From what I can see, on average, all
the BSDs are about the same when it comes to addressing vulnerabilities.
They're almost on par when it comes to preventative measures (but remember,
some preventative measures can go too far: OpenBSD has fallen victim to
that more than once). The real end-of-the-day tangible difference wrt
security is how vocal the project's security team is.
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?
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)?
Where's the non-root, chrooted httpd, dhcpd, mopd, rbootd, afs, pppd etc
on the other BSDs? The privilege seperated tcpdump? This list is not
even remotely complete...
And, why's OpenBSd the only one that has systematically removed all
uses of dangerous string handling functions like strcpy, strcat,
sprintf etc?
so, claiming the difference is how vocal a project is is, in this case,
just far off reality.
* Henning Brauer:
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?
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)?
All these pamper over the real problems and are not very helpful in a
service provider environment, where availability might well be more
important than integrity. Buffer overflows still lead to crashes.
Some of the countermeasures also break lots of legitimate applications
(Lisp implementations, for example, or precompiled headers for GCC).
(Isn't this quite off-topic for NANOG?)
* Florian Weimer <fw@deneb.enyo.de> [2005-09-06 11:44]:
* Henning Brauer:
> 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?
> 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)?
All these pamper over the real problems and are not very helpful in a
service provider environment, where availability might well be more
important than integrity. Buffer overflows still lead to crashes.
oh, so turning a remote root into an application crash is something I
value quite a bit. this is propolice and w^x, mostly.
you skipped all the other stuff I listed that we do.
Some of the countermeasures also break lots of legitimate applications
(Lisp implementations, for example, or precompiled headers for GCC).
clisp is the only thing I am aware of that got broken.
even emancs works, and those who know how emacs works can value that 
(Isn't this quite off-topic for NANOG?)
yes, it is. we can further dicuss that in private if you wish; however,
claiming OpenBSD is just more vocal about security is just far off
reality, and that had to be put in perspective.
yes, it is. we can further dicuss that in private if you wish; however,
claiming OpenBSD is just more vocal about security is just far off
reality, and that had to be put in perspective.
The real question is not whether other BSDs or
other Unices are following OpenBSD's lead. I'd like
to know how many embedded systems (routers and switches)
are implementing similar "hardening" techniques.
The Internet runs on embedded systems and although
many have their roots in Unix, they don't seem
to have adopted many of the security techniques
that are used in C2 or CAPP certified systems.
The details that Henning posted are useful to
list members who are writing RFPs for new network
gear. Even if vendors can't meet these requirements
today, it is good to let them know that people
seriously want secure operating systems on
their routers and switches.
--Michael Dillon
This in reality protects from EVERYTHING! In theory - not, but in reality -
no exploits exists at all (except DDOS exploints, of course) for such
systems.
> yes, it is. we can further dicuss that in private if you wish; however,
> claiming OpenBSD is just more vocal about security is just far off
> reality, and that had to be put in perspective.The real question is not whether other BSDs or
other Unices are following OpenBSD's lead. I'd like
to know how many embedded systems (routers and switches)
are implementing similar "hardening" techniques.
Well, I sort of gather that the implication was "all the ones that are
embedding OpenBSD". 
The Internet runs on embedded systems and although many have their
roots in Unix, they don't seem to have adopted many of the security
techniques that are used in C2 or CAPP certified systems.
Quite so.
The details that Henning posted are useful to list members who are
writing RFPs for new network gear. Even if vendors can't meet these
requirements today, it is good to let them know that people seriously
want secure operating systems on their routers and switches.
Ah yes, the most important requirement: informed, vocal users. The
more you spend per year, the better.
Cheers,
-- jra
(Off-topic, but needs correcting...)
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?
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.
There's probably more systems running a Linux with one of these than OpenBSD.
* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> [2005-09-06 20:04]:
(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.
At least one Linux distro ships with quite a few of the features Henning mentions (exec-shield since FC2, FORTIFY_SOURCE - available in FC3, FC4 built with it enabled).
I think MS have DLL base-address randomisation shipping in a service pack (not quite sure of this).
regards,