1 / 42

Security of Multithreaded Programs by Compilation

Security of Multithreaded Programs by Compilation. Tamara Rezk INDES Project, INRIA Sophia Antipolis Mediterranee Joint work with Gilles Barthe , Alejandro Russo, Andrei Sabelfeld Torino, April 21 st Matyss COLOR Project. In this talk:. Security of mobile code (proof carrying code)

hal
Download Presentation

Security of Multithreaded Programs by Compilation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security of Multithreaded Programs by Compilation Tamara Rezk INDES Project, INRIA Sophia AntipolisMediterranee Joint work with Gilles Barthe, Alejandro Russo, Andrei Sabelfeld Torino, April 21st Matyss COLOR Project

  2. In this talk: • Security of mobile code (proof carrying code) • Verification of confidentiality in low level languages • Connection between different type systems • A modular approach to verification of multithreaded code and its connection to low level multithreaded code

  3. In this talk: • Security of mobile code (proof carrying code) • Verification of confidentiality in low level languages • Connection between different type systems • A modular approach to verification of multithreaded code and its connection to low level multithreaded code

  4. Proof Carrying Code scenarios PRODUCER SIDE CONSUMER SIDE

  5. Mobile Code example: Java applets program program PRODUCER SIDE CONSUMER SIDE

  6. Mobile Code example: Java applets program program NETWORK security guarantees? compiler PRODUCER SIDE CONSUMER SIDE

  7. program program NETWORK difficult! iflow type inference compiler PRODUCER SIDE CONSUMER SIDE

  8. program program NETWORK rejected difficult! easy iflow type inference iflow type checking code + type accepted compiler PRODUCER SIDE CONSUMER SIDE

  9. Proof Carrying Code program program NETWORK rejected difficult! easy iflow type inference iflow type checking TCB code + type accepted compiler PRODUCER SIDE CONSUMER SIDE

  10. Motivation of this work • Insecure flows in mobile code can be prevented by program analysis but • Information flow for multithreaded low-level code has not been addressed so far

  11. Contribution of this work We propose a framework to enforce security for multithreaded low-level programs and extends it for security-type preserving compilation

  12. In this talk: • Security of mobile code (proof carrying code) • Verification of confidentiality in low level languages • Connection between different type systems for iflow • A modular approach to verification of multithreaded code and its connection to low level multithreaded code

  13. Verification of iflow for low level code

  14. Verification of iflow for low level code High-level code Low-level code

  15. Verification of iflow for low level code High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax • Typing rules are syntax directed

  16. Verification of iflow for low level code High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack • Typing rules are syntax directed • Memory model includes a store

  17. Verification of iflow for low level code High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability : composition is given by the successor relation between program points • Typing rules are syntax directed • Memory model includes a store • Typability: given by the typing rule of sequential composition

  18. Verification of iflow for low level code • Tracking information flow via control flow in high-level languages is syntax-directed: Control dependence regions are given by control structure if (y==0) then x :=3; else x:=1; Control dependence region includes program points x:=3; and x:=1 (dependent on expression y==0)

  19. e:k c:k1 c’:k2 k≤k1 k ≤ k2 |- If e then c else c’: k if (y==0) then x :=3; else x:=1;

  20. e:k c:k1 c’:k2 k≤k1 k ≤ k2 |- If e then c else c’: k 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8… if (y==0) then x :=3; else x:=1;

  21. e:k c:k1 c’:k2 k≤k1 k ≤ k2 |- If e then c else c’: k 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8… if (y==0) then x :=3; else x:=1; region(2)

  22. e:k c:k1 c’:k2 k≤k1 k ≤ k2 Instr[pc]=ifeq j i in region(pc) k≤ se(i) |- If e then c else c’: k se |- k :: st => st 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8… if (y==0) then x :=3; else x:=1; k1 k1 k region(2) k2 k2 se

  23. Observation: low level verification is more general…. High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points • Typing rules are syntax directed • Memory model includes a store • Typability of programs: given by the typing rule of sequential composition

  24. In this talk: • Security of mobile code (proof carrying code) • Verification of confidentiality in low level languages • Connection between different type systems for iflow • A modular approach to verification of multithreaded code and its connection to low level multithreaded code

  25. How to connect two different type systems High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points • Typing rules are syntax directed • Memory model includes a store • Typability of programs: given by the typing rule of sequential composition

  26. How to connect two different type systems High-level code Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points • Typing rules are syntax directed • Memory model includes a store • Typability of programs: given by the typing rule of sequential composition

  27. How to connect two different type systems • We annotate high level code with labels and keep these labels for compilation. • The compiler generate low level control dependence regions for high-level control dependence regions • We compile types of expressions in high level typing derivation trees into stack types • Typability does not require further work.

  28. In this talk: • Security of mobile code (proof carrying code) • Verification of confidentiality in low level languages • Connection between different type systems for iflow • A modular approach to verification of multithreaded code and its connection to low level multithreaded code

  29. A modular approach: from sequential to multithreaded code verification… • Barthe, Naumann, and Rezk (S&P 06) noticed that low-level type system generalized high-level type systems , and could be connected by specific compilers for information flow • Russo and Sabelfeld (CSF 06) observed that verification of multithreaded code for a while language with a “fork” feature for thread creation could be done by a non-interference property not based on bisimulations

  30. Feature of our framework Security guaranteed is not more restrictive than ones of sequential programs Example of an internal timing leak: if hi {sleep(100)}; lo:=1 || sleep(50); lo:=0

  31. Approach of multithreaded verification Security guaranteed is not more restrictive than ones of sequential programs Example of an internal timing leak: if hi {sleep(100)}; lo:=1 || sleep(50); lo:=0 The scheduler treats the first thread as “hidden” from the second thread!!

  32. Modularity is the consequence of the approach • The framework modularly extends sequential semantics (language independence from the sequential part) • Modular extension of sequential type systems • Security type preserving compilation is also a modular extension of the sequential counterpart

  33. A program consists of: • A set of program points (including entry, exit) • An instruction map from program points to Ins where Ins= SeqIns U {start pc}

  34. Concurrent Semantics • A state s consists of a mapping from threads to local states , plus a global state • A configuration includes an execution history h

  35. Hypothesis on the scheduler

  36. Extended concurrent type system

  37. Extended concurrent type system

  38. In the paper: • We prove soundness: by assuming soundness of the sequential type system • We show how this result directly extends to type-preserving compilation schemes • We instantiate the framework to a case study: the JAVA-like language to multithreaded JVM

  39. Type-preserving compilation

  40. Type-preserving compilation

  41. Type-preserving compilation

  42. Conclusion • We have proposed a framework for controlling information flow in multithreaded code • Thanks to modularity and language-independence, results for sequential languages can be reused.

More Related