Safe Loading A Foundation for Secure Execution of Untrusted - - PowerPoint PPT Presentation

▶
safe loading a foundation for secure execution of
SMART_READER_LITE
LIVE PREVIEW

Safe Loading A Foundation for Secure Execution of Untrusted - - PowerPoint PPT Presentation

Jun 15, 2023 174 likes •488 views

Safe Loading A Foundation for Secure Execution of Untrusted Programs Mathias Payer, Tobias Hartmann, Thomas R. Gross Department of Computer Science ETH Zurich, Switzerland Motivation Application code Kernel 2 Motivation Application code

slide-1
SLIDE 1

Safe Loading A Foundation for Secure Execution of Untrusted Programs

Mathias Payer, Tobias Hartmann, Thomas R. Gross Department of Computer Science ETH Zurich, Switzerland

slide-2
SLIDE 2

2

Motivation

Kernel Application code

slide-3
SLIDE 3

3

Motivation

Kernel Sandbox Application code ld.so

Code

slide-4
SLIDE 4

4

Sandbox

Motivation

Kernel Sandbox Application code ld.so

Code

slide-5
SLIDE 5

5

Trusted RUntime Environment

Kernel Sandbox Trusted loader TRuE

application library library ...

slide-6
SLIDE 6

6

Outline

  • Motivation
  • Attack and execution model
  • Trusted Runtime Environment
  • Evaluation
  • Related work
  • Conclusion
slide-7
SLIDE 7

7

Attack constraints

  • Attacker tries to escalate privileges with:
  • Code injection
  • Code reuse (ROP / JOP*)
  • Data attacks

Code Data * ROP – Return Oriented Programming: Shacham, CCS'07 JOP – Jump Oriented Programming: Bletsch et al., ASIACCS'11

slide-8
SLIDE 8

8

Attack constraints

  • Attacker tries to escalate privileges with:
  • Code injection
  • Code reuse (ROP / JOP*)
  • Data attacks
  • Application is killed on policy violation

Code Data * ROP – Return Oriented Programming: Shacham, CCS'07 JOP – Jump Oriented Programming: Bletsch et al., ASIACCS'11

X

slide-9
SLIDE 9

9

Execution model

  • Application is untrusted (not malicious)
  • Symbol table and ELF information used in sandbox
  • Secure execution uses
  • Secure loader to bootstrap application
  • Sandbox to protect from any code-based and data-based exploits
slide-10
SLIDE 10

10

Outline

  • Motivation
  • Attack model
  • Trusted Runtime Environment
  • Security architecture
  • Safe loading
  • Sandbox & System call policy
  • Implementation
  • Evaluation
  • Related work
  • Conclusion
slide-11
SLIDE 11

11

Kernel Sandbox Application System call policy TRuE

Security architecture

Secure Loader

slide-12
SLIDE 12

12

Secure loader

ld.so regular sandbox

  • transl. ld.so

application library ... ??? Secure loader safe sandbox application library ... TRuE: Traditional loading: late interception loader as black box

slide-13
SLIDE 13

13

Secure loader

ld.so regular sandbox

  • transl. ld.so

application library ... ??? Secure loader safe sandbox application library ... TRuE: Traditional loading: late interception loader as black box

Information & safe sandbox instantiation

slide-14
SLIDE 14

14

SFI sandbox

  • Translates individual basic blocks
  • Checks branch targets and origins
  • Weaves guards into translated code

Original code Translated code Dynamic translator 1 2 4 3 1' 2' 3'

Sandbox Kernel

System call policy

slide-15
SLIDE 15

15

SFI sandbox

  • Translates individual basic blocks
  • Checks branch targets and origins
  • Weaves guards into translated code

Original code Translated code Dynamic translator 1 2 4 3 1' 2' 3'

Sandbox Kernel

System call policy

Protects from code-based and data-based attacks

slide-16
SLIDE 16

16

TRuE: implementation

  • Prototype implementation (open source)
  • Focus on IA32 and Linux
  • Concept works for any ISA and operating system
  • Small trusted computing base

Code Comments Secure loader 5,400 2,100 Sandbox 15,200* 3,200 *4,900 LOC for the translation tables

slide-17
SLIDE 17

17

Outline

  • Motivation
  • Attack model
  • Trusted Runtime Environment
  • Evaluation
  • Security discussion
  • SPEC CPU2006 performance
  • Related work
  • Conclusion
slide-18
SLIDE 18

18

Security discussion

  • Two execution domains
  • Privileged sandbox domain
  • Unprivileged application domain (traps into sandbox)
  • Sandbox ensures code integrity
  • Protection from code-injection and return oriented programming
  • Policy protects from jump oriented programming and data attacks
  • Secure loader enables safe program instantiation
  • Low complexity (bare bone functionality)
  • API for requests from the application
slide-19
SLIDE 19

19

Security discussion

  • Two execution domains
  • Privileged sandbox domain
  • Unprivileged application domain (traps into sandbox)
  • Sandbox ensures code integrity
  • Protection from code-injection and return oriented programming
  • Policy protects from jump oriented programming and data attacks
  • Secure loader enables safe program instantiation
  • Low complexity (bare bone functionality)
  • API for requests from the application

Protects unmodified, binary applications from attacks

slide-20
SLIDE 20

20

SPEC CPU 2006 performance

  • Benchmarks execute with well-defined policy
  • On Ubuntu Jaunty
  • Intel Xeon E5520 CPU at 2.27GHz
  • GCC version 4.3.3
  • Three configurations:
  • native
  • Secure loader (without sandbox)
  • TRuE (secure loader plus sandbox)
slide-21
SLIDE 21

21

SPEC CPU 2006 performance

Benchmark Secure Loading TRuE 400.perlbench

  • 0.3%

85% 401.bzip2

  • 0.1%

4.9% 429.mcf

  • 0.1%

0.5% 464.h264ref

  • 0.3%

41% 433.milc 0.1% 3.7% Average*

  • 0.1%

15% * Average is calculated over all 28 SPEC CPU2006 benchmarks

slide-22
SLIDE 22

22

SPEC CPU 2006 performance

Benchmark Secure Loading TRuE 400.perlbench

  • 0.3%

85% 401.bzip2

  • 0.1%

4.9% 429.mcf

  • 0.1%

0.5% 464.h264ref

  • 0.3%

41% 433.milc 0.1% 3.7% Average*

  • 0.1%

15% * Average is calculated over all 28 SPEC CPU2006 benchmarks

Low performance impact

slide-23
SLIDE 23

23

Outline

  • Motivation
  • Attack model
  • Trusted Runtime Environment
  • Evaluation
  • Related work
  • Conclusion
slide-24
SLIDE 24

24

Related work

  • System call interposition (Janus, AppArmor)
  • Only system calls checked, code is unchecked
  • Software-based fault isolation (Libdetox, Vx32, Strata)
  • Only a sandbox is not enough, additional guards and system call

authorization needed, no loader information

  • Static binary translation (Google's NaCL, PittSFIeld)
  • Limits the ISA, static, special compilers needed
  • Full system translation (VMWare, QEMU, Xen)
  • Management overhead, data sharing problem
slide-25
SLIDE 25

25

Outline

  • Motivation
  • Attack model
  • Trusted Runtime Environment
  • Evaluation
  • Related work
  • Conclusion
slide-26
SLIDE 26

26

Conclusion

  • TRuE protects from code-based and data-based exploits
  • Secure loader extracts information
  • Sandbox protects from code-based and data-based exploits
  • Trusted secure loader increases security
  • Application needs no privileges to map code executable
  • Knowledge of program structure enables new guards
  • TRuE protects unmodified applications in user-space
slide-27
SLIDE 27

27

Questions?

?

http://nebelwelt.net/projects/TRuE/

slide-28
SLIDE 28

28

Software based fault isolation

  • Translates individual basic blocks
  • Checks branch targets and origins
  • Weaves guards into translated code

1 1' 2 2' 3 3' … ... Original code Code cache Mapping table Dynamic translator 1 2 4 3 1' 2' 3' R RX

Indirect control flow transfers use a dynamic check to verify target and

  • rigin
slide-29
SLIDE 29

29

Implementation alternatives

  • Static binary translation
  • No second protected domain
  • No dynamic library/module support
  • Restricted ISA
  • Regular loader, hidden sandbox
  • Sandbox hidden by modifying loader data-structures
  • Loader treated as black-box
slide-30
SLIDE 30

30

Malicious applications

  • No information about internal control flow
  • Coarse-grained protection at system call level
  • Application can use CPU time (inside the app)
  • System call policy protects from malicious system calls