=================================================================== RCS file: /cvsrepo/anoncvs/cvs/www/security.html,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- www/security.html 1998/03/03 03:09:21 1.44 +++ www/security.html 1998/03/06 11:58:12 1.45 @@ -7,7 +7,7 @@ - + @@ -23,67 +23,80 @@ 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.

+cryptography, we are able to take cryptographic approaches towards +fixing security problems.

-Like most readers of the +Like many 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 +we believe in full disclosure of security problems. Security +information moves very fast in cracker circles. On the other hand, +our experience is that coding and releasing of proper security fixes +typically requires about an hour of work -- very fast fix turnaround +is possible. 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.

+members who continue to search for and fix new security holes. We +have been auditing since the summer of 1996. The process we follow to +increase security is simply a comprehensive file-by-file analysis of +every critical software component. Flaws have been found in just +about every area of the system. Entire new classes of security +problems have been found during our the audit, and often source code +which had been audited earlier needs re-auditing with these new flaws +in mind. Code often gets audited multiple times, and by multiple +people with different auditing skills.

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.

+with the OpenBSD stance. OpenBSD passes Ballista's tests with flying +colours.

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 +In most cases we have found that the determination of exploitability +is not an issue. During our ongoing auditing process we find many +bugs, and endeavor to fix them even though exploitability is not +proven. We fix the bug, and we move on to find other bugs to fix. We +have fixed many simple and obvious careless programming errors in code +and only months later discovered that the problems were in fact +exploitable. (Or, more likely someone on +BUGTRAQ +would report that other operating systems were vulnerable to a `newly +discovered problem', and then it would be discovered that OpenBSD had +been fixed in a previous release). In other cases we have been saved +from full exploitability of complex step-by-step attacks because we +had fixed one of the intermediate 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 +Our 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.

+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: +The most intense part 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, +thousands) of security issues were fixed rapidly over this year-long +period; bugs like the standard buffer overflows, protocol +implementation weaknesses, information gathering, and filesystem +races. Hence most of the security problems that we encountered were +fixed before our 2.1 release, and then a far smaller number needed +fixing for our 2.2 release. We do not find as many problems anymore, +it is simply a case of diminishing returns. Recently the security +problems we find and fix tend to be significantly more obscure or +complicated. Still we will persist for a number of reasons:

The auditing process is not over yet, and as you can see we continue @@ -92,8 +105,13 @@

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. +in OpenBSD 2.2. Some of these problems still +exist in other operating systems. (If you are running OpenBSD 2.1, we +would strongly recommend an upgrade to the newest release, as this +patch list only attempts at fixing the most important security +problems. In particular, OpenBSD 2.2 fixes numerous localhost +security problems. Many of those problems were solved in ways which +make it hard for us to provide patches).