OpenBSD Security

OpenBSD Security Views

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than Sun, SGI, IBM, HP, or other vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography software, we are able to take cryptographic approaches towards fixing security problems.

Like most readers of the BUGTRAQ mailing list, we believe in full disclosure of security problems. We believe that security information moves very fast in crackers circles. Our experience shows that coding and release of proper security fixes typically requires about an hour of work resulting in very fast fix turnaround. Thus we think that full disclosure helps the people who really care about security.

Our security auditing team typically has between six and twelve members, and most of us continually search for and fix new security holes. We have been auditing since the summer of 1997. The process we followed to increase security was simply a comprehensive file-by-file analysis of every critical software component. Flaws were found in just about every area of the system. Entire new classes of security problems were found while we were doing the audit, and in many cases source code which had been audited earlier had to be re-audited with these new flaws in mind.

Some members of our security auditing team work for Secure Networks, the company that makes the industry's premier network security scanning software package Ballista. This company does a lot of security research, and this fits in well with the OpenBSD stance.

Another facet of our security auditing process is its proactiveness. In almost all cases we have found that the determination of exploitability is not an issue. During our auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We have fixed many simple and obvious careless programming errors in code and then only months later discovered that the problems were in fact exploitable. In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the steps. An example of where we managed such a success is the lpd advisory from Secure Networks.

This proactive auditing process has really paid off. Statements like ``This problem was fixed in OpenBSD about 6 months ago'' have become commonplace in security forums like BUGTRAQ.

Most of our security auditing happened immediately before the OpenBSD 2.0 release and during the 2.0->2.1 transition, over the last third of 1996 and first half of 1997. Thousands (Yes, that is thousands) of security issues were fixed rapidly over the year long period; bugs like the standard buffer overflows, protocol implementation weaknesses, information gathering, and filesystem races. More recently the security problems we find and fix tend to be more obscure or complicated. Still we will persist for a number of reasons:

Occasionally we find a simple one we missed before.
Security is like an arms race; the best attackers will continue to search for more complicated exploits, so we should too.

The auditing process is not over yet, and as you can see we continue to find and fix new security flaws.

OpenBSD 2.1 Security Advisories

These are the OpenBSD 2.1 advisories. All these problems are solved in OpenBSD 2.2. Some of these problems still exist in other operating systems.

OpenBSD 2.2 Security Advisories

These are the OpenBSD 2.2 advisories. All these problems are solved in OpenBSD current. Some of these problems still exist in other operating systems.

Intel P5 f00f lockup (patch included).
Sourcerouted Packet Acceptance. A patch is available here.
Setuid coredump & Ruserok() flaw (patch included).
Read-write mmap() flaw. Revision 3 of the patch is available here
MIPS ld.so flaw (patch included).

Watching our Security Changes

Since we take a proactive stance with security, we are continually finding and fixing new security problems. Not all of these problems get widely reported because (as stated earlier) many of them are not confirmed to be exploitable. We do not have the time resources to make these changes available in the above format.

Thus there are usually minor security fixes in the current source code beyond the previous major OpenBSD release. We make a limited gaurantee that these problems are of limited impact and unproven exploitability. If we discover a problem definately matters for security, patches will show up here quickly.

People who are really concerned with critical security can do a number of things:

If you understand security issues, watch our source-changes mailing list and keep an eye out for things which appear security related. Since exploitability is not proven for many of the fixes we make, do not expect the relevant commit message to say "SECURITY FIX!". If a problem is proven and serious, a patch will be available here very shortly after.
Track our current source code tree, and teach yourself how to do a complete system build from time to time (read /usr/src/Makefile carefully). Users can make the assumption that the current source tree always has stronger security than the previous release.
Install a binary snapshot for your architecure, which are made available fairly often. For instance, an i386 snapshot is typically made available weekly.

Other Resources

Other security advisories that have (in the past) affected OpenBSD can be found at the Secure Networks archive. Some OpenBSD audit team members worked with Secure Networks on discovering and solving the problems detailed in some of their security advisories.

If you find a new security problem, you can mail it to deraadt@openbsd.org.
If you wish to PGP encode it (but please only do so if privacy is very urgent, since it is inconvenient) use this pgp key.

www@openbsd.org
$OpenBSD: security.html,v 1.42 1998/03/03 01:32:38 deraadt Exp $