version 1.44, 1998/03/03 03:09:21 |
version 1.45, 1998/03/06 11:58:12 |
|
|
<meta name="description" content="OpenBSD advisories"> |
<meta name="description" content="OpenBSD advisories"> |
<meta name="keywords" content="openbsd,main"> |
<meta name="keywords" content="openbsd,main"> |
<meta name="distribution" content="global"> |
<meta name="distribution" content="global"> |
<meta name="copyright" content="This document copyright 1997 by OpenBSD."> |
<meta name="copyright" content="This document copyright 1997,1998 by OpenBSD."> |
</head> |
</head> |
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#23238E"> |
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#23238E"> |
|
|
uncompromising view towards increased security than Sun, SGI, IBM, HP, |
uncompromising view towards increased security than Sun, SGI, IBM, HP, |
or other vendors are able to. We can make changes the vendors would |
or other vendors are able to. We can make changes the vendors would |
not make. Also, since OpenBSD is exported with <a href=crypto.html> |
not make. Also, since OpenBSD is exported with <a href=crypto.html> |
cryptography software</a>, we are able to take cryptographic |
cryptography</a>, we are able to take cryptographic approaches towards |
approaches towards fixing security problems.<p> |
fixing security problems.<p> |
|
|
Like most readers of the |
Like many readers of the |
<a href=http://www.geek-girl.com/bugtraq/index.html> |
<a href=http://www.geek-girl.com/bugtraq/index.html> |
BUGTRAQ mailing list</a>, |
BUGTRAQ mailing list</a>, |
we believe in full disclosure of security problems. We believe that |
we believe in full disclosure of security problems. Security |
security information moves very fast in crackers circles. Our |
information moves very fast in cracker circles. On the other hand, |
experience shows that coding and release of proper security fixes |
our experience is that coding and releasing of proper security fixes |
typically requires about an hour of work resulting in very fast fix |
typically requires about an hour of work -- very fast fix turnaround |
turnaround. Thus we think that full disclosure helps the people who |
is possible. Thus we think that full disclosure helps the people who |
really care about security.<p> |
really care about security.<p> |
|
|
Our security auditing team typically has between six and twelve |
Our security auditing team typically has between six and twelve |
members, and most of us continually search for and fix new security |
members who continue to search for and fix new security holes. We |
holes. We have been auditing since the summer of 1997. The process we |
have been auditing since the summer of 1996. The process we follow to |
followed to increase security was simply a comprehensive file-by-file |
increase security is simply a comprehensive file-by-file analysis of |
analysis of every critical software component. Flaws were found in |
every critical software component. Flaws have been found in just |
just about every area of the system. Entire new classes of security |
about every area of the system. Entire new classes of security |
problems were found while we were doing the audit, and in many cases |
problems have been found during our the audit, and often source code |
source code which had been audited earlier had to be re-audited with |
which had been audited earlier needs re-auditing with these new flaws |
these new flaws in mind.<p> |
in mind. Code often gets audited multiple times, and by multiple |
|
people with different auditing skills.<p> |
|
|
Some members of our security auditing team work for |
Some members of our security auditing team work for |
<a href=http://www.secnet.com>Secure Networks</a>, the company that |
<a href=http://www.secnet.com>Secure Networks</a>, the company that |
makes the industry's premier network security scanning software |
makes the industry's premier network security scanning software |
package Ballista. |
package Ballista. |
This company does a lot of security research, and this fits in well |
This company does a lot of security research, and this fits in well |
with the OpenBSD stance.<p> |
with the OpenBSD stance. OpenBSD passes Ballista's tests with flying |
|
colours.<p> |
|
|
Another facet of our security auditing process is its proactiveness. |
Another facet of our security auditing process is its proactiveness. |
In almost all cases we have found that the determination of |
In most cases we have found that the determination of exploitability |
exploitability is not an issue. During our auditing process we find |
is not an issue. During our ongoing auditing process we find many |
many bugs, and endeavor to fix them even though exploitability is not |
bugs, and endeavor to fix them even though exploitability is not |
proven. We have fixed many simple and obvious careless programming |
proven. We fix the bug, and we move on to find other bugs to fix. We |
errors in code and then only months later discovered that the problems |
have fixed many simple and obvious careless programming errors in code |
were in fact exploitable. In other cases we have been saved from full |
and only months later discovered that the problems were in fact |
exploitability of complex step-by-step attacks because we had fixed |
exploitable. (Or, more likely someone on |
one of the steps. An example of where we managed such a success is |
<a href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a> |
the |
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 |
<a href=http://www.secnet.com/sni-advisories/sni-19.bsd.lpd.advisory.html> |
<a href=http://www.secnet.com/sni-advisories/sni-19.bsd.lpd.advisory.html> |
lpd advisory from Secure Networks.</a><p> |
lpd advisory from Secure Networks.</a><p> |
|
|
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 |
``This problem was fixed in OpenBSD about 6 months ago'' have become |
commonplace in security forums like <a |
commonplace in security forums like |
href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a>.<p> |
<a href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a>.<p> |
|
|
Most of our security auditing happened immediately before the OpenBSD |
The most intense part of our security auditing happened immediately |
2.0 release and during the 2.0->2.1 transition, over the last third of |
before the OpenBSD 2.0 release and during the 2.0->2.1 transition, |
1996 and first half of 1997. Thousands (Yes, that is thousands) of |
over the last third of 1996 and first half of 1997. Thousands (yes, |
security issues were fixed rapidly over the year long period; bugs |
thousands) of security issues were fixed rapidly over this year-long |
like the standard buffer overflows, protocol implementation |
period; bugs like the standard buffer overflows, protocol |
weaknesses, information gathering, and filesystem races. More |
implementation weaknesses, information gathering, and filesystem |
recently the security problems we find and fix tend to be more obscure |
races. Hence most of the security problems that we encountered were |
or complicated. Still we will persist for a number of reasons: |
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:<p> |
|
|
<ul> |
<ul> |
<li>Occasionally we find a simple one we missed before. |
<li>Occasionally we find a simple problem we missed earlier. Doh! |
<li>Security is like an arms race; the best attackers will continue |
<li>Security is like an arms race; the best attackers will continue |
to search for more complicated exploits, so we should too. |
to search for more complicated exploits, so we will too. |
|
<li>Finding and fixing subtle flaws in complicated software is |
|
a lot of fun. |
</ul> |
</ul> |
|
|
The auditing process is not over yet, and as you can see we continue |
The auditing process is not over yet, and as you can see we continue |
|
|
<p> |
<p> |
<h3><font color=#e00000><strong>OpenBSD 2.1 Security Advisories</strong></font></h3> |
<h3><font color=#e00000><strong>OpenBSD 2.1 Security Advisories</strong></font></h3> |
These are the OpenBSD 2.1 advisories. All these problems are solved |
These are the OpenBSD 2.1 advisories. All these problems are solved |
in OpenBSD 2.2. Some of these problems still exist in other |
in <a href=22.html>OpenBSD 2.2</a>. Some of these problems still |
operating systems. |
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). |
|
|
<ul> |
<ul> |
<li><a href=advisories/rfork>Rfork() system call flaw (patch included)</a> |
<li><a href=advisories/rfork>Rfork() system call flaw (patch included)</a> |
|
|
|
|
<p> |
<p> |
<h3><font color=#e00000><strong>OpenBSD 2.2 Security Advisories</strong></font></h3> |
<h3><font color=#e00000><strong>OpenBSD 2.2 Security Advisories</strong></font></h3> |
These are the OpenBSD 2.2 advisories. All these problems are |
These are the OpenBSD 2.2 advisories. All these problems are solved |
solved in OpenBSD current. Some of these problems still exist in other |
in <a href=anoncvs.html>OpenBSD current</a>. Some of these problems |
operating systems. |
still exist in other operating systems. (The supplied patches are for |
|
OpenBSD 2.2; they may or may not work on OpenBSD 2.1). |
|
|
<ul> |
<ul> |
<li><a href=errata.html#f00f>Intel P5 f00f lockup (patch included).</a> |
<li><a href=errata.html#f00f>Intel P5 f00f lockup (patch included).</a> |
|
|
<h3><font color=#e00000><strong>Watching our Security Changes</strong></font></h3> |
<h3><font color=#e00000><strong>Watching our Security Changes</strong></font></h3> |
Since we take a proactive stance with security, we are continually |
Since we take a proactive stance with security, we are continually |
finding and fixing new security problems. Not all of these problems |
finding and fixing new security problems. Not all of these problems |
get widely reported because (as stated earlier) many of them are not |
get widely reported because (as stated earlier); many of them are not |
confirmed to be exploitable. We do not have the time resources to |
confirmed to be exploitable; many simple bugs we fix do turn out to |
make these changes available in the above format.<p> |
have security consequences we could not predict. We do not have the |
|
time resources to make these changes available in the above format.<p> |
|
|
Thus there are usually minor security fixes in the current source code |
Thus there are usually minor security fixes in the current source code |
beyond the previous major OpenBSD release. We make a limited |
beyond the previous major OpenBSD release. We make a limited |
guarantee that these problems are of limited impact and unproven |
guarantee that these problems are of minimal impact and unproven |
exploitability. If we discover that a problem definitely matters for |
exploitability. If we discover that a problem definitely matters for |
security, patches will show up here quickly.<p> |
security, patches will show up here <strong>VERY</strong> quickly.<p> |
|
|
People who are really concerned with critical |
People who are really concerned with security can do a number of |
security can do a number of things:<p> |
things:<p> |
|
|
<ul> |
<ul> |
<li>If you understand security issues, watch our |
<li>If you understand security issues, watch our |
|
|
complete system build from time to time (read /usr/src/Makefile |
complete system build from time to time (read /usr/src/Makefile |
carefully). Users can make the assumption that the current |
carefully). Users can make the assumption that the current |
source tree always has stronger security than the previous release. |
source tree always has stronger security than the previous release. |
|
However, building your own system from source code is not trivial; |
|
it is nearly 300MB of source code, and problems do occur as we |
|
transition between major releases. |
<li>Install a binary <a href=snapshots.html>snapshot</a> for your |
<li>Install a binary <a href=snapshots.html>snapshot</a> for your |
architecure, which are made available fairly often. For |
architecure, which are made available fairly often. For |
instance, an i386 snapshot is typically made available weekly. |
instance, an i386 snapshot is typically made available weekly. |