Security of Multithreaded Programs by Compilation

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.