700px-Openbsd2.svgAmong all the many choices of hosting solutions available, OpenBSD is one of the most secure. The source code is freely available and has been continually audited by the OpenBSD auditing team since 1996. In eight years, there has been only ONE remote hole in the default install of OpenBSD. Binary emulation of many programs from Linux, FreeBSD, and several other Unix-like operating systems, is also supported under OpenBSD.

Goal

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

Full Disclosure

OpenBSD believes in full disclosure of security problems. 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, OpenBSD experience is that coding and releasing of proper security fixes typically requires about an hour of work — very fast fix turnaround is possible. Thus OpenBSD thinks that full disclosure helps the people who really care about security.


Audit Process

OpenBSD’s security auditing team typically has between six and twelve members who continue to search for and fix new security holes. They have been auditing since the summer of 1996. The process they follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. They are not so much looking for security holes, as they are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and they 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 their 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.

continue reading »

Some members of their 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 their security auditing process is its proactiveness. In most cases they have found that the determination of exploitability is not an issue. During their ongoing auditing process they find many bugs, and endeavor to fix them even though exploitability is not proven. They fix the bug, and they move on to find other bugs to fix. They 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 they managed such a success is the lpd advisory that Secure Networks put out.

The Reward

OpenBSD’s 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 their 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 they encountered were fixed before their 2.1 release, and then a far smaller number needed fixing for their 2.2 release. They do not find as many problems anymore, it is simply a case of diminishing returns. Recently the security problems they find and fix tend to be significantly more obscure or complicated.

The auditing process is not over yet, and as you can see we continue to find and fix new security flaws.

More Information

If security and robustness are important criteria in selecting a hosting platform, contact the knowledgeable Mikro-Data staff for more information about OpenBSD hosting solutions. We’re simply an email or phone call, 866-457-6287, away.

Comments are closed.