What is Secure Bit 2?

Secure Bit 2 is a patent pending, Transparent, Hardware solution against Buffer-Overflow attacks on control data (return-address and function-pointer attacks in particular). It is a continuation of our original work on Secure Bit: both are based on an added Secure Bit, but the management of the bit is dramatically different. We refer to the new management scheme as Secure Bit 2. Secure Bit is a concept to provide a hardware bit to protect the integrity of addresses for the purpose of preventing buffer-overflow attacks. SecureBit2 is our second implementation of a protocol to manage the Secure Bit. SecureBit2 is completely transparent to software, and provides 100% backward compatible with legacy code. Unlike several methods that only reduce the probability of a successful attack, SecureBit2 can detect and prevent all address-corrupting buffer-overflow attacks. SecureBit2 is transparent to software, and has little run-time performance penalty (almost none). The goal of SecureBit2 is to provide hardware support to protect against current and future generations of buffer-overflow attacks by protecting the integrity of addresses: addresses passed in buffers between processes are invalid. Robustness and transparency are demonstrated by emulating the hardware, and booting Linux on the emulator, running application software on that Linux, and performing known attacks.

How does Secure Bit 2 work?

The underlying concept is to keep track of data that are controlled by users (other processes and devices) and prevent it from being used as control data. The main idea of Secure Bit 2 can be summed up as:

“data passing from another domain must not be used
as a return address or a function pointer”.

This observation is not new: for example [Howard and LeBlanc] stated in their book that “Data must be validated as it crosses the boundary between untrusted and trusted environments.” To be able to enforce that condition while maintaining transparency to legacy programs, we modify the hardware as follows:

An additional bit is added to each memory word. This bit serves as integrity meta data of that memory word. Any word with Secure Bit set is an untrustworthy word and should not be used as control data.

To manage the Secure Bit:

A new memory manipulating mode (sbit_write mode) is introduced to the processor. In this mode, any load-store instruction always sets the Secure Bit of the associated target. In normal mode, the load-store instructions simply handle the Secure Bit as a normal data bit. (The implementation can be simply a flag in the FLAGS register.)
Moving data between processes, especially between a process and the operating system, will be forced to execute in the sbit_write mode (set the Secure bit). Since moving data between processes requires kernel invocation, enforcing this condition simply requires a trivial modification to the kernel.
Return instructions, indirect-call instructions, and indirect-jump instructions validate the return address or function pointer before continuing normal operations. If the secure bit is set, raise an exception.
Unlike most hardware-supported security that tightly couples its mechanisms with segmentation (which is not common across platforms and is not transparent to compilers or programmers), Secure Bit is 100% backward compatible to legacy code and transparent to users. As a case study, we used the BOCHS IA-32 emulator to boot Red Hat Linux and run applications such as Apache, gcc, and JVM.

This animation shows the details of Secure Bit 2. (click to see larger image)

How can I test Secure Bit?

To demonstrate the completeness of Secure Bit, its compatibility, its transparency, and its effectiveness we implemented it in both an emulator and a hardware simulator. The best way to elaborate the details of Secure Bit is to create an implementation that is complete and that we can really attack. Implementing Secure Bit in an emulator provided a platform for demonstrating completeness, compatibility, and transparency because we could boot Linux on it. Moreover, we want to capture all possible hardware issues involved in investing in a complex IC design so we also implemented Secure Bit in a hardware simulator. Together both the emulation and the simulation allow us to test Secure Bit with a real operating system under real attacks and to capture all hardware behavior. In fact, this page is also running on our emulator.

You may download this emulator and test image from our software page.

What kinds of attack that Secure Bit 2 can (or cannot) protect?

Secure Bit 2 can protect against attacks on control data and its variations. This includes (but not limited to) first-generation stack smashing (return-address attacks), function-pointer attacks, and Global Offset Table attacks (This type of attack can be use to bypass several software protection mechanisms). In general, it also covers most variations of integer-overflow attacks. Secure Bit 2 have been tested with the following attacks:

Generic Return Address Attacks

Generic Function-Pointer Attacks

Global Offset Table attacks.

Apache SLAPPER worm (an attack to the vulnerable version of Apache mod_ssl). SLAPPER is also served as an example of multistage buffer-overflow attack.

(more)

However, there are certain types of buffer-overflow attacks that only modify data. Password Attack is a good example. We are now working on a next generation of Secure Bit which will also handle this type of buffer-overflow attack.

Actually, this page is also hosted on the vulnerable version of Apache SLAPPER. However, our Secure Bit 2 Box is powerful enough to prevent such attack without any software patch.

Does Secure Bit 2 compatible with Java Just-in-time Compiler and pthread ?

Yes. Secure Bit 2 works fine with sun JVM and pthread. Unlike other methods that modify memory organization or integrity which may prevent non-LIFO control flow and Inter-process communication (IPC) using in most pthread software (including SUN JVM), Secure Bit 2 is 100% compatible with legacy binary and transparently provides protection mechanism to the unmodified processes while allowing process communication. Without any modification, we can run any pthread compliant sofware (including SUN JVM) and still provide protection against buffer-overflow attacks. Here is the list of some serious things that we have done with our Secure Bit 2 box:

Use GCC to compile OpenSSL library

Use GCC to compile Apache and mod_ssl

Run Apache web server with mod_ssl enable

Compile and run Java Application with SUN j2sdk1.4.1_07 (and kaffe, a free implementation of JVM)

Run OpenSSH client and server (SSHD and SSH)

Run telnetd and wu-ftpd

etc.

counter Update: November 23, 2007