Shreds: Fine-grained Execution Units with S R D H E S Private - - PowerPoint PPT Presentation

▶
shreds
SMART_READER_LITE
LIVE PREVIEW

Shreds: Fine-grained Execution Units with S R D H E S Private - - PowerPoint PPT Presentation

Feb 19, 2023 163 likes •391 views

Shreds: Fine-grained Execution Units with S R D H E S Private Memory Yaohui Chen, Sebassujeen Reymondjohnson, Zhichuang Sun, Long Lu RiS3 Lab / Computer Science / Stony Brook University 1 Execution Units Traditional Execution Units

slide-1
SLIDE 1

Yaohui Chen, Sebassujeen Reymondjohnson, Zhichuang Sun, Long Lu

RiS3 Lab / Computer Science / Stony Brook University S H R E D S

Shreds:

Fine-grained Execution Units with Private Memory

1

slide-2
SLIDE 2

Shreds: Fine-grained execution units with private memory

Execution Units

A Process

Threads

  • Traditional Execution Units

2

  • Processes
  • Threads
  • Separate address spaces
  • Sharing one address space
slide-3
SLIDE 3

Shreds: Fine-grained execution units with private memory

  • Stealing secret data
  • The Heartbleed bug
  • Executing private code
  • Private APIs in iOS Apps

In-process Memory Abuses

  • Definition:

Malicious or compromised components try to steal data or execute code of other components running in the same process.

3

  • Two examples
slide-4
SLIDE 4

Shreds: Fine-grained execution units with private memory

Potential Mitigations of in-Process Abuse

Techniques Why unsuitable

Process-level isolation

(OpenSSH, Chrome)

  • IPC is expensive
  • Adoption effort

Software fault isolation-like techniques

(Native Client)

  • Require instrumenting untrusted code
  • Ineffective on dynamic or external code

Hardware-assisted techniques

(SGX, Trustzone)

  • Overly restrictive execution environment
  • Semantic gap

4

slide-5
SLIDE 5

Shreds: Fine-grained execution units with private memory

Introducing Shred

Threads Shreds A process

  • Shred
  • Arbitrarily scoped segment of a thread execution
  • S-pool
  • The private memory pool for each shred
  • Shred APIs & OS-level supports

5

๏ Trusted OS ๏ Untrusted component Threat Model

slide-6
SLIDE 6

Shreds: Fine-grained execution units with private memory

Executable Heap

  • Password authentication on web server(w/o shred)

Plaintext password Local Hash

Example Use Case

6

Stack Kernel Libs

slide-7
SLIDE 7

Shreds: Fine-grained execution units with private memory

Example Use Case cont.

Kernel Plaintext password S-pool Local Hash

  • Password authentication on web server(w/ shred)

7

Executable Heap Stack Libs

slide-8
SLIDE 8

Shreds: Fine-grained execution units with private memory

Shred APIs

  • err_t shred_enter(int pool_desc);
  • Start a shred execution on the current thread
  • Unlock s-pool
  • err_t shred_exit();
  • Terminate a shred execution
  • lock down the s-pool
  • void * spool_alloc(size_t size);
  • Allocate memory inside S-pool
  • err_t spool_free(void *ptr);
  • Free memory inside S-pool

Shred creation APIs S-pool allocation APIs 8

slide-9
SLIDE 9

Shreds: Fine-grained execution units with private memory

Code Example—Lighttpd

Listing 1: lighttpd/src/request.c

✖

9

int http_request_parse(server *srv, connection *con) { ... char *cur; /* to receive password */ + if (strncmp(cur, auth_str, auth_str_len)==0){ + shred_enter(AUTH_PASSWD_POOL); + /* receive and save password */ + data_string *ds = s_ds_init(); + int pw_len = get_passwd_length(cur); + cur += auth_str_len + 1; + buffer_copy_string_len(ds->key, auth_str, auth_str_len); + buffer_copy_string_len(ds->value, cur, pw_len); + cur += pw_len; + shred_exit(); + } ... }

slide-10
SLIDE 10

Shreds: Fine-grained execution units with private memory

Code Example cont.

Listing 2: lighttpd/src/data_string.c Listing 3: lighttpd/src/mod_auth.c

S-pool allocation APIs wrapper 10

/* called inside a shred */ data_string *s_ds_init(void) { data_string *ds; + ds = spool_alloc(sizeof(*ds)); ... return ds; } /* called inside a shred */ void s_ds_free(data_string *ds) {

+ ... + spool_free(ds->key); + ...

return; } ... /* inside HTTP auth module */ + shred_enter(AUTH_PASSWD_POOL); /* ds points passwd obj in spool */ http_authorization = ds->value->ptr; /*hash passwd and compare with local copy*/ + s_ds_free(ds); + shred_exit(); ...

slide-11
SLIDE 11

Shreds: Fine-grained execution units with private memory

System overview

  • Two major components

11

S-driver S-compiler

slide-12
SLIDE 12

Shreds: Fine-grained execution units with private memory

System Component: S-driver

S-pool sharing

12

S-driver

๏Entry/exit of shreds ๏S-pool (de)allocations ๏Controls the access to S-pools

shred_enter (P1); shred_exit(); shred_enter (P1); shred_exit(); shred_enter (P2); shred_exit();

Thread1 Thread2

Process

Security Monitor S-pool Manager

…

S-pool: P2 S-pool: P1

S-driver

Mem Space Runtime

slide-13
SLIDE 13

Shreds: Fine-grained execution units with private memory

How S-pool is Built

  • ARM Memory Domains—The building block

…

D0 D1 D14 D15

Domain Access Control Register

D1 D14 D1

…

Page Directory Descriptor

… … …

Page Table Descriptor

PDE# 0 PDE# 1 PDE#1023

: Accessible : Not accessible

13 Intel: Memory protection keys

slide-14
SLIDE 14

Shreds: Fine-grained execution units with private memory

1)The granularity of the accessing subject can only be checked at CPU level

  • ARM Memory Domain was not designed to serve our goal

2) Limited Domains: Only 16 Domains are available ✓Create the notion of shred so the accessing subject can be recognized and use S-driver to manage them ✓Statically bind an accessible domain to each CPU ✓Reuse a domain for multiple S-pools if they are accessed from the same CPU

Challenges & Solutions

… …

Domain Access Control Register Domain Access Control Register

Core #1 Core #2

s-pool #1 s-pool #2

Virtual Address Space

14

slide-15
SLIDE 15

Shreds: Fine-grained execution units with private memory

S-pool Managements

  • Unlock s-pool when,
  • Lock s-pool when,
  • Shred exits
  • Context-switch Out
  • Asynchronous events: signal handling, etc
  • Shred enters
  • Context-switch in
  • Resuming from asynchronous events

S-driver will,

15

slide-16
SLIDE 16

Shreds: Fine-grained execution units with private memory

Moving the Domain Adjustments Off the Critical Path

  • Changing PDE is relatively cumbersome
  • Page table walking
  • TLB invalidation
  • TWO knobs to control the accessibility of S-pool
  • Domain of the corresponding page table entry
  • Value of corresponding DACR entry
  • Changing DACR value is much faster, only one instruction
  • MCR p15, 0, <Rd>, c3, c0, 0 ; Write DACR
  • Develop the domain fault handler to handle domain fault lazily
  • Detecting attacks
  • Recover from legitimate domain faults

16

slide-17
SLIDE 17

Shreds: Fine-grained execution units with private memory

Runtime Protections

๏ Secure stacks

  • Each shred has a secure stack allocated from its s-pool

๏ System interface protection

  • ptrace()
  • Directly read secret from file
  • etc
  • /dev/mem

17

slide-18
SLIDE 18

Shreds: Fine-grained execution units with private memory

System Component: S-compiler

Shred- hardening Analyses

src.c

S-compiler

Development and build

… int enc(x) { … shred_enter(p1); //encryption logic shred_exit(); … 18

S-compiler

๏ Shred usage verification ๏ Associate each shred with its s-pool ๏ Control flow hardening for in-shred code ๏ Data flow checking to prevent direct-propagation

S h r e d s : F i n e

  • g

r a i n e d E x e c u t i

  • n

U n i t s w i t h P r i v a t e M e m

  • r

y

Y a

  • h

u i C h e n S e b a s s u j e e n R e y m

  • n

d j

  • h

n s

  • n

Z h i c h u a n g S u n L

  • n

g L u

D e p a r t m e n t

  • f

C

  • m

p u t e r S c i e n c e S t

  • n

y B r

  • k

U n i v e r s i t y { y a

  • h

c h e n , s r e y m

  • n

d j

  • h

n , z h i s u n , l

  • n

g } @ c s . s t

  • n

y b r

  • k

. e d u A b s t r a c t — O n c e a t t a c k e r s h a v e i n j e c t e d c

  • d

e i n t

  • a

v i c t i m p r

  • g

r a m ’ s a d d r e s s s p a c e ,

  • r

f

  • u

n d a m e m

  • r

y d i s c l

  • s

u r e v u l n e r

  • a

b i l i t y , a l l s e n s i t i v e d a t a a n d c

  • d

e i n s i d e t h a t a d d r e s s s p a c e a r e s u b j e c t t

  • t

h e f t s

  • r

m a n i p u l a t i

  • n

. U n f

  • r

t u n a t e l y , t h i s b r

  • a

d t y p e

  • f

a t t a c k i s h a r d t

  • p

r e v e n t , e v e n i f s

  • f

t w a r e d e v e l

  • p

e r s w i s h t

  • c
  • p

e r a t e , m

  • s

t l y b e c a u s e t h e c

  • n

v e n t i

  • n

a l m e m

  • r

y p r

  • t

e c t i

  • n
  • n

l y w

  • r

k s a t p r

  • c

e s s l e v e l a n d p r e v i

  • u

s l y p r

  • p
  • s

e d i n

  • p

r

  • c

e s s i s

  • l

a t i

  • n

m e t h

  • d

s a r e n

  • t

p r a c t i c a l f

  • r

w i d e a d

  • p

t i

  • n

. s h r e d s , a s e t

  • f

O S

  • b

a c k e d p r

  • g

r a m m i n g p r i m i

  • d

e v e l

  • p

e r s ’ c u r r e n t l y u n m e t n e e d s f

  • r

fi n e

  • e

f fi c i e n t p r

  • t

e c t i

  • n
  • f

s e n s i t i v e m e m

  • r

y e r s a r i e s . A s h r e d c a n b e v i e w e d a s e x e c u t i

  • n

( h e n c e t h e n a m e ) . m e m

  • r

y p

  • l

, w h i c h U n l i k e p r e v i

  • u

s r e l y i n g

  • n

w a r e .

process remains an open issue, which has been increasingly exploited by attackers. To address this open issue, some recent work proposed the thread-level memory isolation [3], which allows developers to limit the sharing of a thread’s memory space with other threads in the same process. However, this line of works faces three major limitations. First, thread-level memory isolation is still too coarse to stop in-process abuse because exploitable or malicious code often run in the same thread as the legitimate code that needs to access sensitive memory content. Sec-

  • nd, adopting these solutions requires significant efforts from
  • developers. Separating application components into different

threads (i.e., scheduling units) demands major design changes, as opposed to regional code patches, to deal with the added

  • concurrency. Third, threads with private memory tend to

incur much higher overhead than normal threads due to the additional page table switches, TLB flushes, or nested page management upon context switches. We aim to tackle proposing a practical and effective system memory. w execution unit for user- represents an arbitrarily and is granted shred- relation

slide-19
SLIDE 19

Shreds: Fine-grained execution units with private memory

Evaluation

๏ Hardware spec: Raspberry Pi 2 Model B (Quad-core Cortex-A7 Processor with 1GB RAM) Softwares Low overhead ๏ Curl ๏ Minizip ๏ OpenSSH ๏ OpenSSL ๏ Lighttpd ๏ Avg. 4.67% slowdown ๏ Avg. 7.26% RSS(resident set size) overhead Easy adoption ๏ Avg. 21 SLOC change ๏ Avg. 32 min adoption time

19

slide-20
SLIDE 20

Shreds: Fine-grained execution units with private memory

Evaluation cont.

20

slide-21
SLIDE 21

Shreds: Fine-grained execution units with private memory

Conclusion

๏ Goal— To help developers protect sensitive code/data from in-process abuse ๏ To achieve the goal we propose shreds with private memory

  • Fine-grained: Flexibly scoped segments of thread executions
  • Efficient and compatible : MMU based domain check
  • No multiple page tables
  • No nested paging
  • No heavy instrumentations
  • No hardware modifications
  • Robust:
  • Prevent out-shred attacks + intra-shred vulnerabilities

21