Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin - - PowerPoint PPT Presentation

▶
isolation
SMART_READER_LITE
LIVE PREVIEW

Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin - - PowerPoint PPT Presentation

Mar 27, 2024 328 likes •658 views

Locking Down Insecure Indirection with Hardware-Based Control-Data Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin MICRO, Waikiki, Hawaii, US December 7 th 2015 Goal of this work MAKE SOFTWARE MORE SECURE Reducing the

slide-1
SLIDE 1

Locking Down Insecure Indirection with Hardware-Based Control-Data Isolation

William Arthur, Sahil Madeka, Reetuparna Das, Todd Austin

MICRO, Waikiki, Hawaii, US December 7th 2015

slide-2
SLIDE 2

Goal of this work

MAKE SOFTWARE MORE SECURE

Reducing the software attack surface by subtracting the root cause leading to many software exploits today

2

Accomplished by locking down insecure indirection

slide-3
SLIDE 3

Locking Down Insecure Indirection (1)

Every control transfer in executing application comes from the programmer:

Every PC address encoded in instructions, OR Is derived from secure hardware structures

3

Executing application always adheres to the programmer-defined control-flow graph Stopping control-flow attacks which derail the CFG

slide-4
SLIDE 4

Locking Down Insecure Indirection (2)

Achieved by hardware-software co-design

4

Software: Eliminate all indirect control-flow instructions – via Control-Data Isolation (CDI) [1] Hardware: Memoization of secure control transitions in secure hardware – via Indirect Edge Cache

[1] Getting in Control of Your Control Flow with Control-Data Isolation, Arthur et al., CGO 2015

slide-5
SLIDE 5

Outline

Software (in)security Hardware-Based Control-Data Isolation Measure performance and security Conclusions

5

Software (in)security – Control-Flow Attack Hardware-Based Control-Data Isolation Measure performance and security Conclusions

slide-6
SLIDE 6

Control-Flow Attack

6

Control-Flow Attacks

violate, at runtime, the CFG of an application by corrupting the PC with user-injected data Return-to-libc Code Gadgets Heap Spray Buffer Overflow

local variables, return value buffer

attack code

return ?????

Stack Smash

slide-7
SLIDE 7

Outline

7

Software (in)security Hardware-Based Control-Data Isolation Measure performance and security Conclusions

slide-8
SLIDE 8

Control-Data Isolation

int bar() { // function code return; } Vulnerable Code

9 int bar() { // function code return; } Vulnerable Code

int bar() { // function code if([%esp]==_ret1) jump _ret1; else if([%esp]==_ret2) jump _ret1; else call _abort; } “Sled” of conditional branches and direct jumps White-list of valid CFG edges

ret

slide-9
SLIDE 9

Hardware-Based CDI

Software-only CDI (CGO ’15) retains higher than desired runtime overheads for some applications – 31% for gcc

11

Key insight: Caching previously executed sled edges obviates subsequent re- executions of the sled Addition of hardware edge cache

slide-10
SLIDE 10

Hardware-Based CDI Algorithm

12

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (*jmp, *call, ret) Taken branch from sled

slide-11
SLIDE 11

Hardware-Based CDI Algorithm

13

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-12
SLIDE 12

Hardware-Based CDI Algorithm

14

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (*jmp, *call, ret) Taken branch from sled

slide-13
SLIDE 13

Hardware-Based CDI Algorithm

15

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-14
SLIDE 14

Hardware-Based CDI Algorithm

16

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-15
SLIDE 15

Hardware-Based CDI Algorithm

17

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-16
SLIDE 16

Hardware-Based CDI Algorithm

18

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Place

<source,target>

in the Edge Cache

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-17
SLIDE 17

Hardware-Based CDI Algorithm

19

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-18
SLIDE 18

Hardware-Based CDI Algorithm

20

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (*jmp, *call, ret) Taken branch from sled

slide-19
SLIDE 19

Hardware-Based CDI Algorithm

21

Check Edge Cache for <source,target> pair Execute Instructions Fall-through to sled, retain <source> Cache <source,target>

  • f taken branch

Hit? Miss? Indirect Instruction (jmp, call, ret) Taken branch from sled

slide-20
SLIDE 20

Edge Cache(1)

New hardware structure – edge cache

Memoization of most recent indirect edges

22

slide-21
SLIDE 21

Edge Cache(2)

23

Edge Cache Commit Fetch

<src,target>

=

Squash, execute sled No Yes Retire

slide-22
SLIDE 22

Edge Cache(2)

24

PC GHR BTB Target Index Edge Cache Commit Fetch

<src,target>

=

Squash, execute sled No Yes Retire

slide-23
SLIDE 23

Challenges

26

Target Address tag, full address Source Address U V Edge Cache

128 + 2 bits per entry! 1k entries = 16 kB

slide-24
SLIDE 24

Region Table

27 Target

  • Addr. Offset

Source

  • Addr. Offset

G G Region Pointer(S) Region Pointer(T) U V Edge Cache

  • ffset, 18 bits

index, 5 bits

slide-25
SLIDE 25

Region Table

28

Region Table

Region Address U V G Target

  • Addr. Offset

Source

  • Addr. Offset

G G Region Pointer(S) Region Pointer(T) U V Edge Cache

slide-26
SLIDE 26

Region Table

29

Region Table

Region Address U V G Target

  • Addr. Offset

Region Offset Source

  • Addr. Offset

G G Region Pointer(S) Region Pointer(T) U V Edge Cache

50 bits per entry! 1k entries 6.75 kB total

full address

slide-27
SLIDE 27

Outline

30

Software (in)security Hardware-Based Control-Data Isolation Measure performance and security Conclusions

slide-28
SLIDE 28

Experimental Setup

gem5 architectural simulator

Detailed O3 cpu model, configured similar to Intel Haswell processor, x86-64

SPECINT 2000 & 2006

1,024-entry edge cache

4-way set associative

32-entry region table

31

slide-29
SLIDE 29

32

0.995 0.84

0.2 0.4 0.6 0.8 1 1.2 Speedup Over Native Execution Benchmark Applications

Hardware-Based CDI Software-Based CDI Branch prediction – 6% speedup 400.perlbench vs BTB

slide-30
SLIDE 30

Security

Average Indirect target Reduction – AIR [2] Measure of the reduction in the software attack surface

33 [2] Control Flow Integrity for COTS Binaries, Zhang and Sekar, USENIX Security 2013

99.999%+ reduction in indirect target set Average of tens of targets per indirect Previous works: average of tens of thousands of targets per indirect instruction

slide-31
SLIDE 31

Conclusions

Locking down insecure indirection can eliminate contemporary control-flow attacks Hardware-based control-data isolation efficiently realizes this capability

Minimal runtime overhead – 0.5%

34

slide-32
SLIDE 32

Thank You

Questions?

35