Secure Program Execution via Secure Program Execution via Dynamic - PowerPoint PPT Presentation

Secure Program Execution via Secure Program Execution via Dynamic Information Flow Dynamic Information Flow Tracking Tracking G. Edward Suh Suh, , Jae Jae W. Lee, David W. Lee, David G. Edward Zhang, Srinivas Srinivas Devadas Devadas Zhang, Massachusetts Institute of Technology Massachusetts Institute of Technology ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Program Vulnerabilities Program Vulnerabilities � Program bugs cause serious security risks Program bugs cause serious security risks � � Attackers can gain total control of victim processes Attackers can gain total control of victim processes � � Very difficult, if not impossible, to eliminate the bugs Very difficult, if not impossible, to eliminate the bugs � � Existing solutions have limitations Existing solutions have limitations � � Safe languages Safe languages � � re re- -programming, performance hit programming, performance hit � � Fix programs: new libraries, compilers Fix programs: new libraries, compilers � � partial protection, re partial protection, re- -compilation compilation � � Run Run- -time monitoring: program shepherding time monitoring: program shepherding � � overheads overheads � � Other hardware solutions Other hardware solutions � � partial protection partial protection � ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 2 2

Our Goal Our Goal � Architectural support to defeat Architectural support to defeat a broad range a broad range of of � security exploits (possibly all) security exploits (possibly all) � Focus on attacks to Focus on attacks to gain total control gain total control (shell) (shell) � � Should work for legacy code and shared libraries Should work for legacy code and shared libraries � � transparent transparent to applications, run to applications, run- -time checks time checks � � Should have Should have low overhead low overhead (performance and memory (performance and memory � space) space) � Need to find common requirements for successful Need to find common requirements for successful � security exploits security exploits ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 3 3

Attack Model: Example Attack Model: Example - - Stack Smashing Stack Smashing Step 1. Inject malicious data malicious data Step 1. Inject int func(void) � � through legitimate channels through legitimate channels { char buf[256]; � Long input Long input for buffer overflows for buffer overflows � while (gets(buf)) {...} } Step 2. Bugs modify unintended Step 2. Bugs modify unintended � � memory locations memory locations Stack Stack Stack Stack � The data flows into The data flows into buf , [] , buf[] � overwrites a return address overwrites a return address Used for return Return Return Malicious Address Malicious Address Step 3. Take control over Step 3. Take control over � � Input data Input data Attack � Jump to Jump to injected target address injected target address � from from buf buf (return address ( return address in the example) in the example) gets() gets() (256 Bytes) (256 Bytes) � Execute Execute injected code injected code � Other Other Other Other variables variables variables variables ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 4 4

Observation: Common Requirements for Observation: Common Requirements for Successful Attacks Successful Attacks � All attacks come from All attacks come from identifiable I/O identifiable I/O channels channels � � Both OS and applications explicitly manage I/O Both OS and applications explicitly manage I/O � � Malicious inputs should be used for Malicious inputs should be used for a few a few security security � sensitive operations to take control of a process sensitive operations to take control of a process � Instructions Instructions: executes malicious code from I/O : executes malicious code from I/O � � Code pointers Code pointers: : arbitrarily arbitrarily redirect the control flow redirect the control flow � � Data pointers for stores Data pointers for stores: overwrite a : overwrite a critical program critical program � variable ( (valid_passwd valid_passwd = 1) = 1) variable � In most applications, instructions and pointers In most applications, instructions and pointers � usually do not come directly from I/O usually do not come directly from I/O ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 5 5

Our Protection Scheme Our Protection Scheme I/O, other processes Step 1. OS tags Security Tags; potentially malicious 0 – authentic , inputs as spurious 1 – spurious Operating System Step 2. Processors track Dynamic Information the flow of the spurious Flow Tracking values Vulnerability Program Step 3. Detect attacks Detect Processors checks - Check and restrict the + trap handler Unintended Uses use of spurious values ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 6 6

Implementation Overview Implementation Overview Security Policy Operating System I/O 1. Which I/O to Execution Monitor tag spurious I/O interface Trap handler 2. Which flows to I/O Traps track Information Tag flow checker tracker 3. When to trap Processor ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 7 7

Architectural Support Architectural Support ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Security Tags Security Tags 1- -bit information to indicate whether a piece of data can be trust bit information to indicate whether a piece of data can be trusted ed 1 � � � 0 0 – – authentic authentic � � 1 1 – – spurious spurious � Granularity Granularity � � � One for One for each general purpose register each general purpose register (GPR) (GPR) � � One for One for each byte each byte in memory in memory – – 12.5% overhead is a na 12.5% overhead is a naï ïve management ve management � � Multi Multi- -granularity tags granularity tags - - Only Only 1.4% 1.4% space overhead, space overhead, 2.1% 2.1% bandwidth bandwidth � overhead on average (based on experiments) overhead on average (based on experiments) GPR (32 or 64 bits) 0/1 Memory (1 Byte) 0/1 At the start- -up, all instructions and initial data will be tagged up, all instructions and initial data will be tagged “ “authentic authentic” ” At the start � � During the execution, the execution monitor sets the tag for each I/O h I/O During the execution, the execution monitor sets the tag for eac � � input according to the security policy input according to the security policy ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 9 9

Dynamic Information Flow Tracking Dynamic Information Flow Tracking � Compute a new security tag for each operation Compute a new security tag for each operation � � If If spurious spurious data controls a result, the result is also data controls a result, the result is also spurious spurious � � Various types of dependencies exist Various types of dependencies exist � � Direct copy Direct copy: load/store spurious data : load/store spurious data � � Computation Computation: compute from spurious data : compute from spurious data � � Pointer additions Pointer additions � � Other computations Other computations � � Load address Load address: load from spurious address : load from spurious address � � Store address Store address: store into spurious address : store into spurious address � � Propagation Control Register (PCR) determines which Propagation Control Register (PCR) determines which � dependencies to track dependencies to track � Execution monitor sets the register based on the security policy Execution monitor sets the register based on the security policy � ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 10 10

Security Tag Computation Examples Security Tag Computation Examples LD R2, Imm(R1) ST R1, Imm(R2) SUB R3, R1, R2 R1 1 R2 1 R1 1 R3 0 R1 1 R2 0 +Imm +Imm Tag spurious Authentic Spurious - Memory Memory R3 1 T[R3] = T[R2] = T[MEM] = T[R1] OR T[R2] T[MEM] OR T[R1] T[R3] OR T[R1] ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 11 11

Tag Checker Tag Checker � Processor traps when spurious values are used for Processor traps when spurious values are used for � sensitive operations sensitive operations � Sensitive values to be checked Sensitive values to be checked � � Instructions Instructions � � Load addresses Load addresses � � Store addresses Store addresses � � Jump target addresses Jump target addresses � � Trap Control Register (TCR) determines which Trap Control Register (TCR) determines which � uses of spurious values generate a trap uses of spurious values generate a trap ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 12 12