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 simply 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:
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 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.