Linux, OpenBSD, Windows Server Comparison: OpenBSD Security

• Default Installs
• OpenBSD Origins
• Secure by Default
• "Four years without a remote hole"
• UNIX Signal Handler and Open Source Software Fixes
• IP Filter Bug
• OpenBSD Daily Security Audit

Default Installs

So far we've looked primarily at problems that expose systems to unnecessary dangers which can be fixed by knowledgeable administrators. We have not looked explicitly how the default installs compare. It's very easy to rate the systems default installs, because only OpenBSD is specifically designed to be secure by default. There is no contest. For an operating system installed from the standard disks, using all default options, OpenBSD is far ahead of the leading Linux distributions, and even further ahead of any Windows system. A review of OpenBSD will show some of the prime characteristics of a system designed to be secure by default. Here we are looking at a general purpose operating system and so Linux comparisons will be to widely used general purpose distributions such as Red Hat. There are specialty Linux distributions such as Trustix and EnGarde that specifically configure Linux to be very secure.

OpenBSD Origins

OpenBSD has a well deserved reputation as the most secure general purpose operating system available. There are several reasons for this. For starters, creating a stable and secure system was the primary goal and reason for OpenBSD's creation. OpenBSD was an outgrowth of NetBSD. NetBSD is known for running on more hardware platforms than just about any other operating system. FreeBSD split from NetBSD because the developers wanted to optimize the system for performance on Intel processors. As a result, FreeBSD is widely regarded as the fastest OS that runs on Intel systems. OpenBSD split later with the goal of creating a reliable and secure OS. When someone or an organization has a clear and realistic goal and does not have conflicting priorities, the goal can normally be accomplished.

Strictly speaking, a system can only be optimized for a single factor. Reliability and security are not separate. Rather, reliability is a prerequisite for security. The large majority of security problems are the result of bugs. A bug is a system doing something unexpected or failing to do the expected, often in response to an infrequent or unexpected event. Historically, the most frequent and dangerous security problems on most systems have been buffer overflows: a service running as root, an administrator or the system, does something unexpected, for example, allows the execution of arbitrary code, in response to an unexpected event, such as the arrival of excessive data. Eliminating bugs is the first prerequisite of a secure system.

The BSD family of OSs is relatively small and simple compared to many of their competitors. This means there are less lines of code to have bugs. One key characteristic that sets OpenBSD apart from most other systems are periodic and systematic code audits. To quote from the OpenBSD site, http://openbsd.org/security.html, "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." The same OpenBSD page states that thousands of bugs were fixed in late 1996 and early 1997. Each release of OpenBSD, which comes every six months, includes new features and enhancements, but the focus remains on quality so OpenBSD's growth is evolutionary.

Secure by Default

In part, because it's not a commercial system, OpenBSD can take a secure by default stance. Their security page states "All non-essential services are disabled." OpenBSD has less services turned on by default than nearly any other system available. When I first wrote my web pages on Hardening OpenBSD Internet Servers, 2.7 was the current release. I identified 10 services that were turned on by default and I thought could be disabled on a machine intended as a web, FTP, e-mail, DNS or other Internet server or firewall. In 2.8, two of these were no longer on by default.

In the mid nineties, when OpenBSD was first developed, the Internet was much less hostile, and its was expected that UNIX machines would network locally, with other UNIX machines via services that are now widely regarded as LAN services, and not suitable for use across the Internet. The Portmap service is a key component on which many of these services depend and is still on by default; a comment describes it as "Nearly always needed". On the other hand, a very common service, NFS has been turned off by default since I've been familiar with OpenBSD (2.6). This is equivalent to Windows disk sharing.

Secure by default tends to be a problem for any system that attempts to be "easy to use" including most commercial systems because such systems appear to be less functional than ones with all common services enabled. For example, on the first Red Hat Linux system I installed in 1999, httpd was up and running when I first looked for it. In contrast I had to learn how to control services on OpenBSD before I could run a web server.

Part of the secure by default hope and assumption is that if services are not already turned on, people will learn something about them before turning them on. At a minimum they must have a knowledge of the function, a desire to turn it on and learn how to do that much.

It just happened that I wanted to run a web server on the Linux machine. It's likely that most Linux machines, even those set up as servers, won't be intentionally running user maintained web sites. Some users would never be aware that their PC was running a web server. Services that are turned on but not used are just an intruder invitation, especially those that run as root. Apache on Red Hat Linux 6.1 was not running as root.

Where a server, such as a web server is on by default but not used, it may never get turned off and you can be sure that it won't be updated if a security issue is found. Any administrator knowledgeable enough and dedicated to actively upgrade services when a security issue is found, would have already turned off all unused services.

Secure by default not only routinely turns off services that would otherwise be on, but it also typically does not install software that would otherwise be included in default installs. This will include specific services that are less used but it will also include support libraries that are not needed by those servers which are installed. Thus when an administrator adds a new function to a secure by default system, they are likely to find that they must also locate and install support libraries or functions that are not on the system.

A secure by default system is likely to have many file and directory related security settings that prevent ordinary (non root) users from doing things that are allowed on most systems. Examples include not allowing users to su to root unless they are in the wheel group or view systems files not needed for the ordinary use of the system.

"Four years without a remote hole"

The OpenBSD web site opens with a claim that attracts some attention including claims that it's not true or someone just found a bug that invalidates the claim. The statement is "Four years without a remote hole in the default install!" They do not provide a detailed explanation what this means so lets analyze it. I think "Four years without" is clear enough that it's not likely to provoke substantive discussion.

I've seen some claims that there was a bug in some piece of software that is commonly installed and is thus a "default" at the sites it's installed. I don't think that's what "in the default install!" means at all. I think it means in the software that will be running following an install from the standard media taking all the default options.

Commonly used software that is not on by default includes NFS, FTP, telnet, DNS and IP Filter (now removed from the CVS source tree for license reasons). Bugs or holes in any of these would not count because they are not "default install".

"remote" means network access. If a user is already logged in, either at the console or from a remote location but now acting locally via ssh, telnet or rsh, it doesn't count. It means via a network protocol. If for example, sshd which is on by default, had a buffer overflow that could be exploited via the network, without using it to log on, either with encrypted keys or a username and password, that might break the four year run.

Finally what does "hole" mean? I don't think it means bug. If you look at the OpenBSD Security Advisories under 2.8 you will find "May 29, 2001: Sendmail signal handlers contain unsafe code, leading to numerous race conditions." Sendmail is on by default and if hole meant bug then OpenBSD would need to change the opening web statement.

UNIX Signal Handler and Open Source Software Fixes

In the May 31, 2001 issue of the SANS Security Alert Consensus mailing list the lead article begins "An interesting research paper by Michal Zalewski of Bindview was released this week detailing various problems in the signal handler design of Unix applications. We expected to see some vulnerability advisories based on this problem in the near future; however, they've already started -- Sendmail (a widely deployed mail server on Unix) has released an updated version to fix the problems outlined in the paper."

The paper itself is dated May 16-17, 2001. It appears however that the authors did not publicly announce the problem until they posted an announcement to the Bugtraq mail list on May 28. The SANS Alert refers to Bugtraq archive. Apparently Michal Zalewski contacted key UNIX vendors so that they could fix their products before making a public announcement.

Also note that the OpenBSD fix is available with the announcement the day after the problem is publicly announced. I couldn't find any release dates on the Sendmail site. I would guess that OpenBSD was already working behind the scenes with authors of Sendmail and coordinated the timing so that the fix would appear just after the public announcement.

Later in the SANS Alert under the Sendmail specific item, they say the denial of service attacks would be possible and that root compromise was a possibility. There was no suggestion that any actual exploits or denial of service attacks had been developed let alone successfully used against anyone yet. Like most bugs, there is some idea of what definitely can be done with it but it's harder to know what the limits to the problem are. Someone more imaginative than those currently examining the problem might see additional ways to exploit the problem than those who first to study it.

This is a good example of how the open source model can work. Someone identifies a problem and notifies key parties behind the scenes. Fixes are developed and released at about the same time as the problem is announced. No black hat ever has a chance to exploit the problem.

Actually that is not true. There are millions of UNIX computers most of which use Sendmail as their mail transfer agent. Sendmail is on by default on nearly all systems with which it's included. It will be interesting to see how long it takes the various Linux vendors to have patches for their distributions. Of course even though some patches are out now and others will be soon, most systems will never be updated. That's no different than with commercial software. Once the vendors or open source authors have announced the problem and released fixes, they've done their job.

What's important here is that a problem was found by white hats via code review and analysis and that it was circulated in a way that key parts of the UNIX community released fixes before the black hats knew of the problem. With any proprietary product only the employees can look at the code. Once a current product is tested and released, no one is likely to look at existing code until someone reports a problem. Of course as some critics say, the vast majority of open source users do not review the code they use. What matters is that for any significant code, a lot more than the one or two authors directly involved do read the code.

IP Filter Bug

The speed of the Sendmail fix is not unusual for an OpenBSD response to any security related issue. Another recent security issue that affected OpenBSD was the fragment caching vulnerability in IP Filter. The OpenBSD Security Advisory said: "Apr 23, 2001: IPF contains a serious bug with its handling of fragment caching."

My recollection when I first read about it a week or two after the advisory was that it did sound serious. Serious enough that I pursued installing the patch. I had some difficulty with the OpenBSD patch and had to update from the IP Filter site. I believe the patch was posted about five days after the problem was first publicly discussed. As a point of contrast, not relevant to the systems being compared, but still rather interesting, Hewlett-Packard announced their fix to this problem on Jan. 23, 2002, or nine months to the day after the OpenBSD announcement.

Unlike the signal handling issue, this was not handled quietly behind the scenes but announced publicly by the person who found the problem. Once again though, it was found by someone not associated with the source code, reading the code and seeing the implications.

After I'd read most of the relevant matter and upgraded my IP Filter, my conclusion was that a more accurate description would be "an interesting theoretical bug" rather than a "serious bug". I understand why it was called serious and this emphasizes how seriously security is taken by the OpenBSD authors lead by Theo De Raadt. See below for why I did not consider this a serious bug.

It also returns us to the definition of a "hole" versus a "bug". I believe a hole means a bug that was actually exploited to in some way harm an OpenBSD system before a fix was posted on the OpenBSD site. Granted, if some system were compromised by this problem on May 30, as a practical matter, there would have been no way that the administrator could have been expected to learn of the problem and apply the fix in time to do any good. The system authors though, can't be responsible whether administrators fix their sites within a week or a month or never.

So what does "Four years without a remote hole in the default install!" really mean? It means that no one who has installed OpenBSD with default options has actually experienced a network based intrusion in four years. Since the OpneBSD authors can only go on what they know, it means no one who has reported such an intrusion. As OpenBSD is only used those who are more than casually concerned about security in the first place, it's very likely if such an intrusion had occured, it would have been reported. Even though OpenBSD is not widely used, it is an impressive record. I know in my Internet explorations, I've seen statements to the effect that many would be intruders, as soon as they determine a target system is OpenBSD, move onto other targets.

In the past four years there are less than 75 OpenBSD Security Advisories. Most of them are with peripheral products that are distributed with OpenBSD, like IP Filter and most sound a lot less serious than the IP Filter problem which I prefer to characterize as theoretical.

A quick look at my web site will leave little doubt that I'm aware of and concerned with security issues. Enough so that if I screw up, I can't blame anyone but myself. I think the practical implications of many bugs reported as serious security issues is greatly overstated. Had I understood the IP Filter problem as well, before I set about trying to fix it as I did afterwards, it's unlikely that I would have bothered, even though I consider my firewall to be my second most important security measure (after backups).

OpenBSD Daily Security Audit

The *BSD family, including OpenBSD, comes with a feature lacking in other operating systems I've worked with. It has a daily security audit that is turned on by default. Every night, an e-mail to root is composed that analyzes all kinds of security related settings. If any system files have changed or any security related permissions on key files or directories changed, any suid programs added to or modified on the system, any world writable directories created or any of several other changes that might indicate a security issue, an automated e-mail to root describes the changes. It's similar to having a system preinstalled with a Tripwire like system.

This can be turned off by a system administrator but I can't think why one would. As the system runs entirely locally, a very knowledgeable intruder should be able to defeat it, but not without considerable risk of triggering one or more alerts. Turning the system off would stop these. There are enough checks, that when you customize an OpenBSD system and tighten security, it normally takes several days of tuning, to make all the auditing system settings match the new system and thus stop sending security related warning messages. Until the actual system and auditing system are synchronized a new set of warnings is sent each night.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.