www/security.html - diff

Return to security.html CVS log

Up to [local] / www

Diff for /www/security.html between version 1.44 and 1.45

version 1.44, 1998/03/03 03:09:21

version 1.45, 1998/03/06 11:58:12

Line 7

</head>

Line 23

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</a>, we are able to take cryptographic

cryptography</a>, we are able to take cryptographic approaches towards

approaches towards fixing security problems.

fixing security problems.

Like most readers of the

Like many readers of the

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.

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.

in mind. Code often gets audited multiple times, and by multiple

people with different auditing skills.

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.

with the OpenBSD stance. OpenBSD passes Ballista's tests with flying

colours.

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

lpd advisory from Secure Networks.</a>

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

commonplace in security forums like <a

commonplace in security forums like

href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a>.

<a href=http://www.geek-girl.com/bugtraq/index.html>BUGTRAQ</a>.

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:

<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

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>

The auditing process is not over yet, and as you can see we continue

Line 92

Line 105

<h3>OpenBSD 2.1 Security Advisories</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

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>

<li><a href=advisories/rfork>Rfork() system call flaw (patch included)</a>

Line 103

Line 121

<h3>OpenBSD 2.2 Security Advisories</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>

<li><a href=errata.html#f00f>Intel P5 f00f lockup (patch included).</a>

Line 122

Line 141

<h3>Watching our Security Changes</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

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.

have security consequences we could not predict. We do not have the

time resources to make these changes available in the above format.

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 limited impact and unproven

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

security, patches will show up here VERY quickly.

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:

things:

<ul>

<li>If you understand security issues, watch our

Line 147

Line 167

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

architecure, which are made available fairly often. For

instance, an i386 snapshot is typically made available weekly.