1 of 35

CS 773 Paper Presentation

​

Record-Replay Architecture as a General Security Framework

Sahil Jain

ArchMages

180050089@iitb.ac.in

1

2 of 35

2

Inflexible

Imprecise

Intrusive

Hardware security

3 of 35

Security Requirements

3

Precision: False positives/negatives are not acceptable

Intrusive: Less intrusive the hardware, less the cost

Flexibility: Attacks evolve, so must defense

4 of 35

Can we get security that is precise, cheap and flexible?

4

Yes! RnR-Safe

5 of 35

Outline

5

​

A general

framework

RnR-Safe

    • Stack sm-ashing
    • ROP

Example threat

​

Limitations

Prior work

    • Details
    • Results

RnR-Safe & ROP

6 of 35

RnR-Safe

6

7 of 35

Record and (Deterministic) Replay - RnR

  • Attack detection via reliable replay of program execution�
  • Recording
    • Deterministic events –🆗 
    • Non-deterministic events – Saved in a log�
  • Replay
    • Deterministic events – Reproduced via re-execution of program
    • Non-deterministic events – Reproduced from the log

7

8 of 35

RnR-Safe

  • Framework to complement hardware security features
  • Checks offloaded from hardware to the framework

​

8

RnR-Safe Organization

http://iacoma.cs.uiuc.edu/iacoma-papers/hpca18.pdf

9 of 35

Applications of RnR-Safe

9

Attack

Alarm Trigger

Possible First Detection Technique

Role of Replay

Return Oriented Programming (ROP)

RAS misprediction

Manage a 

Multithreaded RAS, use a whitelist

Execute a kernel compatible shadow stack algorithm

Jump Oriented Programming (JOP)

Stray indirect branch or call

Table of begin and 

end addresses of the most common 

functions

Verify if the target is one of the less common functions

Denial of Service (DOS)

Kernel scheduler inactivity

Counter of number of context switches

Identify reason for low switching frequency

10 of 35

Example Threat : (Kernel) ROP

10

11 of 35

Stack Smashing

11

void func(char* input){

    char array[32];

    // overflow

    strcpy(array, input);

    return;

}

input = "attack_code; address_to_attack"

array

ret

attack_code

ret

Injecting malware by attacking stack

12 of 35

W xor X

12

void func(char* input){

    char array[32];

    // overflow

    strcpy(array, input);

    return;

}

input = "attack_code; address_to_attack"

array

ret

attack_code

ret

Not executable

  • Memory pages are either executable or writable
  • Malware injected can no longer be executed

13 of 35

Return-Oriented Programming

  • Stack – not executable
  • Code cannot be on the stack
  • What now?
    • Reuse code from the program text

13

adr 1: instr 1

           ret

….

adr 2: instr 2

           ret

….

adr 3: instr 3

           ret

       Program

​

​

input = "data1; adr2; data2; adr3; data3"

data1

adr2

data2

adr3

data3

Attacker wants to execute:

instr1 data1

instr2 data2

instr3 data3

Assume PC is at adr1

Voila! Attacked w/o executing stack!

Gadget

14 of 35

Prior Work

14

15 of 35

Prior Work & Limitations 

15

SmashGuard & SRAS

    • Intrusive hardware changes
    • Privileged instructions, exploitable

Instrumentation-based CFI enforcing solutions

    • Binary instrumentation adds overheads of over 100%

Randomizing code location (ASLR)

    • Bypassed with address disclosure vulnerabilities
    • Blind ROP

16 of 35

RnR-Safe against ROP

16

17 of 35

Return Address Stack(RAS)

  • Hardware structure to predict return targets

17

RAS

Program

call func

PC

call func2

func:

ret

func2:

ret

PC

PC

PC

PC

PC

ret

Stack

ret

No Mispredictions!

18 of 35

ROP in presence of RAS

18

RAS

Program

call func

PC

func:

vuln

ret

pop rax

ret

gadget1:

PC

PC

PC

Stack

gadget1

gadget2

gadget2

Misprediction!

19 of 35

RAS & ROP detection

  • RAS misprediction as a detector for ROP
  • ROP attack = Atleast one misprediction
    • Zero false negatives!
  • Non-ROP mispredictions?
    • Possible false positives!
  • Four kinds of mispredictions in kernel
    • Multi-Threading
    • Non-procedural Returns
    • Underflow
    • Imperfect Nesting

19

20 of 35

Reducing False Positives

20

21 of 35

Multi-threaded Environment

  • De-scheduled thread leaves behind RAS entries = False Alarm!�

Solution :

    • Per-thread RAS, stored in Hypervisor(inaccessible by kernel)
    • RAS updated on context-switches

21

22 of 35

Multi-threaded Environment

  • Context Switch = VM Exit & VM Enter
  • Hardware saves and restores RAS
  • Hypervisor determines scheduled thread by introspecting OS
    • Need to set BackRASptr correctly

22

23 of 35

Non-procedural Returns

  • push + ret instructions without procedure calls
  • Only observed at one place in Linux kernel
  • Only three possible return destinations�

Solution :

    • White-list all such (RetAddr, TargetAddr)
    • Only three such pairs
    • RAS not popped for white-listed pair(s)

​

23

push addr

ret

Code

Stack

addr

PC

PC

PC =

addr

24 of 35

Underflows

  • RAS = Hardware data-structure, Limited in size
  • Older return addresses evicted = Mispredictions!
  • Difficult to tackle in hardware

​

Solution :

    • Simulate unbounded RAS in software
    • Eviction log on return address eviction
    • Alarm record on misprediction

24

25 of 35

Imperfect Nesting

  • call without ret = Orphaned RAS entries
  • Exception handling – setjmp/ longjmp calls
  • Rare but requires extremely complicated hardware

​

Solution :

    • Easily detectable in software
    • Possible to fix simulated RAS
    • Alarm record

​

​

​

25

26 of 35

Checkpointing Replayer

  • Time since last checkpoint > Threshold:�VM exit occurs, and Checkpoint taken�
  • 3 Components:
      • All the VM State
      • BackRAS
      • Pointer to Input Log Buffer

​

  • Keep copy of only the modified pages�Else keep a pointer to last modified copy

​

​

​

​

26

27 of 35

Alarm Replayer

  • Launched when checkpointing replayer finds an alarm
    • Starts from the last checkpointing preceeding the alarm
    • Loads BackRAS and the saved processor state
    • Executes the original workload natively, in a deterministic manner�
  • Traps at every call and return instruction, 
    • Induces VM exit
    • Transfer control to the Hypervisor 
    • Unbounded RAS is modeled in software�
  • Checks whether the RAS mismatch can only be explained as an ROP attack

​

​

​

​

27

28 of 35

Experimental Evaluation

28

http://iacoma.cs.uiuc.edu/iacoma-papers/hpca18.pdf

29 of 35

Recording Setups 

  • Recording takes on average 27% longer than No-recording 
  • Saving and restoring the RAS induces only 4% overhead 
  • rdtsc dominates recording overhead

​

29

30 of 35

ROP False Alarms 

  • RnR-Safe eliminates most of the false alarms in the kernel
  • Whitelist and BackRAS - very effective at suppressing false alarms
  • Apache passes a few false alarms, corresponding to RAS underflow

30

31 of 35

Checkpointing Replay  

31

  • Checkpointing runs at a speed comparable to recording
  • Replay speed changes with change in checkpoint interval
  • Frequency of checkpointing matters
  • Asynchronous interrupt injection during replay is time consuming 

32 of 35

Alarm Replay for ROP Attacks

  • Slowdown of alarm replay relates to the count of kernel call and return instructions executed
  • On an average, alarm replay is 30X slower than recording

32

33 of 35

Conclusion

33

34 of 35

  • RnR-Safe
    • False positives allowed, making hardware security features less intrusive
    • Relies on 2 types of Replayers
      • Checkpointing Replayer
      • Alarm Replayer
    • Detecting ROP attacks
      • Alarm Replayer re-executes the log. Verifies -> Attack or False positive??
      • RAS extended with fields to remove false positives due to
        • Multithreading
        • Non-procedural Alarms
    • Analytics
      • Done using a VM running Linux
      • Chekpoiniting Replayer speed comparable to that of the Recorder
      • Alarm Replayer deals with only few false positives

​

​

​

34

35 of 35

Thank You!

35