Execution Model Enforcement Via Program Shepherding
Total Page：16
File Type：pdf, Size：1020Kb
Execution Model Enforcement Via Program Shepherding Vladimir Kiriansky, Derek Bruening, Saman Amarasinghe Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 vlk,iye,saman ¡ @lcs.mit.edu Abstract no efficient way to require that the rules of this execution model Nearly all security attacks have one thing in common: they co- be adhered to. The result is that the execution model becomes, in erce the target program into performing actions that it was never practice, a convention rather than a strict set of rules. If this model intended to perform. In short, they violate the program’s execu- were enforced, and only program actions that the programmer in- tion model. The execution model encompasses the Application tended were allowed, a majority of current security holes would be Binary Interface (ABI), higher-level specifications from the pro- closed. For example, a common attack type overwrites a return ad- gram’s source programming language, and components specific to dress to point to a malicious destination. This destination is not a the program — for example, which values a particular function valid return target in the program’s execution model, and would be pointer may take. If this execution model were enforced, and only disallowed by enforcement of the model. program actions that the programmer intended were allowed, a ma- Most security attacks target data storing program addresses. It jority of current security holes would be closed. is unreasonable to try to stop all malevolent writes to memory con- In this paper, we employ program shepherding [26] to enforce taining program addresses, because addresses are stored in many a program’s execution model. Program shepherding monitors con- different places and are legitimately manipulated by the applica- trol flow in order to enforce a security policy. We use static and dy- tion, compiler, linker, and loader. Our model of security attacks namic analyses to automatically build a custom security policy for a assumes that an attacker is able to exploit program vulnerabilities target program which specifies the program’s execution model. We to gain random write access to arbitrary memory locations in the have implemented our analyses in the DynamoRIO [4, 5] runtime program address space. code modification system. The resulting system imposes minimal In this paper, we employ program shepherding [26] to enforce a or no performance overhead, operates on unmodified native bina- program’s execution model. Instead of attempting to protect data, ries, and requires no special hardware or operating system support. program shepherding monitors control flow in order to enforce a se- Our static analyses require source code access but not recompila- curity policy. We use static and dynamic analyses to automatically tion. The analysis process requires no user interaction, but is able build a custom security policy for a target program which specifies to build a strict enough policy to prevent all deviations from the the program’s execution model. This process requires no user in- program’s control flow graph and nearly all violations of the call- teraction, but is able to build a strict enough policy to prevent all ing convention, greatly reducing the possibility of an unintended deviations from the program’s control flow graph and nearly all vi- program action. olations of the calling convention, greatly reducing the possibility of an unintended program action. We have implemented our analyses in the DynamoRIO [4, 5] 1. INTRODUCTION runtime code modification system. DynamoRIO executes a pro- The greatest threat to our modern information infrastructure is gram through copies of its code stored in a cache. This code cache the remote exploitation of program vulnerabilities. The goal of is the key to efficient, secure execution, because it allows many se- most security attacks is to gain unauthorized access to a computer curity checks to be performed only once, when the code is copied system by taking control of a vulnerable privileged program. This to the cache. If the code cache is protected from malicious modi- is done by exploiting bugs that allow overwriting stored program fication, future executions of the trusted cached code proceed with addresses with pointers to malicious code. Today’s most prevalent no security overhead. A second key feature of DynamoRIO is the attacks target buffer overflow and format string vulnerabilities. creation of traces, hot streams of code that cross control flow tran- Nearly all attacks have one thing in common: they coerce the sitions. Security checks on transitions can be elided when execu- target program into performing actions that it was never intended tion follows the trace. These features result in a secure system that to perform. In short, they violate the execution model followed by imposes minimal or no performance overhead, operates on unmod- legitimate programs. The execution model encompasses the Appli- ified native binaries, and requires no special hardware or operating cation Binary Interface (ABI) and higher-level specifications from system support. Our static analyses require source code access but the program’s source programming language. The model also in- not recompilation. corporates components specific to the program, for example, which The contributions of this paper are as follows: values a particular function pointer may take. ¢ We demonstrate that enforcing a program’s execution model A program’s execution model is invariably narrower than that can thwart many security attacks; imposed by the underlying hardware. As such, there is typically ¢ We analyze features of the execution model that can be en- This research was supported in part by the Defense Advanced Re- forced with reasonable cost and those whose costs are unac- search Projects Agency under Grant F29601-01-2-0166. ceptable; ¢ We show how to incorporate static analyses to automatically them random write access to arbitrary addresses in the program ad- extract features of the program’s execution model such as its dress space. In most security attacks modifying data is simply the call graph; means to executing a sequence of instructions that will ultimately compromise the whole system. Attackers induce this by overwrit- ¢ We identify aspects of enforcement that can be performed ing a stored program address that will be used in an indirect control and further enhanced dynamically; transfer. ¢ We present two different schemes for verifying that the call- 2.2 Stored Program Addresses ing convention is followed; Security exploits can attack program addresses stored in many ¢ different places. Buffer overflow attacks target addresses adjacent We give experimental evidence that the execution model can to the vulnerable buffer. The classic return address attacks and local be enforced efficiently and effectively using a runtime code function pointer attacks exploit overflows of stack allocated buffers. modification system. Global data and heap buffer overflows also allow global function In Section 2 we classify the types of security exploits that we are pointer attacks and setjmp structure attacks. Data pointer buffer aiming to prevent. The execution model and how to enforce it is overflows, malloc overflow attacks, and %n format string attacks discussed in Section 3. Applying the enforcement policies using are able to modify any stored program address in the vulnerable program shepherding is described in Section 4, and our implemen- application — in addition to the aforementioned addresses, these tation is discussed in Section 5. We present experimental results attacks target entries in the atexit list, .dtors destructor rou- and the performance of our system in Section 6. We discuss related tines, and in the Global Offset Table (GOT) [14] of shared object work in Section 7 and conclude the paper in Section 8. entries. Program addresses are credibly manipulated by a number of en- tities. For example, dynamic loaders patch shared object functions; 2. SECURITY EXPLOITS dynamic linkers update relocation tables; and language runtime This section provides some background on the types of security systems modify dynamic dispatch tables. Generally, these program exploits we are targeting. We classify security exploits based on addresses are intermingled with and indistinguishable from data. three characteristics: the program vulnerability being exploited, the In such an environment, preventing a control transfer to malicious stored program address being overwritten, and the malicious code code by stopping illegitimate memory writes is next to impossible. that is then executed. It requires the cooperation of numerous trusted and untrusted en- tities that need to check many different conditions and understand 2.1 Program Vulnerabilities high-level semantics in a complex environment. The resulting pro- The two most-exploited classes of program bugs involve buffer tection is only as powerful as the weakest link. overflows and format strings. Buffer overflow vulnerabilities are present when a buffer with weak or no bounds checking is popu- 2.3 Malicious Code lated with user supplied data. A trivial example is unsafe use of Using the privileges of the application, an attacker can cause the C library functions strcpy or gets. This allows an attacker damage by executing newly injected malicious code or by mali- to corrupt adjacent structures containing program addresses, most ciously reusing already present code. Currently, the first approach often return addresses kept on the stack [9]. Buffer overflows af- is prevalently taken and attack code is implemented as new native fecting a regular data pointer can actually have a more disastrous code that is injected in the program address space as data [31]. effect by allowing a memory write to an arbitrary location on a sub- Modifying any stored program address to point to the introduced sequent use of that data pointer. One particular attack corrupts the code will trigger intrusion when that address is used for control fields of a double-linked free list kept in the headers of malloc transfer. In our previous work [26] we have presented a system allocation units [25].