www/security.html - diff

Return to security.html CVS log

Up to [local] / www

Diff for /www/security.html between version 1.440 and 1.441

version 1.440, 2019/04/02 12:46:57

version 1.441, 2019/05/27 22:55:26

Line 1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

<!doctype html>

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>OpenBSD: Security</title>

</head>

<style>

h3 {

color: var(--red);

}

</style>

<h2>

<font color="#e00000">Security</font>

Security

</h2>

<hr>

<p>

For security advisories for specific releases, click below:

<p>

<a href="errata21.html">2.1</a>,

Line 73

Line 76

<br>

<hr>

<ul>

<li><h3><font color="#e00000">Goals</font></h3><p>

<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

Line 84

Line 87

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.<p>

fixing security problems.

<li><h3 id=disclosure>Full Disclosure</h3>

<li><h3><font color="#e00000">Full Disclosure</font></h3><p>

<p>

Like many readers of the

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>

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

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>

<li><h3><font color="#e00000">Audit Process</font></h3><p>

<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

Line 119

Line 123

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>

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>

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

Line 138

Line 144

and only months later discovered that the problems were in fact

exploitable. (Or, more likely someone on

<a href="https://www.securityfocus.com/archive/1">BUGTRAQ</a>

would report that other operating systems were vulnerable to a `newly

would report that other operating systems were vulnerable to a <q>newly

discovered problem', and then it would be discovered that OpenBSD had

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.

<p>

<li><h3 id=newtech>New Technologies</h3>

<li><h3><font color="#e00000">New Technologies</font></h3><p>

<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.

<p>

<ul>

<li>strlcpy() and strlcat()

Line 172

Line 176

<li>ProPolice

<li>... <a href="/innovations.html">and others</a>

</ul>

<p>

<li><h3><font color="#e00000">The Reward</font></h3><p>

<li><h3 id=reward>The Reward</h3>

<p>

Our proactive auditing process has really paid off. Statements like

``This problem was fixed in OpenBSD about 6 months ago'' have become

<q>This problem was fixed in OpenBSD about 6 months ago</q> have become

commonplace in security forums like

<a href="https://www.securityfocus.com/archive/1">BUGTRAQ</a>.<p>

<a href="https://www.securityfocus.com/archive/1">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,

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

Line 192

Line 197

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>

complicated. Still we will persist for a number of reasons:

<ul>

<li>Occasionally we find a simple problem we missed earlier. Doh!

Line 201

Line 206

<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.<p>

to find and fix new security flaws.

<li><h3 id=default><q>Secure by Default</q></h3>

<li><h3><font color="#e00000">"Secure by Default"</font></h3><p>

<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>

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.<p>

within minutes after their first install.

<li><h3 id=crypto>Cryptography</h3>

<li><h3><font color="#e00000">Cryptography</font></h3><p>

<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>.</p>

outlining <a href=crypto.html>what we have done with cryptography</a>.

<li><h3><font color="#e00000">Advisories</font></h3><p>

<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>

<li><h3><font color="#e00000">Watching our Changes</font></h3><p>

<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>

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>

security, patches will show up here <strong>VERY</strong> quickly.

<p>

People who are really concerned with security can do a number of

things:<p>

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 "SECURITY FIX!".

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

Line 272

Line 281

instance, an amd64 snapshot is typically made available daily.

</ul>

<p>

<li><h3 id=reporting>Reporting problems</h3>

<li><h3><font color="#e00000">Reporting problems</font></h3><p>

<p> If you find a new security problem, you can mail it to

<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.txt">pgp key</a>.

<p>

<li><h3 id=papers>Further Reading</h3>

<li><h3><font color="#e00000">Further Reading</font></h3><p>

<p>

Numerous

<a href="papers/index.html">papers</a> have been written by OpenBSD team members,

<a href="events.html">papers</a> have been written by OpenBSD team members,

many dedicated to security.

</ul>

</body>

</html>