Linux Zero Day Attack Protection - Part 1

The first in a five part series on how to deploy Zero Day Attack Protection in Linux, by combining a number of projects to complete the secret sauce.

by  John Buswell     

This article would not be possible without the help of Rodney Sizemore, CEO Pro OnCall Solutions. Rodney was gracious enough to permit me to Open Source this particular technology to the community via this article. So many thanks to Rodney and his great team at Pro OnCall Solutions. The solution in this article does work, and is powering part of the infrastructure at o3 magazine today. At the end of the series, you will have the necessary steps to integrate Zero Day Attack Protection into your Linux deployment, a solution that is as close to unhackable Linux as you will likely get.

What is a Zero Day Attack?

A Zero Day attack is a security vulnerability for which there is no patch or work around to counter-act the problem. The threat of Zero Day attacks is the time from which the vulnerability can be exploited until the IT administrator has patched the problem. Zero Day attack scenarios vary from a publicly available exploit for which the vendor has not yet provided a fix, to the IT administrator who simply has not patched the system or is unaware of the problem.

What is Zero Day Attack Protection?

There are a number of different ways to provide Zero Day Attack Protection, most companies offer complex pattern and protocol analysis on real-time traffic in an attempt to detect unusual activity, and then block it. The problem with this approach is that its not really Zero Day Attack Protection, its more like fancy Intrusion Prevention. The solution provided in this series of articles is TRUE Zero Day Attack Protection. It is a series of technologies and techniques that when combined together counter-act the tools used by malicious users to enter the system.

Who developed this technique?

The technique was developed by a small engineering team at Spliced Networks, consisting of John Buswell and Frank Boyd. Spliced Networks had a working prototype as early as March 2003, the solution evolved to provide full Zero Day Attack Protection by early 2005. Spliced Networks was an Open Source Appliance company that built a general purpose Linux based operating system that ran on compact flash. Spliced Networks took a minimal approach and focused on providing image based deployments for servers, similar to those you see used in virtualized environments today. The technique enables application partitioning, so if security between applications running on the same server is the goal, this technique provides a more secure option to virtualization.

Buffer OverFlow Attacks

One of the most common attacks used in computer systems are buffer overflows. This is not intended to be a detailed discussion of those attacks, but for those unfamiliar with such attacks, a buffer is typically a string that holds data. Often the buffer is populated with data from user input, so badly written code will not take into account that the user may attempt to overload the buffer by entering too much data. For example, code might take a source string thats 20 bytes long and attempt to copy it into a string variable that only holds 16 bytes. Those additional 4 bytes could potentially overrun into other areas of memory, as its exceeded the boundary of the variable. Some of the security features below provide protection against those scenarios and others, but on a system-wide protection basis rather than code changes that a programmer needs to make to current code.

Stack Smashing Protector

As of GCC 4.1, the Stack Smashing Protector is integrated into GCC. This is an extension for the GCC compiler used for protecting applications from stack-smashing attacks. The solution works by automatically inserting code that protects the C application at compilation time. The protection works by providing buffer overflow detection and reordering of variables to avoid the corruption of pointers. The reordering works by placing buffers after pointers to avoid the corruption of pointers that could be used to corrupt random memory locations. It also copies pointers in function arguments to an area preceding local variable buffers to prevent the corruption of pointers and it omits instrumentation code from some functions to decrease the performance overhead. By using the stack smashing protector, one of the basic tools used by malicious users, and one of the most common mistakes in application coding is taken off the table.

Getting Random Numbers Faster

The next component that is used in this solution is frandom, which is a faster and better random number generator than the typical /dev/urandom used in Linux. The frandom component is pretty trivial but since its several orders of magnitude faster than urandom, it provides a performance boost that can counter-act some of the additional measures used for security.

FORTIFY_SOURCE

This is another set of patches for GCC, these provide runtime buffer overflow protection for applications that have been compiled with GCC. It provides lightweight buffer overflow protection to some memory and string functions. It offers advantages over mudflap, a similar project as it has a much smaller runtime overhead.

strlcat and strlcpy

Everyone knows that string manipulation functions are prime targets for finding security vulnerabilities, especially in applications written in C. To further protect against buffer overflow attacks, strlcpy and strlcat functions are used to replace strcpy and strcat functions that are typically used. These functions come from the OpenBSD project. These functions provide the developer with an easy way to write bullet proof code, with both functions guaranteeing to NUL-terminate the destination string for all strings. Both functions also take into consideration the size of the destination string, preventing overloading of the destination string. These functions will truncate the strings appropriately if you attempt to copy a larger source string into a smaller destination string.

Position Independent Executable Support (PIE/PIC)

Position Independent Code can be copied to any memory location without modification and be executed there. The memory location is typically determined by the compiler / linker when the code is built, with a particular offset. This is how malicious users can determine how and where to execute code in order to take advantage of a particular exploit. This is one of the reasons why its important to hide version numbers of applications, operating system types and to avoid using pre-built binaries from package management systems. If an attacker can determine your running versions and obtain the same copy as you did, they now have a roadmap for breaking into your system. Position Independent Executables get around this problem by allowing the memory location to be determined at run-time rather than compile time. This makes it a lot more difficult for an attack to determine the memory location, instead of having a map, they now have to try to win the lottery. Position Independent Executables require the entire platform to be rebuilt, later on in the series we will demonstrate how to disable relocatable code, making it impossible to run statically linked executables and statically linked libraries. This makes the system extremely secure, as the system-wide policy prevents non-PIE code from executing on the system.

In GCC, the options -fpie / -fPIE options are available and function similar to -fpic/-fPIC. There are also some patches to binutils that need to be done. Now rebuilding the entire Linux system is a bit of a task, however this solution calls for a minimal approach. Spliced Networks built a custom build environment, however today, a similar environment can be found at the Hardened Linux From Scratch project.

Hardened Linux From Scratch

For step by step instructions on how to build a completely Position Independent Linux system, follow the Kernel 2.6 and GLIBC version of the Hardened Linux From Scratch project. The book is well written, while it does not contain all the components used by Spliced Networks, for the purpose of this technique it is sufficient enough to provide the initial base system. Follow along the instructions to the end of Chapter 6. Do not follow the instructions beyond chapter 6 as our solution takes a different approach.

Next Article

The next article will use the resulting skeleton Linux system produced in this article as the foundation for the Unhackable Linux platform.