OpenBSD Memory Protection
One of the most common intrusion paths is to attack what’s in the computer’s memory. If intruders can access memory that they shouldn’t be able to access, or if they can make a program access memory it shouldn’t, they have any number of ways to get into the system.
OpenBSD includes a whole bunch of security features for system memory that the sysadmin never actually sees. You don’t need to turn on the nonexecutable stack; it’s just there.
Some of these features appear only in OpenBSD. Some appeared first in OpenBSD, and then spread elsewhere. Some came from research papers. Others build on hardware features.
The OpenBSD team takes a more proactive attitude about security features than many other projects. As an example, consider the ProPolice deployment several years ago. ProPolice is a compiler feature that prevents certain classes of buffer overflows. When you enabled ProPolice in the early days, a lot of software could not be built. Even more software could be built, but it crashed when used. These failures were not ProPolice problems. ProPolice simply exposed programming errors in the software. But many users and developers said that “enabling ProPolice breaks all kinds of stuff, so don’t turn it on.”
The OpenBSD team enabled ProPolice by default in a development snapshot. What happened? Stuff—a lot of stuff—broke. Many third-party applications needed by OpenBSD users either could not build or would not run. Third-party application vendors started receiving bug reports from OpenBSD users who were able to say exactly how the software was broken. Software vendors started fixing bugs.
ProPolice didn’t cause these crashes; it merely exposed bugs. By enabling ProPolice by default, OpenBSD gave the free software world incentive to fix those bugs. Eventually, as the type of bugs revealed by ProPolice became less common, other operating systems also enabled ProPolice. OpenBSD’s willingness to take this step improved computer security as a whole.
If you closely follow OpenBSD development, expect to see more of this behavior. The OpenBSD team does what it considers most correct, not what is most convenient or easiest.
The common memory security features you should know about include W^X, .rodata segments, guard pages, randomized memory allocations, ProPolice, and protecting atexit and stdio. We’ll cover each in turn.
W^X
W^X stands for Write Xor Execute. Once a program is loaded, that program’s pages in memory are either writable or executable, but not both.
A common exploit technique is to trick a program into writing information to memory, and then executing that piece of memory. An attacker might convince a program to write to a chunk of memory, but the kernel will not allow that memory to be executed.
Some hardware platforms (such as amd64) have hardware support for W^X. If that support exists, OpenBSD uses it.
.rodata Segments
A segment of memory containing program code traditionally had two parts: actual code and read-only data, or .rodata segments. In the past, some operating systems allowed programs to modify read-only memory. OpenBSD prevents this by leveraging hardware features when available.
Guard Pages
Many pieces of software used to access memory beyond what they allocated. If a program writes to memory that doesn’t belong to it, it’s writing to memory that belongs to a different program. Intruders use this to exploit programs. A guard page is a single page of memory next to the memory allocated by a program. The program cannot write to this memory. If the program tries to write to the guard page, it probably will crash. By enforcing this limit, OpenBSD protects other programs.
Using guard pages everywhere would use a lot of memory, so OpenBSD enables guard pages only in carefully selected places.
Address Space Layout Randomization
Traditionally, computers allocate memory consecutively. This can give intruders certain advantages. If they know that program A usually loads after program B, and they know they can make program B write to memory space outside its allocation, they can guess that they can write to program A’s memory space and make program A fail in a predictable manner. Doing so requires a certain degree of skill, but once one person figures out this exploit, innumerable people can use it.
OpenBSD randomizes where it allocates memory. Two programs started one after the other don’t get consecutive memory blocks. The randomization is done intelligently, to avoid wasting memory. Intruders cannot use one program against another in this manner.
ProPolice
ProPolice protects code against attacks that manipulate the memory stack. When code is compiled, ProPolice adds additional code to keep a program within its own area of memory. If ProPolice determines that specific areas of memory (called canaries) have been changed, it immediately aborts the program. Where other memory protection techniques prevent writing to executable memory, ProPolice terminates a process when writable memory that can be written to, but specifically should not, is changed.
And More!
OpenBSD includes a whole bunch of small memory guards scattered throughout. Here’s a small sampling:
-
The
malloc()andatexit()system calls mark memory nonwritable after updating it. -
File descriptor handling has been carefully audited throughout.
-
snprintfis async-signal-safe when no floats are involved.
And the list continues.
Could any of these be exploited in the real world? Some of them have, and some are just theoretical. But I would rather be protected against theoretical threats than assume no one can break something that has never been broken before.