1. Flexible In-lined Reference Monitor Certification: Challenges and Future Directions Meera Sridhar and Kevin W. Hamlen University of Texas at Dallas January 29, 2011 Supported by a grant from AFOSR PLPV 2011 Austin, TX

2. Outline Part I: Introduction – IRM's and the IRM Certification Problem Part II: IRM Policy Specification Challenges – How can we specify policies in a way that is both intuitive and amenable to both automated enforcement and automated certification? Part III: Three Outstanding IRM Certification Challenges – Runtime code generation – Concurrency – Semantic equivalence 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 2

3. Reference Monitors (not in-lined) 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 3 OS/VM R EFERENCE M ONITOR grant/denyevent Examples: file system permissions memory safety Disadvantages: — changing the policy requires changing the OS/VM — Example: On Windows, enforce “applications cannot create files ending in.exe” UNTRUSTED CODE

4. In-lined Reference Monitors [Schneider, TISSEC, ‘00] 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 4 OS/VM R EFERENCE M ONITOR grant/deny event UNTRUSTED CODE  enforce safety policies by injecting runtime security guards into untrusted binaries o guards test whether the impending operation constitutes a policy violation, and if so some corrective action is taken  maintain history of security-relevant events  Advantages: o enforce richer policies: e.g., no network sends after file reads o sufficient to enforce safety, some liveness o more powerful than purely static analysis o No need to modify the OS/VM o more flexible: code recipient can specify security policy  Examples: SASI [Erlingsson, Schneider], Java-MAC [Kim, Kannan, Lee, Sokolsky, Viswanathan], Java-MOP [Chen, Rosu], Polymer [Bauer, Ligatti, Walker], ConSpec [Aktug, Naliuka], MoBILe [Hamlen, Morrisett, Schneider]

5. In-lined Reference Monitor E XAMPLE 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 5 b := false;... call Read; b := true;... if b then halt; call Send;... Policy: no sends after reads untrusted BINARY coderewritten binary code Rewriter... call Read;... call Send;...

6. IRM Certification IRMs really powerful, but want formal guarantees that static analysis can provide solution: static verification of IRMs – best of both worlds! – combine power and flexibility of dynamic monitoring with strong formal guarantees of static analysis What do we want from the certifier? – automatic, machine-certification of IRM's on-demand – formal guarantees of soundness – rewritten code satisfies the policy transparency – behavior of good programs preserved by rewriting – light-weight certifier (embedded systems) 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 6

7. IRM Certification 1/17/2010 Sridhar and Hamlen: Model-Checking In-lined Reference Monitors 7 R EWRITER UNTRUSTED CODE POLICY VERIFIER reject (rewriter failure) execute REWRITTEN CODE Related work: ConSpec [Aktug, Naliuka, Sci. of Comp. Prog, ‘08] (certification via contracts), MoBILe [Hamlen, Morrisett, Schneider, PLAS, ‘06] (certification via type-checking) [Sridhar, Hamlen, VMCAI, ‘10] (certification via model-checking) Trusted Computing Base

8. Certifiying IRMs A N EW P ROBLEM D OMAIN certifying IRM’s easier than verifying safety of arbitrary code! – interplay between certifier and rewriter power – rewriter simplifies certifier’s task by inserting guards that obviate safety proof – certifier only needs to identify guards used by IRM to protect dangerous operations verify that guards are not circumvented by unguarded control flows – greater certifier power = greater rewriter flexibility Certifier can be lighter weight – SPIN vs. our previous work ( [DeVries, Gupta, Hamlen, Moore, Sridhar, PLAS, ‘09], [Sridhar, Hamlen, VMCAI, ‘10] ) Different than Proof-Carrying Code (PCC) – PCC rewriters (certifying compilers) [Necula, Lee] leverage source level info – typically unavailable to binary rewriters 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 8

9. Policy Specification Languages A PPROACH 1 policies themselves expressed as code-transformation recipes policy spec tells rewriters what to do most IRM systems today problem: – specification parts consist of code fragments (advice) – approach lends itself to rewriting – but meaningful certification difficult – certification only makes sense when a policy is a program property rewriting sub-problem of certification, leaks back into TCB (examples: ConSpec [Aktug, Naliuka], Polymer [Bauer, Ligatti, Walker], Java-MOP [Chen, Rosu], SASI [Erlingsson, Schneider], [Evans, Twynman, S&P, ‘99], Java-MaC [Kim, Kannan, Lee, Sokolsky, Vishwanathan] ) 1/29/20119 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

10. Approach 1 A POLICY IN C ONSPEC Policy: no sends after reads SCOPE Session SECURITY STATE bool accessed = false; bool permission = false; BEFORE Network.Send PERFORM !accessed -> {permission = true;} accessed -> {permission = false;} AFTER File.Read PERFORM true -> {accessed = true;} -- IRM must have exactly these variables, must have exactly these functions -- for general IRMs, re-do work of rewriter to check 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 10

11. temporal logics (LTL etc.), security automata, types(?) Key Benefits: – verification of P possible without synthesizing a program satisfying P – certifier does not inspect original untrusted code less code duplication between rewriter and certifier certification  meaningful reduction to TCB certification  meaningful second line of defense – policies define what security property not how rewriter free to pick optimal rewriting strategy customized according to information available only at rewrite time 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 11 Policy Specification Languages A B ETTER A PPROACH specify policies purely declaratively

12. Certifying IRMs R ELATED W ORK S URVEY Mobile [Hamlen, Morrisett, Schneider] – can verify general temporal properties – limited guard recognition – requires specific dynamic state representation scheme, – limited aliasing of security-relevant objects Model-checking [Sridhar, Hamlen, VMCAI, ‘10] – security automata for abstract interpretation lattice – policy violations -- stuck states in concrete small-step operational semantics – proof of soundness -- abstract machine sound w.r.t. concrete machine Information-flow IRMs [Chudnov, Naumann, CSF, ‘10] – proof that a particular rewriting algorithm is both sound and transparent 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 12

13. Part III Three prominent, challenging, unsolved problems in the IRM certification domain. eval() concurrency transparency 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 13

14. eval() performs runtime code generation (similar to Lisp back-quote) consistent concern in security literature majority of past IRM work assumes either: – eval sufficiently rare  simply reject conservatively – sufficiently innocuous  safely ignore actuality – – widespread, nontrivial, security-relevant (e.g. XSS) use of eval [Richards, Lebresne, Burg, Vitek, PLDI, ‘10] function MM_jumpMenu(targ,selObj,restore){ eval (targ+".location='"+selObj.options[selObj.selectedIndex].value+"'"); if (restore) selObj.selectedIndex=0; } 1/29/2011 14 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

15. eval() V ERIFICATION C HALLENGE naïve solutions – – simply pass runtime-generated code through second round of rewriting! not a feasible option! - not very scalable, majority IRM frameworks -- rewriter is unavailable at runtime – sanitize! need something smarter main static analysis challenge – string input typically constructed from several components – some only available at runtime (e.g., user input) current static analyses, either – ignore it ( [Anderson, Drossopoulou, WOOD, ‘03], [Anderson, Giannini, ENTCS, ‘05], [Jang, Choe, SAC, ‘09], [Thiemann, TLDI, ‘05] ), or – supply a relatively inflexible mechanism ( [Guha, Krishnamurthi, Jim, WWW, ‘09], [Jensen, Moller, Thiemann, SAS, ‘09] ) fixed reference grammar does not generalize to non-trivial generation of strings outside 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 15

16. eval() P RIOR W ORK 1.[Christensen, Moller, Schwartzbach, SAS, ‘03] – extract context-free grammars from Java programs – use a natural language processing algorithm to compute regular grammars – grammars generate each string expression’s language of possible values 2.[Thiemann, TLDI, ‘05] – type system for analyzing string expressions – type inferencing infers language inclusion constraints for each string expression – the constraints are then viewed as a CFG nonterminal for each string-valued expression solved using algorithms based on Earley’s parsing algorithm 3.[Minamide, WWW, ‘05] – analysis of string expressions based on a prior Java string analyzer [Christensen, Moller, Schwartzbach, SAS, ‘03] – instead of transforming the extracted grammar into a regular grammar, they use trancuders to define a CFG 4.[Doh, Kim, Schmidt, SAS, ‘09] Abstract parsing – strengthens the above by statically computing an abstract parse stack in an LR(k) grammar for each security-relevant string – abstract parse stacks retain structural information about dynamically generated strings – parse stacks can be checked by a tainting analysis or for inclusion in a reference grammar to detect attacks 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 16

17. our intuition about existing work: – does not yet support sufficiently powerful dynamic checks to achieve this – common inadequacy -- conditional branching treated as non- determinism – need rewriter to generate meaningful guard instructions 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 17 eval() S OLUTION D IRECTIONS if (guard) then s1 else s2 current static analysis: eval (s1 s2) we need: {guard}eval(s1){…} or {~guard}eval(s2){…}

18. eval() SOLUTION DIRECTIONS certifying IRM’s potentially better suited to addressing this problem than purely static analyses – IRM can put in dynamic checks if static analysis is not powerful enough certifier must be sufficiently powerful – allow effective, flexible, yet provably sound rewriting for these domains – code point where the static analysis conservatively rejects must be a way to transform code to include a statically verifiable dynamic check check conditionally preserves or prohibits unverifiable behavior 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 18

19. possible solution -- dependently typed string analysis with reconstructed types – test criteria of conditional branches incorporated into reconstructed types type-checking need not be complete for effective IRM certification – need only support a sufficiently powerful set of conditional tests so that rewriters have useful options for inserted guards eval() S OLUTION D IRECTIONS

20. Concurrency standard IRM technique to enforce a resource-bound policy on a security-relevant resource: – rewriter replaces use_resource() with: if (count < limit) { use_resource(); count := count + 1; } not sufficient to prevent policy-violations in concurrent env IRM must add some form of synchronization, na ї ve solution: – surround guard code with lock-acquire/ lock-release unreasonably expensive when bounded resource is asynchronous (I/O) extremely common situation -- real-world IRM systems frequently implement a variety of complex, non-standard synchronization strategies in rewritten code (c.f. Racer [Bodden, Havelund, ISSTA, ‘08] ) – global lock hash table 1/29/201120 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification count -- state variable introduced by the rewriter to track a conservative approximation of the security-relevant event history

21. Concurrency P RIOR W ORK S URVEY large body of work on AOP dynamic detection of race conditions and deadlocks (e.g., [Artho, Havelund, Biere, VVEIS, ‘03], [Bensalem, Havelund, Haifa Verif. Conf., ‘05], [Havelund, SPIN, ‘00] ) some work done on dynamic detection of race conditions using aspects (c.f. Racer [Bodden, Havelund, ISSTA, ‘08] ). – neat separation of concerns – more hope for certifying that the instrumented code satisfies the security policy concurrency issues handled by certifying IRM’s – those that enforce purely non-temporal policies e.g., SFI [McCamant, Morrisett], NaCL [Yee et al] ) can safely ignore the concurrency issue because they need not maintain a history of security-relevant events – those that do enforce temporal properties: Mobile [Hamlen, Morrisett, Schneider] supports only one form of synchronization implemented as a trusted library ConSpec [Aktug, Naliuka], [Sridhar, Hamlen, VMCAI, ‘10] leave concurrency to future work 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 21

22. Need spec language that – is precise – is flexible enough to admit many (efficient) IRM implementations – is amenable to automated certification of these implementations to our knowledge no previous work does that building such a certifier would involve answering two major questions – What are the right implementation-level synchronization primitives? – What are the right policy-level temporal operators? 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 22 Concurrency S OLUTION D IRECTIONS

23. How should we specify security policies that involve potentially asynchronous, security-relevant events? canonical example: no-network-sends-after-file-reads non-atomic, possibly asynchronous operations the policy must specify which inter-leavings are permissible – temporal notion of “after” ambiguous in concurrent setting E.g. Thread A begins sending, then Thread B begins reading while A is still sending. Is this a send "after" a read? – fine-grained nuances must be expressible formulate policies in a way that does not impose undue performance overhead for self-monitoring code 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 23 Guiding Example

24. Group 1 : abstract concurrent policy specification languages – e.g. Pi-Calculus [Milner] – expressive modular fine-grained concurrency specifications [Jacobs & Piessens, POPL ‘11] (separation logic) – suitable framework for defining a good synchronization primitives language Group 2: practical tools – aspect-oriented temporal assertions [Stolz, Bodden, ENTCS, ‘06] runtime verification framework for Java programs, properties can be specified in LTL over AspectJ pointcuts – tracematching [Allan et al., OOPSLA, ‘05], and applications for race detection enhanced with Racer [Bodden, Havelund, ISSTA, ‘08] would allow for maintaining history in the presence of concurrent events – useful concurrent IRM implementation strategies -- future work should pair with corresponding static certification strategies 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 24 Concurrency P RIOR W ORK S OLUTIONS

25. Transparency proving semantic-preservation of policy-satisfying code most certifying IRM systems exclusively focus on proving soundness of rewritten code transparency failures often deemed less severe than policy violations – mission-critical applications  non-transparency = denial-of-service formal, automated certification of transparency valuable contribution to the field 1/29/201125 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

26. Transparency P RIOR W ORK expressed as equivalences classes of programs [Hamlen, Morrisett, Schneider, TOPLAS, ‘06] – equivalence relation denotes semantic equivalence – transparency demands rewriter closure over equivalence relation – equivalence relation left abstract transparency for an IRM that enforces information flow properties [Chudnov, Naumann, CSF, ‘10] – first formal proof of transparency for a real IRM – equivalence relation in terms of program input-output pairs – manual proof of transparency of rewriting algorithm – specific to one particular language and rewriting algorithm 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 26

27. Transparency S OLUTION D IRECTIONS many complex systems -- behavior not precisely characterizable in terms of input-output – semantic equivalence definition very difficult e.g. possible to encode unique behaviors as unique types (e.g., TIL [Tarditi, Morrisett, Cheng, Stone, Harper, Lee] ), – resulting equivalence relation too strict – precludes most IRM’s that enforce history-based access-control policies need equivalence relation that distinguishes between – code-transformations that affect only policy-violating program behaviors – and those that potentially affect even policy-satisfying behaviors – former should be accepted by a transparency-certifier, latter shouldn’t 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 27

28. Type-checking program-equivalence [Jia, Zhao, Sjoberg, Weirich, POPL, ‘10] – dependently typed language – doesn’t need decidable type-checking, decidable program equivalence – type system parametrized by abstract relation isEq( Δ, e, e ′ ) – relation holds when e and e ′ are semantically equivalent in a context of assumptions about the equivalence of terms Kripke logical relations [Hur & Dreyer, POPL ’11] – traditional contextual equivalence relations don’t work well for low- level code equivalent functions return the same values in equivalent contexts – low-level contexts are too specific – Example: self-decrypting binary code 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 28 Transparency S OLUTION D IRECTIONS

29. Conclusion hybrid static-dynamic monitoring extremely powerful – power & flexibility of dynamic monitoring – strong formal guarantees of purely static analysis – static certification of IRM systems emerging challenge Part II – motivating discussions on what’s been done already Part III -- three outstanding problems faced by developers of IRM systems today – IRM certification in the presence of runtime code generation(e.g., eval) – certification of concurrent IRM code – certification of behavior-preservation 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 29

30. References 1.I. Aktug and K. Naliuka. ConSpec - a formal language for policybspecification. Science of Computer Programming, 74:2–12, 2008. 2.C. Allan, P. Avgustinov, A. S. Christensen, L. Hendren, S. Kuzins, O. Lhot´ak, O. de Moor, D. Sereni, G. Sittampalam, and J. Tibble. Adding trace matching with free variables to AspectJ. In Proc. ACM Conf. on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), pages 345–364, 2005. 3.L. Bauer, J. Ligatti, and D. Walker. Composing security policies with Polymer. In Proc. ACM Conf. on Programming Language Design and Implementation (PLDI), pages 305–314, 2005. 4.U. Erlingsson and F. B. Schneider. SASI enforcement of security policies: A retrospective. In Proc. New Security Paradigms Workshop (NSPW), 1999. 5.K. W. Hamlen, G. Morrisett, and F. B. Schneider. Computability classes for enforcement mechanisms. ACM Transactions on Programming Languages and Systems, 28(1):175–205, 2006. 6.K. W. Hamlen, G. Morrisett, and F. B. Schneider. Certified in-lined reference monitoring on.NET. In Proc. ACM Workshop on Programming Languages and Analysis for Security (PLAS), pages 7– 16, 2006. 7.S. H. Jensen, A. Møller, and P. Thiemann. Type analysis for JavaScript. In Proc. Int. Static Analysis Symp. (SAS), pages 238–255, 2009. 8.L. Jia, J. Zhao, V. Sj ¨oberg, and S. Weirich. Dependent types and program equivalence. In Proc. ACM Symp. on Principles of Programming Languages (POPL), pages 275–286, 2010. 9.M. Kim, S. Kannan, I. Lee, and O. Sokolsky. Java-MaC: A run-time assurance tool for Java programs. In Proc. Int. Workshop on Runtime Verification (RV), 2001. 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 30

31. References Contd. 1.G. C. Necula. Proof-Carrying Code. In Proc. ACM Symp. on Principles of Programming Languages (POPL), pages 106–119, 1997. 2.G. Richards, S. Lebresne, B. Burg, and J. Vitek. An analysis of the dynamic behavior of JavaScript programs. In Proc. ACM Conf. on Programming Language Design and Implementation (PLDI), pages 1–12, 2010. 3.F. B. Schneider. Enforceable security policies. ACM Transactions on Information and Systems Security, 3(1):30–50, 2000. 4.M. Sridhar and K. W. Hamlen. ActionScript in-lined reference monitoring in Prolog. In Proc. Int. Symp. on Practical Aspects of Declarative Languages (PADL), pages 149–151, 2010. 5.M. Sridhar and K. W. Hamlen. Model-checking in-lined reference monitors. In Proc. Int. Conf. on Verification, Model-Checking and Abstract Interpretation (VMCAI), pages 312–327, 2010. 6.V. Stolz and E. Bodden. Temporal assertions using AspectJ. Electronic Notes in Theoretical Computer Science, 144(4):109–124, 2006. 7.D. Tarditi, G. Morrisett, P. Cheng, C. Stone, R. Harper, and P. Lee. TIL: A type-directed optimizing compiler for ML. In Proc. ACM Conf. on Programming Language Design and Implementation (PLDI), pages 181–192, 1996. 8.P. Thiemann. Grammar-based analysis of string expressions. In Proc. ACM Int. Workshop on Types in Languages Design and Implementation (TLDI), pages 59–70, 2005. 9.J. Viega, J. Bloch, and P. Chandra. Applying aspect-oriented programming to security. Cutter IT Journal, 14(2), 2001. 10.B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Ormandy, S. Okasaka, N. Narula, and N. Fullagar. Native Client: A sandbox for portable, untrusted x86 native code. In Proc. IEEE Symp. on Security and Privacy (S&P), pages 79–93, 2009. 1/29/2011 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification 31