2.5. Inherent Protections

FreeBSD and OpenBSD provide excellent foundations for secure servers. They have security underpinnings that other operating systems don't. Just by choosing FreeBSD or OpenBSD, you automatically benefit from built-in protections. OpenBSD distinguishes itself especially along these lines. Its "secure by default" mantra means you frequently don't get choices about security options: you're given the most secure option by default and you'd have to go out of your way to be less secure. FreeBSD tends to be a little more flexible about security. It doesn't force your configuration one way or another, but gives you some of the same options and lets you choose. It also doesn't always activate the most secure settings by default. It's up to you, with either operating system, to figure out what works best for your environment and set the options appropriately.

This section discusses several inherent security-related technologies, some are available in both operating systems and some are available only in one. Some of them are optional, and others are mandatory.

2.5.1. Fighting Buffer Overflows

OpenBSD incorporates two technologies into its kernel that fight the dreaded buffer overflow. They are utterly transparent to programs running on OpenBSD because they are integrated into the operating system and the compiler. They significantly limit the damage that's possible from the classic buffer overflow problems. The first is W^X memory protection and the second is ProPolice stack protection.

2.5.1.1 W^X memory protection

One of the fundamental principles exploited by a buffer overflow attack is the fact that data (on an Intel i386-based system, anyways) can be executed. That is, an attacker can change the value in the instruction pointer to the address of any location in memory and the CPU will execute the bytes it finds there as instructions. Some non-Intel CPU architectures prevent executing code on memory pages that are not marked executable, but Intel hardware does not support that behavior. Since the hardware can't help us, OpenBSD incorporated a software technique into its kernel.

The W^X (pronounced "write XOR execute") technique tries to make memory pages either writable or executable, but never both. That is, if you can write to the memory page (i.e., it contains some data for the program like its heap or stack), then the page can't be executable. If you can execute the page (that is, if it contains instructions), then it will not be writable. This functionality is implemented by extensions to the compiler that work in concert with specific features in the runtime loader (ld.so) and the kernel itself. The kernel itself keeps track of this quality for each memory page.

The goal of W^X is to make a program crash if it attempts to write to an execute-only page or execute code on a write-only page. The kernel and the loader try to make sure that a program's instructions are always allocated on pages marked executable, and data (e.g., the program's stack and heap) is always allocated to pages that are writable but not executable. It's not flawless, but it sets up a significant barrier to misusing buffer overflows. W^X frequently turns a high-impact problem, like privilege escalation through stack smashing, into a low-impact problem: badly written programs crash. While you'd rather not have an important program crashing a lot, it's a lot better than it being exploited.

2.5.1.2 ProPolice stack protection

The W^X technique is a good one, but keeping "defense in depth" in mind, the OpenBSD team didn't stop with just that one protection. They also incorporated stack protection called "ProPolice" by Hiroaki Etoh at IBM. As an extension to the GCC C/C++ compiler, ProPolice rearranges buffers and variables on the stack in a variety of ways to thwart would-be hackers.

Another principal that hackers use when crafting exploits is the fact that programs are loaded into memory in exactly the same way every time. Creating an exploit that loads just the right machine instructions into the right memory location is a time-consuming process and it always involves a little trial and error. Once he has figured out what inputs to send, though, the hacker knows that, given the same inputs, the program will perform the same way each time. ProPolice breaks this fundamental assumption. It inserts a random "canary" value into every function frame. When a program returns, code that has been added by the compiler checks to make sure the canary value has not changed. If it has, the program will log an error and crash.

It's almost impossible to defeat this system unless the hacker can guess the canary value and insert it into his attack input. However, there are essentially 2³² (about 4 billion) possible canary values, and a different one is chosen for each and every function call. You might think he can just keep trying his exploit over and over with the same value in the canary position, and eventually through luck his canary value and the random one used by the program will match. That's true. Mathematically speaking he will have to attempt it billions of times before he succeeds. In this case we are counting on detecting his attempts through some means (perhaps the logs) before he makes billions of attempts. Don't forget there's still W^X to get around.

2.5.2. Cryptography

Cryptography is a critical component in most security architectures. Performing cryptographic operations quickly, safely, and correctly is vital to the entire security infrastructure that is built on top of cryptography. SSL web connections, SSH, IPv6, VPN connections, and many other security tools need cryptography to work correctly. OpenBSD and FreeBSD excel at supporting not just software cryptography, but hardware-based cryptography. Rather than having hacked up drivers for a random assortment of cards, they have a cryptographic framework, allowing them to integrate cards from different vendors and provide a uniform application programming interface (API) to software.

OpenBSD and FreeBSD support essentially the same list of hardware cryptographic coprocessors, which basically consists of boards using several HiFn chipsets as well as the Broadcom Ubsec chipset. You can find HiFn cards under the "PowerCrypt" and "XL-Crypt" names from a company called GTGI. The Broadcom chipset appears in cards that bear the NetCryptX name. Information on how to purchase the cards and how much they cost is scarce.

Both OpenBSD and FreeBSD integrate these cards directly into the crypto framework (see crypto(4) on OpenBSD and crypto(9) on FreeBSD), which is a uniform set of kernel APIs for performing cryptographic operations. Once the card is installed, OpenSSL and the ipsec(4) infrastructure will all use the hardware-provided algorithms. If the card provides a random number generator (not all do), the kernel will use it as its source of randomness. Some newer versions of the cards support cryptographic algorithms like AES that are not yet exported through the crypto API. Taking advantage of a hardware cryptographic accelerator, however, is about as painless as it possibly could be.

2.5.3. Code Review

Both BSDs have excellent security track records, though it is arguable that OpenBSD has a few more bragging rights. Both FreeBSD and OpenBSD review code before it is committed to the operating system. The OpenBSD team, however, takes it a step further. They audit software before it is added to the ports system, too. You will notice in later chapters that we sometimes have to recommend that you install software from source on OpenBSD because no port exists. With so much software and only a limited number of people who volunteer time to review software for security issues, the OpenBSD team cannot review everything that everyone would like to run. It's actually quite remarkable how much software they have reviewed.

The OpenBSD team, during its audits, routinely discovers buffer overflows, format string problems, and a host of other common programming errors. They share their findings with the software developers and sometimes create a solution or workaround so that the code can safely be integrated in OpenBSD. Very often the version of software that you run in OpenBSD is not exactly what the software's original author distributes. Patches are applied to impose privilege separation, make the software run under a specific user by default, or to correct unsafe behavior.

As a general principle, you want to run as much software out of the base operating system as you can to take advantage of the efforts of the teams that audit the software. Although there are plenty of places where we recommend considering software that is not installed by default, you must be conscious of what you might be giving up and what you are gaining.