Multiple flexible security policies

Current DIFT systems hard-code a single security policy, which leaves them inflexible to counter evolving threats. This restricts their applicability, since high-level attacks such as SQL injections require tag management policies very different from those required by low- level exploits such as buffer overflows. SQL injection protection, for example, requires that the system prevent tainted SQL commands from being executed. While the hardware performs taint propagation, SQL string checks are extremely complex and dependent on SQL grammar, and should be performed in software. In contrast, some memory corruption protection techniques untaint tags on validation instructions, and raise security exceptions on access of tainted pointers. The policies required for these two protection techniques are very different.

In addition, real world software is ridden with corner cases [24, 41]. These corner cases often require custom tag propagation and check rules to be applied to certain instructions. To avoid false positives or false negatives due to such corner cases, it is essential that the system be able to flexibly specify security policies.

While existing DIFT systems provide protection against single attacks, it is now com- mon for attacks to exploit multiple vulnerabilities [11, 83]. Multiplexing all security poli- cies on top of a single tag bit would create false positives or false negatives due to the fact that certain policies are mutually incompatible with one another (e.g. SQL injection pro- tection vs. pointer tainting). It is essential for DIFT systems to be able to support multiple, concurrently active security policies to offer robust protection. This is turn necessitates the use of a multi-bit tag per word of memory. Every ”column” of bits would then correspond to a unique security policy (e.g. bit 0 of each tag could be used for buffer overflow protec- tion, bit 1 for SQL injection protection, etc.). While the exact number of policies is still a research topic, our experiments indicate that four policies suffice. This is discussed further in Chapter 4.

3.1.3 Software analysis support

While hardware maintains the state necessary for taint, software is responsible for config- uring the security policies that dictate the propagation and check modes adopted by the hardware. Tag manipulations require the addition of instructions to the ISA that can oper- ate upon tags. One of the main advantages of DIFT is that it can be used to catch security exploits on unmodified binaries. Support for this requires that the binary be agnostic of tags. These special tag instructions should thus be accessible only from within a supervisor operating mode.

Existing DIFT systems cannot protect the operating system since the OS runs at the highest privilege level. This is a shortcoming of these systems, since a successful attack on

the OS can compromise the entire system. In order to be able to apply DIFT to the oper- ating system, it is necessary for the software managing the analysis (or a software security handler) to be outside the operating system. The security handler is responsible for config- uring the propagation and check policies for the executing program, and for initializing tag values.

The security handler is also responsible for handling security exceptions. Current DIFT systems trap into the operating system on a security exception and terminate the applica- tion. Moving forward, it is more realistic to imagine that the DIFT hardware will identify potential threats for which further software analysis is required. An example is SQL injec- tion where hardware performs taint propagation, and software is responsible for determin- ing if the query contains tainted commands. Trapping to the operating system frequently to perform such an analysis is extremely expensive. Since OS traps cost hundreds of CPU cycles, even infrequent security exceptions can have an impact on application performance. Thus, the method of invoking the security handler should be via user-level tag excep- tions rather than expensive OS traps. These exceptions transfer control to the security handler in the same address space, at the same privilege level. Privilege level transitions are expensive due to events such as TLB flushes, saving and restoring registers, etc. In contrast, user-level tag exceptions incur an overhead similar to function calls. Keeping the overhead of invoking the security handler low allows for a further analysis to be performed flexibly in software, and increases the extensibility of the DIFT system greatly.

3.2 The Raksha Architecture

This section introduces Raksha1_{, a flexible hardware DIFT architecture for software se-}

curity. Raksha introduces three novel features at the architecture level. First, it provides a flexible and programmable mechanism for specifying security policies. The flexibility is

!"#" $%&'(#) *"+ ,&'(#) !"#" $%&'(#) *"+ ,&'(#) -.+()#./) 0.12/3

Figure 3.1: The tag abstraction exposed by the hardware to the software. At the ISA level, every register and memory location appears to be extended by four tag bits.

necessary to target high-level attacks such as cross-site scripting, and to avoid the trade-offs between false positives and false negatives due to the diversity of code patterns observed in commonly used software. Second, Raksha enables security exceptions that run at the same privilege level and address space as the protected program. This allows the integration of the hardware security mechanisms with additional software analyses, without incurring the performance overhead of switching to the operating system. It also makes DIFT applicable to the OS code. Finally, Raksha supports multiple concurrently active security policies. This allows for protection against a wide range of attacks.