For security advisories for specific releases, click below:
2.1, --- 1,29 ---- ! ! ! !
For security advisories for specific releases, click below: +
2.1,
***************
*** 73,82 ****
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
--- 76,85 ----
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 *************** *** 84,111 **** 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.
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.
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 --- 87,115 ---- 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. !
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.
!
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 *************** *** 119,134 **** 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 --- 123,140 ---- 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 *************** *** 138,158 **** 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. -
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. -
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. !
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.
!
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 --- 176,193 ----
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 *************** *** 192,198 **** 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:
The auditing process is not over yet, and as you can see we continue ! to find and fix new security flaws.
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.
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.
!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:
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. !
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. !
Please refer to the links at the top of this page. !
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:
SECURITY FIX!. If a problem is proven and serious, a patch will be available here very shortly after.
!
If you find a new security problem, you can mail it to
deraadt@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.
!
Numerous ! papers have been written by OpenBSD team members, many dedicated to security.
! If you find a new security problem, you can mail it to
deraadt@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.
!
Numerous ! papers have been written by OpenBSD team members, many dedicated to security.