Software Security Features

OpenBSD handles its internal memory in a slightly different way than most other UNIX-like operating systems, and also builds software slightly differently, all to enhance security. Generally speaking, most free software developers are satisfied if their software compiles and runs most of the time, and are not so careful about the internal security of their software. In the past several years, however, we've seen root-level exploits in everything from web servers to MP3 players. As the OpenBSD team cannot audit all software that any admin might install, they've taken the step of securing third-party software during the building and running process. These features may or may not work on all hardware platforms, but is certainly a step in the right direction. OpenBSD's five standard security features are the non-executable stack, PROT_ purity, WorX, separate read-only segments, and propolice.

Non-Executable Stack

The stack is a section of memory used to keep track of mathematical operations or system internal operations. On OpenBSD, memory on the stack cannot be executed, which eliminates many possible attack techniques.

Executing code on the stack is generally considered poor programming practice, but some developers did it anyway. When OpenBSD implemented this change, it caused quite a few programmers to receive numerous bug reports about their software, and forced them to change this behavior to something more secure. This is good not just for the security of OpenBSD users, but all people who use that software.

PROT_ purity

According to the POSIX specification, each page of memory has three possible permissions: read (PROT_READ), write (PROT_WRITE), and execute (PROT_EXEC). In theory, if you set a piece of memory to be read and write only, information in that chunk of memory cannot be executed as a program. In practice, most implementations of UNIX assume that if you have read permissions on a page of memory, the contents of that page can be executed. In many cases, this is because of limitations in the hardware, but the most common cause is poor kernel programming. An attacker can possibly exploit this.

As of release 3.3, the OpenBSD kernel carefully tracks memory permissions and enforces them on hardware that allows it. The Sparc, Sparc 64, Alpha, and HP hardware architectures support this out-of-the-box. Older hardware, such as VAX and 68K Macs, cannot support this at all. The popular i386 architecture divides memory into two regions, executable and not-executable. As of release 3.3, the stack is stored in the non-executable area. While PowerPC is slightly more flexible than i386, it's not good either.

For the forthcoming OpenBSD 3.4 release, the i386 platform will get per-page memory execution protection by widely separating the text and data memory segments. Similarly, the PowerPC platform will divide executables and data between different areas of memory to create the same effect. This requires careful tweaking within the kernel and the ld(1) linker.

Many of the other software security features are based upon PROT_ purity.

WorX

WorX stands for "Write or Execute" and may be written as W^X or "PROT_WRITE XOR PROT_EXEC." In an OpenBSD system, pages of memory are either writable or executable — but not both. This is heavily dependent upon PROT_ purity, of course.

A common exploit technique is to trick a program to write information to memory, and then execute the contents of that piece of memory. An attacker may convince a program to write to a chunk of memory, but the kernel will not allow that memory to be executed. Attackers who rely upon this will be quite frustrated trying to break into an OpenBSD machine!

Note

On ELF-based systems, shared-library programs have two segments called GOT and PLT that on some architectures need to be both writable and executable. These have been isolated in their own segments, hence protected from such attacks.

Read-Only Segments

A segment of memory containing program code traditionally had two parts: actual code and read-only data. This was the standard in the day of a.out binaries, but the practice continued when the world moved on to ELF binaries. The read-only data has been split out into its own segment. While this would be difficult to actually exploit, it's not impossible. It also enhances performance and caching, however, so it's worth implementing.

Propolice

Propolice checks function return addresses upon completion of a function, to guarantee that they have not moved. A canary, or random value constant per run, is used to make the check un-fakeable by an attacker. A common exploit technique is to overwrite or overflow variables. If a return address moves, the program is immediately shut down, and an error is logged to syslogd. Additionally, propolice rearranges the placement of objects in internal memory so that the objects most likely to overflow (i.e., buffers) are more easily detected. While having a program crash under attack is unpleasant, a logged crash is much better than a rooted machine!

With these security features in place, software running on OpenBSD is largely protected even from itself.

With the ability to control how software executes, where it can be executed, what system calls a program can use, and what the kernel itself permits, Open-BSD can prevent any number of attacks.

Now that you understand the basics of OpenBSD's advanced security features, let's look at how to configure the kernel itself.