Lord of the X86 Rings: A Portable User Mode Privilege Separation Architecture on X86 (CCS'18) [Unofficial] Slide presented by cxm95

1. Lord of the X86 Rings: A Portable User Mode
Privilege Separation Architecture on X86
Memory Defense Paper Sharing(I) ccs 2018
Hojoon Lee, Chihyun Song, Brent
Byunghoon Kang
Presented by Xingman Chen
2018-10-09

2. In-Process Isolation
● Most attacks against
○ Control Flow
■ Control flow hijack/bending
○ Data Flow
■ Non-control data attack
2

3. In-Process Isolation
● Most attacks against
○ Control Flow
■ Control flow hijack/bending
○ Data Flow
■ Non-control data attack
● Sensitive data in memory
○ Cryptographic keys
○ Function table
○ Control flow intergrity mitigation metadata
○ (Un)trust libs
● Need to be protected
3

4. Motivations
● HeartBleed Vulnerability
○ A malicious memcpy(bp,pl,payload) in
openssl nearly bring down the HTTPs
○ Sensitive data: Private key
4

5. Motivations
● Metadata Protection
○ Shadow Stack
■ Backup return address to avoid ret based
control flow hijack
■ Sensitive data: backup return address
○ Code Pointer Intergrity
■ Move code pointer and indirect code
pointers to safe region
■ Sensitive data: safe region
5

6. Motivations
● Metadata Protection
○ Shadow Stack
■ Backup return address to avoid ret based
control flow hijack
■ Sensitive data: backup return address
○ Code Pointer Intergrity
■ Move code pointer and indirect code
pointers to safe region
■ Sensitive data: safe region
6

7. Motivations
● Untrusted Library
○ Blackhat’17 by Chaitin: Many Birds, One Stone: Exploiting a Single SQLite Vulnerability
Across Multiple Software
○ CVE-2015-7036
■ SQLite fts3_tokenizer Untrusted Pointer Remote Code Execution Vulnerability
7

8. In-Process Isolation: Approaches
● Software based
○ Randomization based
■ e.g. ASLR
○ Instrument non-sen code with bounds
checks prior to indirect memory
accesses
■ e.g. SFI
8
Application
Sen-Code
(Sensitive Data
Related Code)
Non Sen Code Non Sen Memory
Sen Memory

9. ● Software based
○ Randomization based
■ e.g. ASLR
○ Instrument non-sen code with bounds
checks prior to indirect memory
accesses
■ e.g. Software Fault Isolation(SFI)
● OS/Hardware based
○ OS feature based: Paging or
Segmentation based appoarches
○ Hardware feature based
■ e.g. intel MPX(CFIXX), SGX, CET,
MPK; arm Memory
Domain(Shred)
In-Process Isolation: Approaches
9
Application
Sen-Code
(Sensitive Data
Related Code)
Non Sen Code Non Sen Memory
Sen Memory

10. Lord of the x86 Rings: A Portable User Mode Privilege
Separation Architecture on x86
● Presented LOTRx86, a novel approach that establishes a new user privilege
layer safeguards secure access sensitive data to achieve in-process privilege
separation
● OS Feature based
● Feature
○ No extra hardware feature needed
○ Fast: average of 30.40% overhead on Intel processor
10

11. Motivation
● Randomization based: Weak
● SFI: High overhead
● Hardware feature based: Not portable
● LOTRx86: Trade off
○ Portable approach based on segmentation & paging features
○ Harnesses the underused x86 intermediate Rings (Ring1 and Ring2)
11

12. Preliminaries: Addressing in x86
● Segmentation in x86(IA-32,386)
○ DPL(Description Priviliege Level): in GDT/LDT
○ CPL(Current Priviliege Level): 2bit in Segment
register(cs)
○ RPL(Request Privilege Level)
12

13. Preliminaries: Addressing in x86
● Pagging in x86
○ 2-level page table
■ User/Supervisor: priviliege
required for accessing this page
13

14. Preliminaries: Addressing in x64
● x64(x86_64,amd64/IA-32e, EM64T): Weakened Segmentation
14

15. Preliminaries: Addressing in x64
● x64(x86_64,amd64/IA-32e, EM64T): Weakened Segmentation
○ Treats the segment base of CS, DS, ES, SS as zero, creating a linear address
○ Used only for memory protection
○ CPL Remained
■ DPL: Valid for code segment descriptor, ignored for data segment descriptor
15

16. Preliminaries: Callgate
● Callgate: Privilege escalation &
de-escalation
○ Callgate Descriptor defined at
GDT/LDT
○ DPLg: minium priv requirement
○ Stack pivot after
escalation/decalation
16

17. Preliminaries: Inter-bitness control transfer
● Bitness(32/64): defined by the
currently active code segment
descriptor
○ L bit
○ callgate cannot target a 32-bit code
segment in long mode(64 bit)
17

18. Thread Model & Target
● Thread Model
○ Arbitary Code Execution
● Security Guarantee
○ User mode cannot directly access a
region protected
18
Application
Sen-Code
(Sensitive Data
Related Code)
Non Sen Code Non Sen Memory
Sen Memory

19. ● Establishing PrivUser memory
space
○ M-SR1. User mode must not be able
to access PrivUser memory
■ set S-page PTE s-bit
Design
19

20. ● Establishing PrivUser memory
space
○ M-SR1. User mode must not be able
to access PrivUser memory
■ set S-page PTE s-bit
○ M-SR2. PrivUser mode must not be
able to access kernel memory space
■ set privuser code page as
32-bit segmentation enabled
code segment
● run 32bit code with
special segment(cs)
Design
20

21. Design
● Challenges
○ Hardware constraint: 32-bit call gate is
disabled, a 64-bit call gate have to be
introduced
○ Potential risk: any non-ring3 64-bit code
can access kernel memory
■ if Privuser jump to 64-bit call gate
area instead of call gate entry, it
can access the kernel memory
21

22. Design
● Challenges
○ Hardware constraint: 32-bit call gate is
disabled, a 64-bit call gate have to be
introduced
○ Potential risk: any non-ring3 64-bit
code can access kernel memory
■ if Privuser jump to 64-bit call gate
area instead of call gate entry, it
can access the kernel memory
● Solution: Inescapable segmentation
enforcement
○ An ring-1 callgate(x64) with lret
22

23. Design
● Challenges
○ Hardware constraint: 32-bit call gate is
disabled, a 64-bit call gate have to be
introduced
○ Potential risk: any non-ring3 64-bit
code can access kernel memory
■ if Privuser jump to 64-bit call gate
area instead of call gate entry, it
can access the kernel memory
● Solution: Inescapable segmentation
enforcement
○ An ring-1 callgate(x64) with lret
23

24. Implementation
● Components
○ lotr-kmod: build PrivUser space
■ space size is fixed
■ generate LDT, init S-page PTE, init ring1 ring2
○ liblotr: util functions for calling initalize PrivUser space, entering, etc.
○ lotr-libc: private libc, no scalable
○ kernel modification: let mmap/mprotect bypass and return error
24

25. Implementation
● Components
○ lotr-build: create 32-bit machine code
25

26. Evaluation
● Micro-benchmark
○ compare with normal function
■ But why intel different with amd?
26
no cache
opt

27. Evaluation
● micro-Benchmark
○ compare with normal function
27

28. Evaluation
● LOTRx86 enabled web server
○ latency: response time
28

29. Discussion
● Portable but no scalable
○ e.g. Size, Libc, argument passing
● Low automation
● High Overhead: 35%
29

30. Thanks!
30