security.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>,
<a href="errata74.html">7.4</a>,
<a href="errata75.html">7.5</a>,
<a href="errata76.html">7.6</a>,
<a href="errata77.html">7.7</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 &mdash; 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&rarr;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>