mirror of https://github.com/openbsd/www.git
310 lines
11 KiB
HTML
310 lines
11 KiB
HTML
<!doctype html>
|
|
<html lang=en>
|
|
<meta charset=utf-8>
|
|
|
|
<title>OpenBSD: Security</title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link rel="stylesheet" type="text/css" href="openbsd.css">
|
|
<link rel="canonical" href="https://www.openbsd.org/security.html">
|
|
|
|
<style>
|
|
h3 {
|
|
color: var(--red);
|
|
}
|
|
</style>
|
|
|
|
<h2 id=OpenBSD>
|
|
<a href="index.html">
|
|
<i>Open</i><b>BSD</b></a>
|
|
Security
|
|
</h2>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
For security advisories for specific releases, click below:
|
|
|
|
<p>
|
|
|
|
<a href="errata20.html">2.0</a>,
|
|
<a href="errata21.html">2.1</a>,
|
|
<a href="errata22.html">2.2</a>,
|
|
<a href="errata23.html">2.3</a>,
|
|
<a href="errata24.html">2.4</a>,
|
|
<a href="errata25.html">2.5</a>,
|
|
<a href="errata26.html">2.6</a>,
|
|
<a href="errata27.html">2.7</a>,
|
|
<a href="errata28.html">2.8</a>,
|
|
<a href="errata29.html">2.9</a>,
|
|
<a href="errata30.html">3.0</a>,
|
|
<a href="errata31.html">3.1</a>,
|
|
<a href="errata32.html">3.2</a>,
|
|
<a href="errata33.html">3.3</a>,
|
|
<a href="errata34.html">3.4</a>,
|
|
<a href="errata35.html">3.5</a>,
|
|
<br>
|
|
<a href="errata36.html">3.6</a>,
|
|
<a href="errata37.html">3.7</a>,
|
|
<a href="errata38.html">3.8</a>,
|
|
<a href="errata39.html">3.9</a>,
|
|
<a href="errata40.html">4.0</a>,
|
|
<a href="errata41.html">4.1</a>,
|
|
<a href="errata42.html">4.2</a>,
|
|
<a href="errata43.html">4.3</a>,
|
|
<a href="errata44.html">4.4</a>,
|
|
<a href="errata45.html">4.5</a>,
|
|
<a href="errata46.html">4.6</a>,
|
|
<a href="errata47.html">4.7</a>,
|
|
<a href="errata48.html">4.8</a>,
|
|
<a href="errata49.html">4.9</a>,
|
|
<a href="errata50.html">5.0</a>,
|
|
<a href="errata51.html">5.1</a>,
|
|
<br>
|
|
<a href="errata52.html">5.2</a>,
|
|
<a href="errata53.html">5.3</a>,
|
|
<a href="errata54.html">5.4</a>,
|
|
<a href="errata55.html">5.5</a>,
|
|
<a href="errata56.html">5.6</a>,
|
|
<a href="errata57.html">5.7</a>,
|
|
<a href="errata58.html">5.8</a>,
|
|
<a href="errata59.html">5.9</a>,
|
|
<a href="errata60.html">6.0</a>,
|
|
<a href="errata61.html">6.1</a>,
|
|
<a href="errata62.html">6.2</a>,
|
|
<a href="errata63.html">6.3</a>,
|
|
<a href="errata64.html">6.4</a>,
|
|
<a href="errata65.html">6.5</a>,
|
|
<a href="errata66.html">6.6</a>,
|
|
<a href="errata67.html">6.7</a>,
|
|
<br>
|
|
<a href="errata68.html">6.8</a>,
|
|
<a href="errata69.html">6.9</a>,
|
|
<a href="errata70.html">7.0</a>,
|
|
<a href="errata71.html">7.1</a>,
|
|
<a href="errata72.html">7.2</a>,
|
|
<a href="errata73.html">7.3</a>.
|
|
<br>
|
|
<hr>
|
|
|
|
<ul>
|
|
<li><h3 id=goals>Goals</h3>
|
|
|
|
<p>
|
|
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 most vendors are
|
|
able to. We can make changes the vendors would
|
|
not make. Also, since OpenBSD is exported with <a href=crypto.html>
|
|
cryptography</a>, we are able to take cryptographic approaches towards
|
|
fixing security problems.
|
|
|
|
<li><h3 id=disclosure>Full Disclosure</h3>
|
|
|
|
<p>
|
|
Like many readers of the
|
|
<a href="https://marc.info/?l=bugtraq">
|
|
BUGTRAQ mailing list</a>,
|
|
we believe in full disclosure of security problems. In the
|
|
operating system arena, we were probably the first to embrace
|
|
the concept. Many vendors, even of free software, still try
|
|
to hide issues from their users.
|
|
|
|
<p>
|
|
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.<p>
|
|
|
|
<li><h3 id=process>Audit Process</h3>
|
|
|
|
<p>
|
|
Our security auditing team typically has between six and twelve
|
|
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. We are not so much looking for
|
|
security holes, as we are looking for basic software bugs, and if
|
|
years later someone discovers the problem used to be a security
|
|
issue, and we fixed it because it was just a bug, well, all the
|
|
better. Flaws have been found in just about every area of the system.
|
|
Entire new classes of security problems have been found during our
|
|
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.
|
|
|
|
<p>
|
|
Some members of our security auditing team worked for Secure Networks,
|
|
the company that made the industry's premier network security scanning
|
|
software package Ballista (Secure Networks got purchased by Network
|
|
Associates, Ballista got renamed to Cybercop Scanner, and well...)
|
|
That company did a lot of security research, and thus fit in well
|
|
with the OpenBSD stance. OpenBSD passed Ballista's tests with flying
|
|
colours since day 1.
|
|
|
|
<p>
|
|
Another facet of our security auditing process is its proactiveness.
|
|
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
|
|
<a href="https://marc.info/?l=bugtraq">BUGTRAQ</a>
|
|
would report that other operating systems were vulnerable to a <q>newly
|
|
discovered problem</q>, 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 that Secure Networks put out.
|
|
|
|
<li><h3 id=newtech>New Technologies</h3>
|
|
|
|
<p>
|
|
As we audit source code, we often invent new ways of solving problems.
|
|
Sometimes these ideas have been used before in some random application
|
|
written somewhere, but perhaps not taken to the degree that we do.
|
|
|
|
<ul>
|
|
<li>strlcpy() and strlcat()
|
|
<li>Memory protection purify
|
|
<ul>
|
|
<li>W^X
|
|
<li>.rodata segment
|
|
<li>Guard pages
|
|
<li>Randomized malloc()
|
|
<li>Randomized mmap()
|
|
<li>atexit() and stdio protection
|
|
</ul>
|
|
<li>Privilege separation
|
|
<li>Privilege revocation
|
|
<li>Chroot jailing
|
|
<li>New uids
|
|
<li>ProPolice
|
|
<li>... <a href="/innovations.html">and others</a>
|
|
</ul>
|
|
|
|
<li><h3 id=reward>The Reward</h3>
|
|
|
|
<p>
|
|
Our proactive auditing process has really paid off. Statements like
|
|
<q>This problem was fixed in OpenBSD about 6 months ago</q> have become
|
|
commonplace in security forums like
|
|
<a href="https://marc.info/?l=bugtraq">BUGTRAQ</a>.
|
|
|
|
<p>
|
|
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:
|
|
|
|
<ul>
|
|
<li>Occasionally we find a simple problem we missed earlier. Doh!
|
|
<li>Security is like an arms race; the best attackers will continue
|
|
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>
|
|
|
|
<p>
|
|
The auditing process is not over yet, and as you can see we continue
|
|
to find and fix new security flaws.
|
|
|
|
<li><h3 id=default><q>Secure by Default</q></h3>
|
|
|
|
<p>
|
|
To ensure that novice users of OpenBSD do not need to become security
|
|
experts overnight (a viewpoint which other vendors seem to have), we
|
|
ship the operating system in a Secure by Default mode. All non-essential
|
|
services are disabled. As the user/administrator becomes more familiar
|
|
with the system, he will discover that he has to enable daemons and other
|
|
parts of the system. During the process of learning how to enable a new
|
|
service, the novice is more likely to learn of security considerations.
|
|
|
|
<p>
|
|
This is in stark contrast to the increasing number of systems that
|
|
ship with NFS, mountd, web servers, and various other services enabled
|
|
by default, creating instantaneous security problems for their users
|
|
within minutes after their first install.
|
|
|
|
<li><h3 id=crypto>Cryptography</h3>
|
|
|
|
<p>
|
|
And of course, since the OpenBSD project is based in Canada, it is possible
|
|
for us to integrate cryptography. For more information, read the page
|
|
outlining <a href=crypto.html>what we have done with cryptography</a>.
|
|
|
|
<li><h3 id=advisories>Advisories</h3>
|
|
|
|
<p>
|
|
Please refer to the links at the top of this page.
|
|
|
|
<li><h3 id=watching>Watching our Changes</h3>
|
|
|
|
<p>
|
|
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; many simple bugs we fix do turn out to
|
|
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
|
|
beyond the previous major OpenBSD release. We make a limited
|
|
guarantee that these problems are of minimal impact and unproven
|
|
exploitability. If we discover that a problem definitely matters for
|
|
security, patches will show up here <strong>VERY</strong> quickly.
|
|
|
|
<p>
|
|
People who are really concerned with security can do a number of
|
|
things:
|
|
|
|
<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 <q>SECURITY FIX!</q>.
|
|
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.
|
|
However, building your own system from source code is not trivial;
|
|
it is over 850MB of source code, and problems do occur as we
|
|
transition between major releases.
|
|
<li>Install a binary snapshot for your
|
|
architecture, which are made available fairly often. For
|
|
instance, an amd64 snapshot is typically made available daily.
|
|
</ul>
|
|
|
|
<li><h3 id=reporting>Reporting problems</h3>
|
|
|
|
<p>
|
|
If you find a new security problem, you can mail it to
|
|
<a href="mailto:security@openbsd.org">security@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.txt">pgp key</a>.
|
|
|
|
<li><h3 id=papers>Further Reading</h3>
|
|
|
|
<p>
|
|
Numerous
|
|
<a href="events.html">papers</a> have been written by OpenBSD team members,
|
|
many dedicated to security.
|
|
</ul>
|