Survey on Runtime Monitoring based on Formal Specification

1. Survey on Runtime Monitoringbased on Formal Specification WPE-II Presentation By Usa Sammapun Oct 28, 2005

2. Software Programs Car ATM Heart Device Aircraft

3. Safe Programs ??

4. Safe Programs Verification Security

5. all-leg-down !walk leg2-up, leg3-up walk & !fall leg1-up, leg4-up walk & !fall leg1-up, leg2-up walk & fall Program Development Model walk and not fall Requirement class AIBO { Leg leg1,leg2,leg3,leg4; main() { leg1 = new Leg(1); leg2 = new Leg(2); leg3 = new Leg(3); leg4 = new Leg(4); } } class Leg { void walk() { } void stop() { } } Implementation

6. Program Safety Techniques Goal: Ensuring that implementation satisfies requirement Model Model Checking Model Carrying Code Requirement Model Carrying Code Runtime Monitoring Implementation

7. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Discussion • Conclusion

8. leg1 leg2 leg3 leg4 Programs Instrumentation Runtime Monitoring Formal Specification class AIBO { Leg leg1,leg2,leg3,leg4; main() { leg1 = new Leg(1); send(checker,leg1); leg2 = new Leg(2); send(checker,leg2); leg3 = new Leg(3); send(checker,leg3); leg4 = new Leg(4); send(checker,leg4); } } class Leg { void walk() { send(checker,walk); } void stop() { send(checker,stop); } } Monitor Satisfied Trace Extraction Not Satisfied Feedback

9. Runtime Monitoring • Formal specification language • Based on Mathematics • Logics, Automata, Calculi • Instrumentation • Manual & Automatic • Bytecode & Sourcecode • Specification Evaluation Process • Transform spec language into a checking automaton • Takes a trace as an input • Returns result: Satisfied, Not Satisfied • Direct algorithm • Takes both spec language and a trace as inputs • Returns result: Satisfied, Not Satisfied • Feedback • Optional • Fixed or user-defined

10. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

11. Temporal Assertions using AspectJ (SB’05) • Specification Language: LTL • Spec Evaluation Process: Alternating Automata • Instrumentation: • Automatic: AspectJ • Bytecode • Feedback: AspectJ

12. SB’05 Language • LTL – Linear Temporal Logic • Reason about time-dependent truth value • Classical: 1 < 2 • Temporal: it’s raining • Syntax • f :: = p | ¬ f | f1∧f2 | f1 νf2 | ○f | ◊f | □f | f1Uf2 | f1Rf2 Proposition Next Eventually Always Until Release

13. f2 f f2 f1 f f f2 f2 f1 f2 f2 f1 f f2 f f2 f1 f2 f2 f f f1 f f2 LTL ○f -- Next ◊f -- Eventually  fν○(◊f) □f – Always (Global)  f∧○(□f) f1U f2 -- Until  f2ν(f1∧○(f1Uf2)) f1R f2 -- Release  f2∧(f1ν○(f1Rf2))

14. true f f f true f true f f true f f false f f f LTL • ◊f = true Uf • □f = false Rf • Concise Syntax • f :: = p | ¬ f | f1∧f2 | f1 νf2 | Xf | f1Uf2 | f1Rf2

15. SB’05 Spec Evaluating Process • Translate LTL formulae to Alternating Automata • Use Alternating Automata to check a trace • Alternating Finite Automata (AFA) • Generalization of Non-deterministic Finite Automata (NFA) • NFA – existential automaton • -automaton • A combination of both

16. AFA s5 s5 • On input a : T(s1, a) = {s2, s5, s8, s9} • NFA: Accept • - automata: Reject • AFA: Depends e s6 s2 s2 a e s7 s1 s1 s3 s3 a e s8 s8 e s4 s4 a s9 s9 s10 • AFA = (S, S, s0, T, F) • The only difference from NFA is the transition function • TNFA(s1, a) = {s2, s5, s8, s9} = s2 νs5ν s8 νs9 • TAFA(s1,a) = (s2 νs5) ∧ (s8 νs9) • Choose to go to {s5, s9}, then accept • TAFA(s1,a) = s2 ∧ (s5ν s8 νs9) • Reject, no matter what you choose

17. AFA • Formally, AFA = (S, S, s0, T, F) • T: S x S B+(S) • B+(S) is a set of positive Boolean formulae over S • Positive Boolean Formulae: Boolean formulae built from elements in S using ∧ and ν • We say a set S’ satisfies a positive Boolean formula f in B+(S) if the truth assignment assigns true to S’ and false to S-S’ • For example, • the set S’ = {s5, s9} satisfies the formula f = (s2 ν s5) ∧ (s8 ν s9) • the set S’ = {s2, s5} does not satisfy f

18. AFA • A runr’ of NFA is linear because you only choose one path • A runr of AFA is a tree • For disjunction, you choose one path • For conjunction, you have to take all paths • A runr of AFA on a finite word w = a1, a2, …, an is a finite tree such that • if s is a node in the tree r and T(s, ai) = f, where f is positive Boolean formula • then s has k children for some k ≤ |S|, and {s1, s2, …, sk} satisfies f • Transition therefore determines what are possible next states • TAFA(s1,a) = (s2 νs5) ∧ (s8 νs9) • Possible states are {s2,s8}, {s2, s9}, {s5,s8}, {s5,s9} • E.g., you can’t go to state {s2,s5} • AFA accepts a run r if all leaves of a run r are final states s1 s5 s9

19. Translation: LTL  AFA • Translating an LTL formula fto an AFA Af • Af accepts, then f satisfies • Af rejects, then f doesn’t satisfy • Af= (S, S, s0, T, F) • S = a set of propositions in f • S = all sub-formulae of fand true, false • s0 = original formula f • F = all formulae in S of the form (f1R f2) and true • T  next slide

20. Translation: LTL  AFA • States: Formulae, sub-formulae, true, false • Transition: T(state, input) = state • T(p, Prop) = true if p Prop • T(p, Prop) = false if p Prop • T(¬p, Prop) = true if p Prop • T(¬p, Prop) = false if p Prop • T(true, Prop) = true • T(false, Prop) = false • T(f1νf2, Prop) = T(f1 ,Prop) ν T(f2 ,Prop) • T(f1∧f2, Prop) = T(f1 ,Prop) ∧ T(f2 ,Prop) • T(Xf, Prop) = f • T(f1Uf2, Prop) = T(f2, Prop) ν(T(f1, Prop) ∧ (f1Uf2)) • T(f1Rf2, Prop) = T(f2, Prop) ∧(T(f1, Prop) ν(f1Rf2))

21. SB’05 Evaluation Summary • Given an LTL formula and an execution trace (set of propositions) • LTL f is translated into AFA Af • Af checks an execution trace • At anytime, if transit to the state • true, satisfied • false, falsified • At the end of the trace, • If at final state, satisfied • Otherwise, falsified

22. Head Leg void look() void move() void stop() void kick() void move() void stop() SB’05 Instrumentation / Feedback: AspectJ • At move and stop, create a log file or calculate safe location • AspectJ helps you modularize by writing once: specify • Where to do operations • What kind of operations • Pointcut  Advice Aspect

23. requiresInit() shall not be called unless init() has been called prior (!call(requiresInit())) U (call(init()) AspectJ • LTL formulae are transformed into an aspect • Pointcut as propositions • Advice: AFA takes transitions and checks a trace

24. AspectJ aspect InitPolicy { pointcut p1(): call(requiresInit()); pointcut p2(): call(init()); int p1 = 1; int p2 = 2; Formula state = Until( Not(p1), p2); Set<int> currentPropositions = new Set<int>(); after(): p1() { currentPropositions.add(p1); } after(): p2() { currentPropositions.add(p2); } after(): p1() || p2() { state = state.AFAtransition(currentPropositions); if (state.equals(Formula.True)) { // report the formula as satisfied } else if (state.equals(Formula.False)) { // report the formula as falsified } currentPropositions.clear(); // reset proposition vector } } pointcut declaration advice

25. Overall Architecture – Instrumentation Specification p1 U p2... Compiler AspectJ aspect F1 {... AFAtransition Weaving Instrumented Java bytecode if(!p1) notify{... CodeGen

26. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

27. EAGLE • Specification Language: Eagle • Specification Evaluation: Direct algorithm • Instrumentation: - • Feedback: - • Motivated by the need for small, general, but powerful framework for specifying languages for runtime monitoring • Eagle can be used to specify LTL, Metric Temporal Logic (MTL), Regular expression, limited form of Context Free language

28. Eagle Language • Illustrated by an example LTL Next ○ is built-in syntax maxAlways(Form F) = F ∧○Always(F) minEventually(Form F) = F ν○Eventually(F) minUntil(Form F1, Form F2) = F2ν (F1 ∧○Until(F1, F2)) monM1 = Always(x > 0 Eventually(y > 0)) Evaluate to true at the end of the trace Rules Evaluate to false at the end of the trace Properties

29. Syntax • R :: = {max | min} N(T1 x1, …, Tn xn) = F • F :: = expression | true | false | ¬F | F1∧F2 | F1ν F2 | F1 F2 | ○F | N(F1, …, Fn) | xi • M ::= mon N = F • S ::= R* M*

30. Metric Temporal Logic (MTL) • Temporal logic parameterized by some clock(s) • Ex. ◊[t1,t2]f • Means that f must hold true sometime when a clock value is between t1 and t2 • Eagle Rule minEventAbs(Form F, float t1, float t2) = (F ∧ t1 ≤ clock ∧ clock ≤ t2) ν ((clock < t1 ν( ¬F ∧clock ≤ t2)) ∧○EventAbs(F,t1,t2))

31. Eagle Spec Evaluation Process • At every state, the runtime monitor evaluates formulae, and generates a new set of formulae to hold in the next state • By using eval function • eval: F x state  F • Its result is a new set of formulae to hold in the next state • eval(true, s) = true • eval(false, s) = false • eval(exp, s) = value of exp in s • eval(¬F, s) = ¬eval(F, s) • eval(F1op F2, s) = eval(F1, s) op eval(F2, s) where op is ∧ ,ν ,  • eval(○F, s) = F • eval(N(F,P), s) = eval(B[f  F, p  P], s) if {max | min} N(Form f,T p) = B

32. Eagle Evaluation Summary • A list of monitored properties • At any time during the trace • The runtime monitor evaluate formulae, and generate a new set of formulae to hold in the next state • If any formula is evaluated to true, that formula is removed from the monitoring list • If any monitor is evaluated to false, a violation is issued • Remaining formulae will be checked at the next state • At the end of the trace • Remaining max rule  evaluate to true • Remaining min rule  evaluate to false

33. Eagle Instrumentation/Feedback • No instrumentation & Feedback • Need a third-party program to supply an execution trace

34. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

35. Edit Automata • A slightly different goal, but similar technique • Goal: run untrusted code without harming our machine • Specification Language & Spec Evaluating Process: • Security Policies is defined in terms of Edit Automata • Edit Automata is a monitor running in parallel with the untrusted program • It monitors the untrusted program and enforces security policies • Instrumentation: • Manual, sourcecode • Feedback: • Feedback (enforcement) is integrated into the language

36. Enforcing Policy in Edit Automata • List of monitored actions or operations • Specify what to do when an application is about to invoke a monitored action • When it recognizes a dangerous action, it may • halt the application • suppress (skip) the operation but allow the application to continue • insert (perform) some computation on behalf of the application

37. Edit Automata app’s requested action executed action: allowed, inserted

38. Example: Atomicity • Program: Apple Market-Client • Policy: Atomicity Apple Market

39. 3 Works on Edit Automata • Edit automaton is a high-level concept for evaluating process with feedback • Analogous to Alternating Automata in SB’05 • Policy Calculus is a language based on the edit automaton concept • Analogous to LTL in SB’05, ex. ¬p1Up2 • Polymer is a prototype language based on Policy Calculus for monitoring Java programs • Analogous to Until( Not(p1), p2);

40. Policy Calculus • Policy: Memory quota fun mpol(quota:int). { actions: malloc(); policy: next  case * of malloc(n)  if (quota > n) then ok; run (mpol (quota-n)) else halt end } List of actions Policy

41. Polymer • Policy: Limit # of opened files and its path policy limitWriter(int maxopen) = actions = { java.io.FileWriter(String path); java.io.FileWriter.close(); } state = { int cur = 0; } policy = { aswitch { case java.io.FileWriter(String path) : if (cur >= maxopen) suppress; if (path.startsWith(``\tmp'')) { cur++; ok; } else { emit(System.err.println(``Can't open.'')); suppress; } case java.io.FileWriter.close() : cur--; } } List of actions Variables Policy

42. Polymer Instrumentation • Method Warpper • All calls (actions) to monitored methods are redirected to the runtime monitor • The runtime monitor then evaluates the action • If ok, the original method call is made and returned • If suppress, it throws a SuppressionException • Program must handle the exception • If insert, it executes inserted operation • If halt, it terminates the program

43. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

44. Intrusion Detection using EAGLE • Intrusion Detection • Anomaly-based • Define normal behaviors • Any behavior deviates from normal behaviors is an intrusion • Signature-based • Define patterns of bad behaviors or attacks • Anything fits the patterns is an intrusion • Naldurg et al. use Eagle • Signature-based Intrusion Detection • Use Eagle to specify attack patterns

45. DoS Attack • Create DoS attack by sending a forged “ping” message with a victim’s IP address as a sender to a broadcast IP address • Large number of response can cause DoS • Eagle • maxAttack() = (type = “ping”) ∧ isBroadcast(ip) • monDoSSafety = Always(¬ Attack())

46. Summary

47. Language • Expressiveness • SB’05 LTL Eagle • Edit Automata DFA Eagle • Abstraction Level • Implementation: SB’05 (pointcut), Edit Automata (Java method call) • Specific particular programming language • Design: Eagle (variable) • General and for any programming language

48. Spec Evaluation Process • Execution time depends on specification language • More expressive, higher complexity • For each input, for a formula f of size m (m subformulae) • Edit Automata: O(m) • DFA • SB05: ≈ O(2m) • Number of states in the AFA Af is O( m ) • SB05 translates AFA (which is essentially NFA) into DFA • Translating NFA into DFA exponentially blows up the number of DFA states • Eagle: • LTL: ≈ O(2m) • Transforming an LTL f to another LTL f’ to hold in the next state • At most 2m possibilities to combine m subformulae in a conjunction or disjunction for f’ • General: (with data-values) depends on both • the size of the formula.. At least W(2m) • the length of the trace

49. Why Checking LTL is ≈ O(2m) • Checking Past-LTL is O(m) • Look at history • Can say satisfied, or not satisfied • Deterministic • Checking Future-LTL is ≈ O(2m) • Waiting for future trace • Cannot say now whether satisfied, or not satisfied • Need to keep track of what we have seen and what we are waiting for • Non-deterministic

50. Why Eagle general checking time depends on length of trace • Ex. “whenever at some point x > 0, then eventually y = x". • Eagle: • minR(int k) = Eventually(y = k) • monM = Always (x > 0 R(x)) • After x becomes > 0 and keeps changing its value, e.g., • s0 = {x = 0, y = 0} • s1 = {x = 1, y = 0} • s2 = {x = 2, y = 0} • s3 = {x = 3, y = 0} • s4 = {x = 4, y = 0} • s5 = {x = 5, y = 0} • s6 = {x = 6, y = 2} • At s6, the result of the eval function (what need to hold next state) becomes • Eventually(y=1) /\ Eventually(y=3) /\ Eventually(y=4) /\ Eventually(y=5) /\ Eventually(y=6) /\ Always(x>0 R(x))