Flexible In-lined Reference Monitor Certification: Challenges and Future Directions Meera Sridhar...
-
Upload
flora-jenkins -
Category
Documents
-
view
216 -
download
2
Transcript of Flexible In-lined Reference Monitor Certification: Challenges and Future Directions Meera Sridhar...
Flexible In-lined Reference Monitor Certification:
Challenges and Future Directions
Meera Sridhar and Kevin W. HamlenUniversity of Texas at Dallas
January 29, 2011
Supported by a grant from AFOSR
PLPV 2011Austin, TX
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
2
Reference Monitors (not in-lined)
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
3
OS/VM
REFERENCE MONITOR
grant/denyevent
Examples: file system permissionsmemory safety
Disadvantages:
— changing the policy requires changing the OS/VM
— Example: On Windows, enforce
“applications cannot create files ending in .exe”UNTRUSTED CODE
In-lined Reference Monitors [Schneider, TISSEC, ‘00]
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
4
OS/VM
REFERENCE MONITOR
grant/denyevent
UNTRUSTED CODE
enforce safety policies by injecting runtime security guards into untrusted binarieso 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 readso sufficient to enforce safety, some
livenesso 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]
In-lined Reference MonitorEXAMPLE
1/29/2011Sridhar 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 code rewritten binary code
Rewriter
...call Read;...call Send;...
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
6
IRM Certification
1/17/2010Sridhar and Hamlen: Model-Checking In-lined Reference
Monitors7
REWRITER
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
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
1/29/2011Sridhar and Hamlen: Flexible In-lined
Reference Monitor Certification8
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])
1/29/2011 9Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
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 PERFORMtrue -> {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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
10
• 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 BETTER APPROACH
specify policies purely declaratively
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
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
12
Part III Three prominent, challenging, unsolved problems in the IRM certification domain.
eval()concurrencytransparency
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
13
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/201114
Sridhar and Hamlen: Flexible In-lined Reference Monitor
Certification
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
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
15
eval()PRIOR WORK1. [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 attacks1/29/2011
Sridhar and Hamlen: Flexible In-lined Reference Monitor
Certification16
• 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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
17
eval()SOLUTION DIRECTIONS
if (guard) then s1 else s2
current static analysis:
eval (s1 s2)we need:
{guard}eval(s1){…} or {~guard}eval(s2){…}
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
18
• 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()SOLUTION DIRECTIONS
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/2011 20Sridhar 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
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 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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
21
• 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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
22
ConcurrencySOLUTION DIRECTIONS
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
23
Guiding Example
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
24
ConcurrencyPRIOR WORK SOLUTIONS
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/2011 25Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
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
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
26
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
1/29/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
27
• 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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
28
TransparencySOLUTION DIRECTIONS
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/2011Sridhar and Hamlen: Flexible In-
lined Reference Monitor Certification
29
References1. 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
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