Flexible In-lined Reference Monitor Certification: Challenges and Future Directions Meera Sridhar and Kevin W. Hamlen University of Texas at Dallas January

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)



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]



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



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)



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-


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



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



12

Part III Three prominent, challenging, unsolved problems in the IRM certification domain.

eval()concurrencytransparency



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



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



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){…}


• 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



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


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

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



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?



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



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



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



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



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



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



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



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.


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.


Documents

Flexible In-lined Reference Monitor Certification: Challenges and Future Directions Meera Sridhar and Kevin W. Hamlen University of Texas at Dallas January