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

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Secure Program Execution via Secure Program Execution via Dynamic Information Flow Dynamic Information Flow Tracking Tracking

• G. Edward
• G. Edward Suh

Suh, , Jae Jae W. Lee, David

• W. Lee, David

Zhang, Zhang, Srinivas Srinivas Devadas Devadas Massachusetts Institute of Technology Massachusetts Institute of Technology

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 2 2

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

• verheads
• verheads
• Other hardware solutions

Other hardware solutions partial protection partial protection

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 3 3

Our Goal Our Goal

• Architectural support to defeat

Architectural support to defeat a broad range a broad range of

• f

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 4 4

Attack Model: Attack Model: Example

Example -

• Stack Smashing

Stack Smashing

• Step 1. Inject

Step 1. Inject malicious data malicious data through legitimate channels through legitimate channels

• Long input

Long input for buffer overflows for buffer overflows

• Step 2. Bugs modify unintended

Step 2. Bugs modify unintended memory locations memory locations

• The data flows into

The data flows into buf buf[] [], ,

• verwrites a return address
• verwrites a return address
• Step 3. Take control over

Step 3. Take control over

• Jump to

Jump to injected target address injected target address ( (return address return address in the example) in the example)

• Execute

Execute injected code

int func(void) { char buf[256]; while (gets(buf)) {...} }

injected code

Other Other variables variables buf buf (256 Bytes) (256 Bytes) Return Return Address Address Stack Stack Attack Other Other variables variables Malicious Malicious Input data Input data from from gets() gets() Stack Stack Used for return

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 5 5

Observation: Observation: Common Requirements for

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 variable ( (valid_passwd valid_passwd = 1) = 1)

• 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 6 6

Our Protection Scheme Our Protection Scheme

I/O, other processes Program Vulnerability Unintended Uses Step 3. Detect attacks

• Check and restrict the

use of spurious values

Detect

Operating System Step 1. OS tags potentially malicious inputs as spurious Security Tags; 0 – authentic, 1 – spurious Step 2. Processors track the flow of the spurious values Dynamic Information Flow Tracking Processors checks + trap handler

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 7 7

Implementation Overview Implementation Overview

I/O Information flow tracker Processor Tag checker Operating System Execution Monitor I/O I/O interface Trap handler

• 1. Which I/O to

tag spurious

• 2. Which flows to

track

• 3. When to trap

Security Policy Traps

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Architectural Support Architectural Support

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 9 9

Security Tags Security Tags

• 1

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

• 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

• verhead on average (based on experiments)
• verhead on average (based on experiments)
• At the start

At the start-

• up, all instructions and initial data will be tagged

up, all instructions and initial data will be tagged “ “authentic authentic” ”

• During the execution, the execution monitor sets the tag for eac

During the execution, the execution monitor sets the tag for each I/O h I/O input according to the security policy input according to the security policy

GPR (32 or 64 bits) 0/1 Memory (1 Byte) 0/1

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 10 10

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 11 11

Security Tag Computation Examples Security Tag Computation Examples

T[MEM] = T[R3] OR T[R1] ST R1, Imm(R2) R1 1 Memory

Spurious

R3

+Imm Tag spurious

T[R2] = T[MEM] OR T[R1] LD R2, Imm(R1) R1 1 Memory

Authentic

R2 1

+Imm

R1 1 R2 R3 1 T[R3] = T[R1] OR T[R2]

• SUB R3, R1, R2

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 12 12

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 13 13

Hardware Support Summary Hardware Support Summary

• 1

1-

• bit tag for each GPR

bit tag for each GPR

• Small modification to ALU

Small modification to ALU

• Tag computation (logical OR)

Tag computation (logical OR)

• TLB contains tag types and

TLB contains tag types and tag pointers tag pointers

• Separate tag caches

Separate tag caches

• Allow parallel accesses to

Allow parallel accesses to data and tags data and tags

• Exploit multi

Exploit multi-

• granularity tags

granularity tags

• Tags will be often less than

Tags will be often less than 1/8 of data

Core D$-L1 L2 I$-L1 D-TLB I-TLB T$-L2 T$-L1 Regs Tag Types, Pointers Security Tags

1/8 of data

Memory Bus

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Security Policy Security Policy

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 15 15

Security Policy Security Policy

• Defines

Defines “ “spurious spurious” ” values values

• I/O channels to be tagged

I/O channels to be tagged

• Dependencies to be tracked

Dependencies to be tracked

• Defines illegal uses of spurious values

Defines illegal uses of spurious values

• Trap conditions

Trap conditions

• Software checks in the handler

Software checks in the handler

• Can be general for many programs, or customized

Can be general for many programs, or customized for each program for each program

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 16 16

Take 1: Maximum Security Take 1: Maximum Security

• Untrusted

Untrusted I/O I/O

• ALL

ALL

• Tracked Dependencies

Tracked Dependencies

• ALL

ALL

• Trap Condition

Trap Condition

• Instruction

Instruction

• Jump target address

Jump target address

• Store address

Store address

• Trap Handler

Trap Handler

• Terminate the process

False alarms from spurious pointers Need to balance security and false positives Terminate the process

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 17 17

Where Are Spurious Pointers From? Where Are Spurious Pointers From?

• I/O inputs are often used as

I/O inputs are often used as offsets for pointer

• ffsets for pointer

tables tables after a bound check after a bound check

PTR_n PTR_n … … PTR_3 PTR_3 PTR_2 PTR_2 PTR_1 PTR_1

1 1 LDA Dep. Comp Dependency Base PTR 0

+

Bound Check 0 ≤ offset < n

*4

Offset 1

Jump Table Spurious Jump Pointer From I/O

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 18 18

Take 2: Allow Legitimate Uses Take 2: Allow Legitimate Uses

• Unstrusted

Unstrusted I/O I/O

• ALL

ALL

• Tracked Dependencies

Tracked Dependencies

• ALL but pointer offsets

ALL but pointer offsets

• Trap Condition

Trap Condition

• Instruction

Instruction

• Jump target address

Jump target address

• Store address

Store address

• Trap Handler

Trap Handler

• Terminate the process

Terminate the process For pointer additions such as [4*r1+r2] in x86, s4addq r1, r2, r3 (r3 r2+4*r1) in Alpha The new tag = T[r2] assuming the bound check is done.

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 19 19

Example Example – – Stack Smashing Stack Smashing

Registers LD R1, Imm(SP)

• Load a return address

Data Inst Inst Inst Data Ret Adr I/O

1

I/O

1

I/O

1

I/O

1

I/O

1

JR R1 - Return Trap – spurious jump target address Tag Check Processor Memory

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004

Evaluation Evaluation

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 21 21

Simulation Frameworks Simulation Frameworks

• Bochs

Bochs (Intel x86) (Intel x86)

• Keyboard and network I/O are tagged spurious

Keyboard and network I/O are tagged spurious

• Used to evaluate the effectiveness of our scheme

Used to evaluate the effectiveness of our scheme

• x86 applications on

x86 applications on Debian Debian Linux (3.0r0) Linux (3.0r0)

• SimpleScalar

SimpleScalar (Alpha) (Alpha)

• All I/O are tagged spurious

All I/O are tagged spurious

• sim

sim-

• fast: functional evaluations (false alarms, space

fast: functional evaluations (false alarms, space

• verheads for tags)
• verheads for tags)
• sim

sim-

• outorder
• utorder: performance evaluations

: performance evaluations

• SPEC CPU2000 benchmarks

SPEC CPU2000 benchmarks

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 22 22

Detecting Security Attacks Detecting Security Attacks

• Buffer overflow

Buffer overflow testbed testbed (by (by Wilander Wilander, 2003) , 2003)

• Covers all 20 combinations possible in practice

Covers all 20 combinations possible in practice

• Overwrite technique: direct, pointer redirection

Overwrite technique: direct, pointer redirection

• Buffer location: stack, heap/BSS/data

Buffer location: stack, heap/BSS/data

• Attack targets: return address, base pointer, function pointer,

Attack targets: return address, base pointer, function pointer, and and longjmp longjmp buffers buffers

• The best protection scheme in 2003 detected only 50%

The best protection scheme in 2003 detected only 50%

• Format string attacks (from TESO security group)

Format string attacks (from TESO security group)

• Overflow a buffer or use %n conversion specification

Overflow a buffer or use %n conversion specification

• Detects and stops

Detects and stops ALL ALL security attacks tested security attacks tested

• So far, all known attacks directly inject pointers or

So far, all known attacks directly inject pointers or instructions instructions lenient tag propagation does not matter lenient tag propagation does not matter

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 23 23

No False Alarms No False Alarms

• Common x86 applications

Common x86 applications

• Debian

Debian Linux 3.0 (keyboard, network marked spurious) Linux 3.0 (keyboard, network marked spurious)

• System commands:

System commands: ls ls, cp, vi, ping, etc. , cp, vi, ping, etc.

• penSSH
• penSSH server/client

server/client

• Dynamically generated code

Dynamically generated code

• A simple http server (TinyHttpd2)

A simple http server (TinyHttpd2) – – marked spurious marked spurious

• SUN

SUN’ ’s s JAVA SDK 1.3 JAVA SDK 1.3 HotSpot HotSpot VM with JIT VM with JIT

• SPEC2000 CPU benchmarks

SPEC2000 CPU benchmarks

• Input files are marked spurious

Input files are marked spurious

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 24 24

Performance Degradation Performance Degradation

0.7 0.75 0.8 0.85 0.9 0.95 1 1.05 ammp applu apsi art crafty eon equake gap gcc gzip mcf mesa mgrid parser sixtrack swim twolf vortex vpr wupwise ave

Normalized IPC

512KB 1MB 2MB 4MB

• Various L2 sizes with 1/8 tag caches

Various L2 sizes with 1/8 tag caches – – 1.1% 1.1% degradation on average degradation on average

• Pessimistic

Pessimistic overhead: baseline case gets 12.5% larger caches if it helps

• verhead: baseline case gets 12.5% larger caches if it helps

0.82 0.78 0.95 With the same cache sizes, the performance degradation is less than 0.1% in the worst case.

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 25 25

Conclusion Conclusion

• Dynamic information flow tracking provides a powerful tool

Dynamic information flow tracking provides a powerful tool for system security for system security

• Tells whether a value came from

Tells whether a value came from untrusted untrusted I/O or not I/O or not

• Can restrict the use of potentially malicious input values

Can restrict the use of potentially malicious input values

• Our protection scheme is effective against large class of

Our protection scheme is effective against large class of attacks attacks

• Stops both buffer overflow and format string attacks

Stops both buffer overflow and format string attacks

• No false alarms for real

No false alarms for real-

• world applications

world applications

• The overhead of tagging can be small

The overhead of tagging can be small

• 1.4% space, 2.1% bandwidth, 1.1% performance overhead

1.4% space, 2.1% bandwidth, 1.1% performance overhead

• Many extensions are possible

Many extensions are possible

• Automatically identify bound checks and strictly follow dependen

Automatically identify bound checks and strictly follow dependencies cies

• Combine with static analysis

Combine with static analysis

• Other applications such as protecting private information or

Other applications such as protecting private information or debugging debugging

ASPLOS XI, October 11, 2004 ASPLOS XI, October 11, 2004 26 26

Questions? Questions?

• Our website

Our website

http:// http://www.csg.csail.mit.edu www.csg.csail.mit.edu

• Contact Info

Contact Info

Edward Suh ( Edward Suh (suh@mit.edu suh@mit.edu) )