Readactor: Practical Code Randomization Resilient to Memory Disclosure

IEEE Symposium on Security and Privacy(Oakland) 2015

presented by LIANG Yu@WHU

IntroductionBackground

Code-reuse attacks pose a severe threat to modern software

designing practical and effective defenses against code-reuse attacks is challenging

Current approaches for defending against code-reuse attacks

1. CFI restriction

2. Lower adversary’s knowledge of memory layout, particularly code page layout

Randomization: ASLR, Fine-grained code diversification,

Memory disclosure restriction: make code pages execute-only (XnR), hiding code pointer(Oxymoron)

Deficiencies of existing solutions (2nd approach)

Vulnerable to memory disclosure

Impractical for deployment on commodity systems

2

Basics—Memory Disclosure

Direct and indirect memory disclosure

3

Basics—Memory Disclosure

Direct and indirect memory disclosure

3

Oxymoron

Basics—Memory Disclosure

Direct and indirect memory disclosure

3

Oxymoron

Isomoron

Basics——Roadmap of Code Reuse

NX/DEP ASLRFine-grained

RandomisationDefences

ExploitationMemory disclosure

+ ROP

ROP

Ret2libc

JIT Code reuse (direct)

Oxymoron

XnR

JIT Code reuse (indirect)

ccs14

USENIX14

S&P,CCS 12~13

JIT dynamically generated code

(indirect)

timeline4

Basics——Roadmap of Code Reuse

NX/DEP ASLRFine-grained

RandomisationDefences

ExploitationMemory disclosure

+ ROP

ROP

Ret2libc

JIT Code reuse (direct)

Oxymoron

XnR

JIT Code reuse (indirect)

ccs14

USENIX14

S&P,CCS 12~13

JIT dynamically generated code

(indirect)

timeline4

static ROP dynamic ROP

Basics——Roadmap of Code Reuse

NX/DEP ASLRFine-grained

RandomisationDefences

ExploitationMemory disclosure

+ ROP

ROP

Ret2libc

JIT Code reuse (direct)

Oxymoron

XnR

JIT Code reuse (indirect)

ccs14

USENIX14

S&P,CCS 12~13

JIT dynamically generated code

(indirect)

timeline

Readactor

4

static ROP dynamic ROP

ReadactorGeneral Idea

mitigate memory disclosure—> defending dynamic ROP

fine-grained code randomisation —> defending static ROP

Readactor —— more practical&effective

hardware-assisted execute-only enforcement

Compiler-based fine-grained randomization

Capability

protect against both direct and indirect memory disclosure

prevent all existing ROP attacks: ROP, ROP without return, dynamical ROP(online attack, e.g.:blind ROP, Just-in-time ROP)

apply execute-only memory enforcement on both statically & dynamically generated code(JIT compiled code)

5

ReadactorGeneral Idea

mitigate memory disclosure—> defending dynamic ROP

fine-grained code randomisation —> defending static ROP

Readactor —— more practical&effective

hardware-assisted execute-only enforcement

Compiler-based fine-grained randomization

Capability

protect against both direct and indirect memory disclosure

prevent all existing ROP attacks: ROP, ROP without return, dynamical ROP(online attack, e.g.:blind ROP, Just-in-time ROP)

apply execute-only memory enforcement on both statically & dynamically generated code(JIT compiled code)

“tackle the shortcomings of existing defenses by closing (direct&indirect) memory disclosure channels while using a

reasonable granularity of code randomization”

5

Overview of ReadactorCompiling Runtime

Hardware-assisted execute-only restriction

6

Implementation Compiler Instrumentation

Code diversification

Code data separation

Code pointer hiding

Execute-only Memory Enforcement via Virtualization

Enforce page access permission via EPT

Thin Hypervisor

7

Execute-only Memory Enforcement

Extended Page Table(EPT)

An new virtualization feature provided by Intel since 2008

EPTs add an additional abstraction layer during the memory translation(translate the physical addresses of a virtual machine (VM) to host(real) physical memory

Page Access permissions can be enforced during address translations

EPTs allow us to enforce execute-only code pages, which isn’t supported by PT

8

Execute-only Memory Enforcement

Extended Page Table(EPT)

An new virtualization feature provided by Intel since 2008

EPTs add an additional abstraction layer during the memory translation(translate the physical addresses of a virtual machine (VM) to host(real) physical memory

Page Access permissions can be enforced during address translations

EPTs allow us to enforce execute-only code pages, which isn’t supported by PT

8

Thin Hypervisor

Objective: Providing an interface to manage EPT permissions and to forward EPT access violations to the OS

Hypervisor: Implemented with less than 500 LOC in C

KernelPatch: 82 LOC is patched to Linux kernel to support mapping execute-only pages

9

Fine-grained code randomization techniques

Function permutation

basic-block insertion

NOP (no-operation) insertion

instruction schedule(order) randomization

equivalent instruction substitution

register allocation randomization

callee-saved register save slot reordering

Code Diversification

10

Code data separationWhy—— make sure code and data mapped into different pages while loading.

Switch-case

LLVM compiler only emits data in the executable .text section of x86 binaries when optimizing a switch-case statement

ELF header

Situation: Linker maps elf-header data and executable code on the first page

Solution: 1) patch for both the BFD and Gold linkers to start the executable code on a separate page from the readable ELF headers; 2) adjust the page permissions appropriately

11

Code data separationWhy—— make sure code and data mapped into different pages while loading.

Switch-case

LLVM compiler only emits data in the executable .text section of x86 binaries when optimizing a switch-case statement

ELF header

Situation: Linker maps elf-header data and executable code on the first page

Solution: 1) patch for both the BFD and Gold linkers to start the executable code on a separate page from the readable ELF headers; 2) adjust the page permissions appropriately

11

Code data separationWhy—— make sure code and data mapped into different pages while loading.

Switch-case

LLVM compiler only emits data in the executable .text section of x86 binaries when optimizing a switch-case statement

ELF header

Situation: Linker maps elf-header data and executable code on the first page

Solution: 1) patch for both the BFD and Gold linkers to start the executable code on a separate page from the readable ELF headers; 2) adjust the page permissions appropriately

12

Code Pointer HidingWhy hiding code pointers?

Threat: Making code non-readable prevents the original JIT-ROP attack but not indirect JIT-ROP

How——add a level of indirection to code pointers

1) creating trampolines for each instruction reachable through an indirect branch

2) replacing all code pointers in readable memory with trampoline pointers

Two kinds of trampolines:

jump trampolines ——to protect function addresses

call trampolines ——to protect call sites

13

Code Pointer HidingHiding code pointers stored in the heap and in C++ vtables via jump trampolines

14

Code Pointer HidingHiding return addresses stored on the machine stack via call trampolines

15

Workflow of Readactor

16

JIT Compiler Protection

Timeline of the execution of a JIT-compiled program. Execution switches between the JIT compiler and generated code

17

Readacted JIT Compiler

Transforming V8 Code objects to separate code and data.

JIT Compiler Protection

Security Evaluation

Evaluated by analysis

1.Static ROP

2.JIT-ROP with direct disclosure

3.JIT-ROP with indirect disclosure

4.ROP on just-in-time generated code

5.Return-to-libc

19

Security EvaluationEvaluated via PoC execution

Info: an artificial vulnerability in V8 JIT, which allows an attacker to read and write arbitrary memory.

attack:

1) disclose a function address

2) overwrite the function with shellcode

3) invoke the function

result: PoC fails to overwrite the function with protected v8

analysis: JIT-compiled code RWX—> execute-only20

Performance Evaluation

SPEC CPU2006

All protections enabled: avg 6.4%

Code-Data Separation: avg <0.5%; max 1.1%

Code-Pointer Hiding: performance slowdown of 4.1%(due to the frequent use of trampolines)

Hypervisor (see the figure)

21

Performance Evaluation

SPEC CPU2006

Hypervisor—— Hypervisor only, without any execute-only page protections or code-pointer hiding enabled Hypervisor XO —— Hypervisor + Execute-only

22

Performance EvaluationChromium Browser

Rendering speed slowdown

All protection-enabled: avg 4.0%

Performance slowdown on Extensive Dromaeo benchmark suite

No code-pointer hiding:2.8% overall

Hypervisor execute-only + code-pointer hiding: 12%

23

Performance EvaluationV8 JavaScript JIT

V8 engine alone

No readactor: 6.2% overall

Readactor enabled: 7.8%

with Chromium Browser

Scrolling smoothness slowdown 13.8% versus 4.0% without the JIT compiler patches

24

Comparison of Various Approaches

Comparison of randomizing defenses against attacks combining memory disclosure and ROP

25

SummaryObjective

prevent attacker from disclosing the code layout :

directly by reading code pages

indirectly by harvesting code pointers from the data areas of a program

Counter measures

direct disclosure ——> hardware-enforced execute-only memory

indirect disclosure ——> code-pointer hiding.26

Achievements

more comprehensive and efficient protection against direct disclosure

the first defense to address indirect disclosure

the first technique to provide uniform protection for both statically and dynamically compiled code.

Summary

27

ReferencesJust-In-Time (JIT) code reuse (S&P’13)

XnR: You can run but you can’t read (CCS’14)

Oxymoron: Making Fine-Grained Memory Randomization Practicalby Allowing Code Sharing (USENIX Security 2014)

HideM: Protecting the contents of userspace memory in the face of disclosure vulnerabilities (CODASPY 2015)

……

28