Flexible In-lined Reference Monitor Certification: Challenges and Future Directions

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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

3. Reference Monitors (not in-lined) • 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” OS/VM Reference Monitor event grant/deny untrusted code Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

4. In-lined Reference Monitors [Schneider, TISSEC, ‘00] • enforce safety policies by injecting runtime security guards into untrusted binaries • 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: • enforce richer policies: e.g., no network sends after file reads • sufficient to enforce safety, some liveness • more powerful than purely static analysis • No need to modify the OS/VM • 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] OS/VM Reference Monitor grant/deny event untrusted code Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

5. In-lined Reference MonitorExample Policy: no sends after reads untrusted BINARY code rewritten binary code b := false; ... call Read; b := true; ... if b then halt; call Send; ... ... call Read; ... call Send; ... Rewriter Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

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) Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

7. IRM Certification untrusted code policy Rewriter verifier reject (rewriter failure) 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) execute rewritten code Trusted Computing Base Sridhar and Hamlen: Model-Checking In-lined Reference Monitors

8. Certifiying IRMsA New Problem Domain • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

9. Policy Specification LanguagesApproach 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]) Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

10. Approach 1 A policy in Conspec 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

11. Policy Specification Languages A Better Approach • specify policies purely declaratively • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

12. Certifying IRMsRelated Work Survey • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

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

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; } Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

15. eval()Verification Challenge • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

16. eval()Prior Work • [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 • [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 • [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 • [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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

17. eval()Solution Directions • 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 if (guard) then s1 else s2 current static analysis: eval (s1 s2) we need: {guard}eval(s1){…} or {~guard}eval(s2){…} Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

19. eval()Solution Directions • 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

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 • count -- state variable introduced by the rewriter to track a conservative approximation of the security-relevant event history Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

21. ConcurrencyPrior Work Survey • 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 ofsecurity-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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

22. ConcurrencySolution Directions • 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? Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

23. Guiding Example 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

24. Concurrency Prior Work Solutions 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 AspectJpointcuts • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

26. TransparencyPrior Work • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

27. TransparencySolution Directions • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

28. TransparencySolution Directions • 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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

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 Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

30. References • I. Aktug and K. Naliuka. ConSpec - a formal language for policybspecification. Science of Computer Programming, 74:2–12, 2008. • 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. • 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. • U. Erlingsson and F. B. Schneider. SASI enforcement of security policies: A retrospective. In Proc. New Security Paradigms Workshop (NSPW), 1999. • 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. • 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. • S. H. Jensen, A. Møller, and P. Thiemann. Type analysis for JavaScript. In Proc. Int. Static Analysis Symp. (SAS), pages 238–255, 2009. • 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. • 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. Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification

31. References Contd. • G. C. Necula. Proof-Carrying Code. In Proc. ACM Symp. on Principles of Programming Languages (POPL), pages 106–119, 1997. • 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. • F. B. Schneider. Enforceable security policies. ACM Transactions on Information and Systems Security, 3(1):30–50, 2000. • 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. • 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. • V. Stolz and E. Bodden. Temporal assertions using AspectJ. Electronic Notes in Theoretical Computer Science, 144(4):109–124, 2006. • 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. • 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. • J. Viega, J. Bloch, and P. Chandra. Applying aspect-oriented programming to security. Cutter IT Journal, 14(2), 2001. • 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. Sridhar and Hamlen: Flexible In-lined Reference Monitor Certification