Combining Control-Flow Integrity and Static Analysis for Efficient … · 2012-02-21 · Combining Control-Flow Integrity and Static Analysis for Efficient and Validated Data Sandboxing

Combining Control-Flow Integrity and Static Analysis for Efficient and

Validated Data Sandboxing

Bin Zeng, Gang Tan Greg Morrisett

Lehigh University Harvard University

@ CCS 2011 Chicago

Software Attacks

• Software attacks are common – Attacks in 2011

• CIA websites were taken down

• Sony user data were stolen

– Software attacks are increasing every year …

• Inducing illegal control-flow transfers is a common step – Buffer overflow attacks

– Jump-to-libc attacks

– Return oriented programming …

2

Control Flow Integrity (CFI)

• CFI definition – Enforces that execution paths must follow a

predetermined control flow graph

• CFI implementation – Static verification + dynamic checks

• Effectiveness – Prevents buffer overflow and other arc injection

attacks

– Protects against any attacks violating control flow integrity

3


4


5


• CFI can help with other security mechanisms

– Many other security mechanisms require a certain level of control flow integrity. e.g. IRM

– CFI enforces a control flow graph even under attacks

– Accurate static analysis also entails a control flow graph

6


• CFI can facilitate Inlined Reference Monitor (IRM)

– IRM inserts checks into code to enforce safety policies e.g. Software-based Fault Isolation (SFI)

– IRM requires that inserted checks cannot be bypassed by adversaries

– Static analysis can optimize away checks inserted by IRM

7

CFI Enables Static Analysis

8

According to the definition of loops, with the dashed lines there is no loop in the flowchart because a loop cannot be entered from anywhere other than the header block.

CFI-enabled static analysis

• Optimizations

– Remove redundant checks for IRM

– Hoist checks outside a loop

• Verification

– IRM implementation is error-prone

– Optimizations are hard to get right

– CFI can help with verification

9

Software-based Fault Isolation (SFI)

• SFI

– It’s a special IRM

– Ensures that memory accesses are within a specified region

• Implementation

– Hardware segmentation, in x86 but not x86-64

– Insert checks before memory accesses

10

Software-based Fault Isolation (SFI)

• Subtle requirement

– SFI needs some form of control-flow integrity

– Inserted checks cannot be bypassed by adversaries

• Current SFI implementations usually sandbox only writes but not reads

– High overhead

– Writes affect the integrity; reads affect only confidentiality

– Our work sandboxes both reads and writes

11

Note: 32-bit NaCl uses hardware segmentation to sandbox both reads and writes.

Outline • Contributions

• Threat Model and Security Policy

• Data sandboxing optimizations

• CFI Optimizations

• Experiments

12

Contributions

• CFI + data sandboxing – CFI and data sandboxing are combined – Both reads and writes are sandboxed

• Data sandboxing optimizations – A series of optimizations for efficient data sandboxing

were proposed, implemented and evaluated

• Data sandboxing verification – Range analysis is proposed and implemented to verify

data sandboxing

• CFI optimizations – Two CFI optimizations are implemented and evaluated

13

Threat Model

• Data region is readable and writable but not executable – Data region is assumed to be under the control of

adversaries and can be changed between any two instructions

• Code region is executable and readable but not writable

• Registers can not be changed directly by adversaries

14

Security Policy

• A memory access is allowed if the address is within the range [DB-GSize, DL+GSize]

– DB represents data region begin

– DL means data region limit

– GSize is the size of guard region

• Guard regions are inserted right before and after data region

– To optimize sandboxing stack accesses, e.g. [ebp+8]

– Memory visits serve as checks

15

Security Policy

16

Outline • Contributions




• Experiments

17

Data Sandboxing Optimizations

• Scavenge registers – Sandboxing needs scratch registers to hold results

– Our work is done right before code emission, after register allocation

– Existing SFI reserves a register for this purpose

– Liveness analysis is performed to find dead registers

18

Original code Sandboxed code(eax is dead) Sandboxed code(no live reg)ebx := [ecx+4] eax := ecx + 4 push eax

eax := eax & $Dmask eax := ecx + 4ebx := [eax] eax := eax & $Dmask

ebx := [eax]pop eax

Liveness analysis example


• In-place sandboxing

– Common memory addressing pattern: base + displacement

– Only the base register needs to be sandboxed

– No need for scratch register

19

Original code Sandboxed code(in-place) Sandboxed code(eax is dead)ebx := [ecx+4] ecx := ecx & $Dmask eax := ecx + 4

ebx := [ecx + 4] eax := eax & $Dmask ebx := [eax]

In-place sandboxing example

Range Analysis

• Definition – Range analysis determines the ranges of a variable, register

or expression at a program point

• Steps: – Initialization

• At the entry to a function, the ranges of general registers are initialized to be [-∞, +∞]

– Update • Once a register is sandboxed, its range is updated to be [DB, DL]

• Other instructions also update the ranges…

– Widening • When two ranges are combined, the new range is the union of them

20

Range Analysis

• Definition – Range analysis determines the ranges of a variable, register

or expression at a program point

• Steps: – Initialization

• At the entry to a function, the ranges of general registers are initialized to be [-∞, +∞]

– Update • Once a register is sandboxed, its range is updated to be [DB, DL]

• Other instructions also update the ranges…

– Widening • When two ranges are combined, the new range is the union of them

21

ebx: [-∞, +∞]ecx: [-∞, +∞]edx: [-∞, +∞]

ecx := ecx & $Dmaskebx: [-∞, +∞]ecx: [DB, DL]edx: [-∞, +∞]

edx := ecx + 4ebx: [-∞, +∞]ecx: [DB, DL]edx: [DB+4, DL+4]

ebx := [ecx + 8]ebx: [-∞, +∞]ecx: [DB, DL-8]edx: [DB+4, DL+4]

Range analysis example

Range Analysis

• Why range analysis?

– Optimizations

• 1. redundant check elimination

• 2. loop check hoisting

• 3. other optimizations?

– Verification

• Verify the range of each memory address

• If the ranges of a memory address are not safe, report an error

22


• Redundant check elimination

• When the ranges of a register are statically determined to be safe according to the policy, the inserted check can be eliminated

23

The second check can be eliminated here because the range of [ecx+8] is still safe.


• Loop check hoisting

• A loop check can be hoisted to its pre-header if: – 1. there is a small constant change to the index register

– 2. for each iteration, there is a memory visit with the index register

24


• Loop check hoisting example

25

Loop check hoisting eax holds the initial address of the array; ebx holds the length and esi holds the pointer value p; edx holds sum

Validating Data Sandboxing

• Low-level transformations are error-prone – Range analysis can be used to validate the optimizations

performed – A separate verifier was implemented to verify data

sandboxing

• The process involves two steps: – 1. perform range analysis to compute the ranges of

registers – 2. traverse the program and check the range of each

memory address If the address range is within [DB-Gsize, DL+Gsize], then ok else report an error

26

Outline • Contribution




• Experiments

27

CFI Optimizations

• CFI serves as the foundation

– A fast CFI implementation can reduce the overhead of the whole system

• Two CFI optimizations were implemented

– 1. jumping over prefetch instruction

– 2. jump table check optimization

28

Outline • Contribution




• Experiments

29

Experiment Setup

• Implemented in LLVM 2.8

– All the passes are inserted right before code emission

– Essentially assembly–level rewriting

• Evaluated on SPECint2000

– Compiled with O3 enabled

– Run on a CentOS 5.3 box with Intel Xeon CPU with 12 GB of RAM

30

31

Runtime overheads of CFI on SPECint2000 With both optimizations enabled, CFI causes less than 8% slowdown on average.

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

gzip vpr gcc mcf crafty gap vortex bzip2 twolf avg

CFI

CFI.jt.no-skip

CFI.no-jt.skip

CFI.no-jt.no-skip

CFI Optimization Runtime Performance Evaluation

32

Runtime overhead of data sandboxing with CFI on SPECint2000 Sandboxing both reads and writes, the overhead is less than 28% on average including CFI. Sandboxing only writes incurs 10.40% slowdown.

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

gzip vpr gcc mcf crafty gap vortex bzip2 twolf avg

DS-W.CFI

DS-RW.live

DS-RW.live.in-place

DS-RW.CFI

Data Sandboxing Optimization Runtime Performance Evaluation

Related Work • Control-flow Integrity

– M. Abadi, M. Budiu, et al. Control-flow integrity – V. Kiriansky, D. Bruening, et al. Secure execution via program

shepherding

• Software-based fault isolation – S. McCamant and G. Morrisett. Evaluating SFI for a CISC architecture – Ú. Erlingsson and F. Schneider. SASI enforcement of of security policies:

A retrospective – D. Sehr, R. Muth, C. Biffle, et al. Adapting software fault isolation to

contemporary CPU architecture – R. Wahbe, S. Lucco, et al. Efficient software-based fault isolation.

• XFI – Ú. Erlingsson , M. Abadi et al. XFI: Software guards for system address

spaces

• AND MANY MORE …

33

Future Work

• Apply CFI to other security mechanisms?

– Software Memory Access Control (SMAC)?

– Other IRMs?

• CFI + data sandboxing for other architectures?

– ARM?

– X86-64?

34

Conclusion

• CFI – Can serve as the foundation for data sandboxing

– Can enable static analysis

• Optimizations – CFI and data sandboxing optimizations can reduce

the overhead significantly

• Range analysis – Can be used to optimize and validate data

sandboxing

35

Thank you!

Question?

36

Documents

Combining Control-Flow Integrity and Static Analysis for Efficient … · 2012-02-21 · Combining Control-Flow Integrity and Static Analysis for Efficient and Validated Data Sandboxing