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: ------ The Composable High Assurance Trusted Systems (CHATS) program is developing the tools and technology that enable the core network services to be protected from the introduction and execution of malicious code or other attack techniques and methods. These tools and technologies will provide the security services needed to achieve comprehensive-secure, highly distributed, mission-critical information systems for the DoD. A unique feature of CHATS is that these system capabilities will be developed by engaging the open-source community in security functionality for existing open-source operating systems. Additionally, DARPA will engage the open-source community in a consortium-based approach to create a ?neutral?, secure operating system architecture framework. This security architecture framework will then be used to develop techniques for composing OS capabilities to support both servers and clients in the increasing network-centric communications fabric of the DoD. In FY 2003 the CHATS program will move to project ST-24 in this program element. ------ For a time, DARPA even funded the ongoing work of the OpenBSD team but political disagreements over the Iraq war scuttled that work. In roughly the same time frame, there was a project called LSAP (Linux Security Audit Project) that attenmpted to extend the methodology of OpenBSD to Linux. This was succeeded by Sardonix which attempted to create a register of all audited open source software. For various reasons both of these projects fizzled. So why did OpenBSD succeed in their rigorous audit process? I believe it is because there was a firm hand at the helm who was able to keep them focused on their non-profit goal, namely secure operating software. Now corporations do share one characteristic with OpenBSD which should allow them to be able to succeed in the same way. They have firm hands at the helm. However, they also have the profit motive and it is often possible for corporations to avoid security issues in their systems and make profits anyway. That's where NANOG comes in. We are the customers of the router and switch manufacturers. We have the ability to tie the corporate profit motive together with a security imperative. I know that people on this list would rather talk about how to tweak the boxes and protocols to do the best with what we have available, but I think times have changed. The global community of hackers is our Al Qaeda, a leaderless mob that wants to break the network and control the network. If we want to prevent this, then we have to work as hard and as smart as the many people who are tackling Islamist terrorist cells. It's no longer good enough to just do the best we can with the boxes that vendors give us when those boxes are so easily compromised and when there is a community of people who are specifically targetting those boxes, unlike in the past. --Michael Dillon
On Aug 4, 2005, at 8:20 AM, Michael.Dillon@btradianz.com wrote:
So why did OpenBSD succeed in their rigorous audit process?
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
On Thu, 04 Aug 2005 14:20:46 BST, Michael.Dillon@btradianz.com said:
If we want to prevent this, then we have to work as hard and as smart as the many people who are tackling Islamist terrorist cells.
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.
On Thu, 4 Aug 2005, Florian Weimer wrote:
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> <tv@pobox.com> <todd@vierling.name>
* 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, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
* 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. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
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
On Tue, Sep 06, 2005 at 12:04:14PM +0100, Michael.Dillon@btradianz.com wrote:
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 -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Tue, 6 Sep 2005, Michael.Dillon@btradianz.com wrote:
The real question is not whether other BSDs or other Unices are following OpenBSD's lead.
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, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: While your friend holds you affectionately by both your hands you are safe, for you can watch both of his. -- Ambrose Bierce, "The Devil's Dictionary"
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. ----- Original Message ----- From: "Florian Weimer" <fw@deneb.enyo.de> To: <nanog@merit.edu> Sent: Tuesday, September 06, 2005 2:43 AM Subject: Re: DARPA and the network
* 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?)
On Tue, 06 Sep 2005 11:35:22 +0200, Henning Brauer said: (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]:
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@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
participants (9)
-
Alexei Roudnev -
Florian Weimer -
Henning Brauer -
Jay R. Ashworth -
Michael.Dillon＠btradianz.com -
Paul Jakma -
Tim Yocum -
Todd Vierling -
Valdis.Kletnieks＠vt.edu