www.openbsd.org Open in urlscan Pro
2620:3d:c000:178::80  Public Scan

Form analysis
0 forms found in the DOM

Text Content

OPENBSD SECURITY

--------------------------------------------------------------------------------

For security advisories for specific releases, click below:

2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5,
3.6, 3.7, 3.8, 3.9, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 5.0, 5.1,
5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7,
6.8, 6.9, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5.


--------------------------------------------------------------------------------


 * GOALS
   
   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 cryptography, we
   are able to take cryptographic approaches towards fixing security problems.


 * FULL DISCLOSURE
   
   Like many readers of the BUGTRAQ mailing list, 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.
   
   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.
   
   


 * AUDIT PROCESS
   
   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.
   
   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.
   
   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 BUGTRAQ 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 that
   Secure Networks put out.


 * NEW TECHNOLOGIES
   
   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.
   
   * strlcpy() and strlcat()
   * Memory protection purify
     * W^X
     * .rodata segment
     * Guard pages
     * Randomized malloc()
     * Randomized mmap()
     * atexit() and stdio protection
   * Privilege separation
   * Privilege revocation
   * Chroot jailing
   * New uids
   * ProPolice
   * ... and others


 * THE REWARD
   
   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 BUGTRAQ.
   
   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:
   
   * Occasionally we find a simple problem we missed earlier. Doh!
   * Security is like an arms race; the best attackers will continue to search
     for more complicated exploits, so we will too.
   * Finding and fixing subtle flaws in complicated software is a lot of fun.
   
   The auditing process is not over yet, and as you can see we continue to find
   and fix new security flaws.


 * SECURE BY DEFAULT
   
   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.
   
   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.


 * CRYPTOGRAPHY
   
   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 what we have done with cryptography.


 * ADVISORIES
   
   Please refer to the links at the top of this page.


 * WATCHING OUR CHANGES
   
   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.
   
   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
   VERY quickly.
   
   People who are really concerned with security can do a number of things:
   
   * If you understand security issues, watch our source-changes mailing list
     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.
   * 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.
   * Install a binary snapshot for your architecture, which are made available
     fairly often. For instance, an amd64 snapshot is typically made available
     daily.


 * REPORTING PROBLEMS
   
   If you find a new security problem, you can mail it to security@openbsd.org.
   If you wish to PGP encode it (but please only do so if privacy is very
   urgent, since it is inconvenient) use this pgp key.


 * FURTHER READING
   
   Numerous papers have been written by OpenBSD team members, many dedicated to
   security.