File: [local] / www / security.html (download) (as text)
Revision 1.38, Thu Feb 26 22:45:42 1998 UTC (26 years, 3 months ago) by deraadt
Branch: MAIN
Changes since 1.37: +5 -4 lines
new advisories
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html>
<head>
<title>OpenBSD Security</title>
<link rev=made href=mailto:www@openbsd.org>
<meta name="resource-type" content="document">
<meta name="description" content="OpenBSD advisories">
<meta name="keywords" content="openbsd,main">
<meta name="distribution" content="global">
<meta name="copyright" content="This document copyright 1997 by OpenBSD.">
</head>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#23238E">
<img alt="[OpenBSD]" SRC="/images/smalltitle.gif">
<p>
<h3><font color=#e00000><strong>OpenBSD Security Views</strong></font></h3>
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 <a href=crypto.html>
cryptography software, we are able to take cryptographic
approaches towards fixing security problems.</a><p>
Like most readers of the
<a href=http://www.geek-girl.com/bugtraq/index.html>
BUGTRAQ mailing list</a>,
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.<p>
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.<p>
Some members of our security auditing team work for
<a href=http://www.secnet.com>Secure Networks</a>, 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.<p>
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
<a href=http://www.secnet.com/sni-advisories/sni-19.bsd.lpd.advisory.html>
lpd advisory from Secure Networks.</a><p>
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 <a
href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a>.<p>
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:
<ul>
<li>Occasionally we find a simple one we missed before.
<li>Security is like an arms race; the best attackers will continue
to search for more complicated exploits, so we should too.
</ul>
The auditing process is not over yet, and as you can see we continue
to find and fix new security flaws.<p>
<p>
<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
in OpenBSD 2.2. Some of these problems still exist in other
operating systems.
<ul>
<li><a href=advisories/rfork>Rfork() system call flaw (patch included)</a>
<li><a href=advisories/procfs>Procfs flaws (patch included)</a>
<li><a href=advisories/signals>Deviant Signals (patch included)</a>
</ul>
<p>
<h3><font color=#e00000><strong>OpenBSD 2.2 Security Advisories</strong></font></h3>
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.
<ul>
<li><a href=errata.html#f00f>Intel P5 f00f lockup (patch included)</a>
<li><a href=advisories/sourceroute>Sourcerouted Packet Acceptance</a>
<a href=errata.html#sourceroute>(patch)</a>
<li><a href=errata.html#ruserok>Setuid coredump & Ruserok() flaw (patch included)</a>
<li><a href=advisories/sourceroute>Read-write mmap() flaw</a>
<a href=errata.html#mmap>(patch included, revision 3)</a>
<li><a href=errata.html#ldso>MIPS ld.so flaw (patch included)</a>
</ul>
<p>
<h3><font color=#e00000><strong>Watching our Security Changes</strong></font></h3>
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.<p>
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.<p>
People who are really concerned with critical
security can do a number of things:<p>
<ul>
<li>If you understand security issues, watch our
<a href=mail.html>source-changes mailing list</a> 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.
<li>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.
<li>Install a binary <a href=snapshots.html>snapshot</a> for your
architecure, which are made available fairly often. For
instance, an i386 snapshot is typically made available weekly.
</ul>
<p>
<h3><font color=#e00000><strong>Other Resources</strong></font></h3>
Other security advisories that have (in the past) affected OpenBSD can
be found at the <a href=http://www.secnet.com/nav1.html>Secure Networks archive</a>.
Some OpenBSD audit team members worked with Secure Networks on discovering
and solving the problems detailed in some of their security advisories.
<p> If you find a new security problem, you can mail it to
<a href=mailto:deraadt@openbsd.org>deraadt@openbsd.org</a>.
<br>
If you wish to PGP encode it (but please only do so if privacy is very
urgent, since it is inconvenient) use this <a href=advisories/pgpkey>pgp key</a>.
<hr>
<a href=index.html><img src=/back.gif border=0 alt=OpenBSD></a>
<a href=mailto:www@openbsd.org>www@openbsd.org</a>
<br>
<small>$OpenBSD: security.html,v 1.38 1998/02/26 22:45:42 deraadt Exp $</small>
</body>
</html>
![[BACK]](/icons/back.gif){kind=icon}
Return to security.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www