Survey on Runtime Monitoring based on Formal Specification WPE-II Presentation By Usa Sammapun Oct 28, 2005

Survey on Runtime Monitoringbased on Formal Specification

WPE-II Presentation

By

Usa Sammapun

Oct 28, 2005

Software Programs

Heart Device

Car

Aircraft

ATM

Safe Programs ??

Safe Programs

Verification

Security

Program Development

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

all-leg-down!walk

leg1-up, leg4-upwalk & !fall

leg2-up, leg3-upwalk & !fall

leg1-up, leg2-upwalk & fall

walk and not fallRequirement

Model

Implementation

Program Safety Techniques

Implementation

ModelModel Checking

Model Carrying Code

Runtime Monitoring

Requirement

Goal: Ensuring that implementation satisfies requirement

Model Carrying Code

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

Runtime Monitoring

Programs

Instru

men

tation

Monitor

Trace Extraction

Feedback

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); }}

leg1 leg2 leg3 leg4

Satisfied

Not Satisfied

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

Outline




Comparison and Analysis Conclusion

Temporal Assertions using AspectJ (SB’05)

Specification Language: LTL Spec Evaluation Process: Alternating

Automata Instrumentation:

Automatic: AspectJ Bytecode

Feedback: AspectJ

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 | f1 U f2 | f1 R f2

Next Eventually Always Until

Proposition

Release

LTL

f

f

f f f f f f

f1 f1 f1 f1 f2

○f -- Next

◊ f -- Eventually f ν ○(◊f)

□ f – Always (Global) f ∧ ○(□f)

f1 U f2 -- Until f2 ν (f1 ∧ ○(f1 U f2))

f2 f2 f2 f2 f1

f1 R f2 -- Release f2 ∧ (f1 ν ○(f1 R f2))

f2 f2 f2 f2 f2 f2

LTL

◊ f = true U f

□ f = false R f

Concise Syntax f :: = p | ¬ f | f1 ∧ f2 | f1 ν f2

| X f | f1 U f2 | f1 R f2

true true true true f

f f f f f f

f f f f false

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

AFA

s1

s2

s3

s4

s5

s6

s7

s8

s9

s10

On input a : T(s1, a) = {s2, s5, s8, s9}

NFA: Accept - automata: Reject AFA: Depends

s1

s2

s3

s4s9

s8

s5

AFA = (, 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

a

a

a

AFA Formally, AFA = (, S, s0, T, F) T: S x 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

AFA A run r’ of NFA is linear because you only choose one path A run r of AFA is a tree

For disjunction, you choose one path For conjunction, you have to take all paths

A run r 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

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, s0, T, F) = 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

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(f1 U f2, Prop) = T(f2, Prop) ν (T(f1, Prop) ∧ (f1 U f2)) T(f1 R f2, Prop) = T(f2, Prop) ∧ (T(f1, Prop) ν (f1 R f2))

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

Leg

void kick()void move()void stop()

Head

void look()void move()void stop()

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

Aspect Pointcut Advice

SB’05 Instrumentation / Feedback: AspectJ

AspectJ

LTL formulae are transformed into an aspect Pointcut as propositions

Advice: AFA takes transitions and checks a trace

requiresInit() shall not be called unless init() has been called prior

(!call(requiresInit())) U (call(init())

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

advice

AspectJ

declaration

Overall Architecture – Instrumentation

Specification p1 U p2...

AspectJaspect F1 {...AFAtransition

InstrumentedJava bytecode

if(!p1) notify{...

Compiler Weaving

CodeGen

Outline





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

Eagle Language

Illustrated by an example LTL

Next ○ is built-in syntax

max Always(Form F) = F ∧ ○ Always(F)

min Eventually(Form F) = F ν ○ Eventually(F)

min Until(Form F1, Form F2) = F2 ν (F1 ∧ ○ Until(F1, F2))

mon M1 = Always(x > 0 Eventually(y > 0))

Evaluate to true at the end of the

trace

Evaluate to false at the end

of the trace

Rules

Properties

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*

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

min EventAbs(Form F, float t1, float t2) =

(F ∧ t1 ≤ clock ∧ clock ≤ t2) ν

((clock < t1 ν ( ¬F ∧ clock ≤ t2)) ∧ ○ EventAbs(F,t1,t2))

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(F1 op 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

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

Eagle Instrumentation/Feedback

No instrumentation & Feedback

Need a third-party program to supply an execution trace

Outline





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

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

Edit Automata

app’s requested action

executed action: allowed, inserted

Example: Atomicity Program: Apple Market-Client Policy: Atomicity Apple Market

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. ¬p1 U p2

Polymer is a prototype language based on Policy Calculus for monitoring Java programs Analogous to Until( Not(p1), p2);

Policy Calculus

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

Policy: Memory quota

Polymer

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 actionsVariables

Policy

Policy: Limit # of opened files and its path

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

Outline





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

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 max Attack() = (type = “ping”) ∧ isBroadcast(ip) mon DoSSafety = Always(¬ Attack())

Summary

Language Spec Evaluation

Instrument Feedback

SB’05 LTL Alternating Automata

AspectJ: Automatic, Bytecode

AspectJ, User-defined

Eagle Eagle (LTL, Regular Expression, MTL, Context Free language)

Direct Algorithm - -

Edit Automata

Security Policies DFA – Edit Automata

Method wrapper:

Manual, Sourcecode

Fixed: suppress,

insert, halt

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

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 (2m) the length of the trace

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

Why Eagle general checking time depends on length of trace Ex. “whenever at some point x > 0, then eventually y = x".

Eagle: min R(int k) = Eventually(y = k) mon M = 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))

Other Runtime Monitoring

Various Specification Language LTL, MTL, regular expression, Real-Time Logic,

Timed-LTL, probabilistic, etc… Multithreaded and Distributed Monitoring Toward First-Order Logics

Conclusion

Runtime monitoring based on formal specification Runtime verification

SB’05 checking LTL using AspectJ Eagle checking LTL, MTL, RE, no instrumentation

Security Edit Automata enforcing security policies Eagle for signature-based intrusion detection

Discussion

Reference [Eagle]

Howard Barringer, Allen Goldberg, Klaus Havelund and Koushik Sen. Rule-Based Runtime Verification. In Proceedings of the 5th International Conference on Verification, Model Checking, and Abstract Interpretation, 2004

[SB05] Volker Stolz and Eric Bodden. Temporal Assertions using AspectJ. In

Proceedings of the 5th International Workshop on Runtime Verification, 2005 [Edit Automata]

Jay Ligatti, Lujo Bauer, and David Walker. Edit Automata: Enforcement Mechanisms for Run-time Security Policies. Technical report, Princeton University, Computer Science Department, May 2003.

[Intrusion Detection] Prasad Naldurg, Koushik Sen, and Prasanna Thati. A Temporal Logic Based

Approach to Intrusion Detection. In Proceedings of the International Conference on Formal Techniques for Networked and Distributed Systems (FORTE 2004), 2004.

Q & A

Q: Eagle Toward CFL

Eagle also provide concatenation F :: = expression | true | false

| ¬F | F1 ∧ F2 | F1 ν F2 | F1 F2

| ○F | N(F1, …, Fn) | xi | F1 · F2

Example: match a sequence of login, logout Define a rule Match, and monitor Match(login,logout)

min Match(Form F1, Form F2) =

F1 · Match(F1,F2) · F2 · Match(F1,F2) ν Empty()

max Empty() = ¬○ trueTrue when evaluated on an

empty (suffix) sequence

Q: Eagle Regular Expression Eagle also provide concatenation

F :: = expression | true | false | ¬F | F1 ∧ F2 | F1 ν F2 | F1 F2

| ○F | N(F1, …, Fn) | xi | F1 · F2

E ::= Ø | | a | E · E | E + E | E* Write each syntax using Eagle formula

Let Tr(E) denote the regular expression E’s corresponding Eagle Formula

max Empty() = ¬○ true

Tr(Ø) = falseTr() = Empty()Tr(a) = a ∧ ○Empty()Tr(E1 · E2) = Tr(E1) · Tr(E2)Tr(E1 + E2) = Tr(E1) ν Tr(E2)Tr(E*) = X() where max X() = Empty() ν (Tr(E) · X())

Example: a* · (b + c) mon M = AStar() · (b ν c) max AStar() = Empty() ν (a · AStar())

True when evaluated on an empty (suffix) sequence

Q: Eagle -Calculus

Eagle can be use to specify -Calculus

Example -Calculus

x. (p ○○∧ x ∧ y.( q ○∧ x)) Eagle

max X() = p ∧ ○○X() ∧ Y()

min Y() = q ∧ ○X()

Q: LTL AFA Example

true

false

false R p

(false R p) U q

T((false R p),{p})

T(q,{p})

T(p,{p})

(false R p) U q

false R p

{p}

{p}{p}

{p}

{p}

{p}

{p}

T(p, Prop) = true if p Prop T(p, Prop) = false if p Prop

T(f1 U f2, Prop) = T(f2, Prop) ν (T(f1, Prop) ∧ (f1 U f2))

T(f1 R f2, Prop) = T(f2, Prop) ∧ (T(f1, Prop) ν (f1 R f2))

= (T(f2, Prop) ∧ T(f1, Prop)) ν (T(f2, Prop) ∧(f1 R f2))

= (T(p, {p}) ∧ T(false, {p})) ν (T(p, {p}) ∧(false R p))

Q: Eagle Eval Example The result of eval function is a new set of formulae to be held in the next state

eval( Always(x > 0 Eventually(y > 0)), s ) eval( (x > 0 Eventually(y > 0)) ∧ ○Always(x > 0 Eventually(y > 0)), s ) eval( x > 0 Eventually(y > 0), s ) ∧

eval( ○Always(x > 0 Eventually(y > 0)), s ) ( eval( x > 0, s ) eval( Eventually(y > 0), s ) ) ∧ Always(x > 0 Eventually(y > 0)) (x > 0 eval( (y > 0) ν ○Eventually(y>0), s) ) ∧ Always(x > 0 Eventually(y > 0)) (x > 0 ( eval(y > 0, s) ν eval( ○Eventually(y>0), s ) ) ) ∧ Always(x > 0 Eventually(y > 0)) (x > 0 (y > 0 ν Eventually(y>0))) ∧ Always(x > 0 Eventually(y > 0))

Q: Eagle Eval Example (continue..) The result of eval function is a new set of formulae to be held in the next

state

(x > 0 (y > 0 ν Eventually(y>0))) ∧ Always(x > 0 Eventually(y > 0))

If state s = { x = -1, y = 0}, then (false (false ν Eventually(y >0))) ∧ Always(x > 0 Eventually(y > 0)) true ∧ Always(x > 0 Eventually(y > 0)) Always(x > 0 Eventually(y > 0))

If state s = { x = 1, y = 0}, then (true (false ν Eventually(y >0))) ∧ Always(x > 0 Eventually(y > 0)) (false ν Eventually(y >0)) ∧ Always(x > 0 Eventually(y > 0)) Eventually(y >0) ∧ Always(x > 0 Eventually(y > 0))

Q: Eagle Execution Time – Depending on Trace Length Ex. “whenever at some point x = k > 0 for some k, then eventually y = k".

Eagle: min R(int k) = Eventually(y = k) mon M = 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))

Q: Overhead

Instrumentation Depending on how often the extraction is

Evaluation Process Depending on the specification language

Q: Multithreaded and Distributed Monitoring Multithreaded

Formula on shared variables Thread T1 { … x++; … y = x+1; … } Thread T2 { … z = x+1; … x++; … } (x > 0) [ (x = 0), y > z)

Distributed No shared variables, only asynchronous messages Operator @: evaluate a formula in the last known state of a remote process Ex. “the server accepts the command to reboot only after knowing that each

client is inactive and aware of the warning about pending reboot” Local to server rebootAccepted ∧client (@client (inactive ∧ @server rebootWarning))

Q: Actual Eagle LTL Checking Time Time: O(m4 22m log2m)

Transforming an LTL f to another LTL f’ to hold in the next state Assume | f | = m

f has m subformulae

Space: The size of the LTL f’ can be O(2m)

There are at most 2m possibilities to combine them in a conjunction or disjunction Space requirement for each conjunction is O(m2 log m) Hence, space complexity is O(m2 2m log m)

Time: At each node, it can possibly spend O(m2 2m log m) time to do conjunction and

disjunction Since the space complexity is O(m2 2m log m), the time complexity is O(m2 2m log m) x

O(m2 2m log m) = O(m4 22m log2 m)

Q:

Placement of Specification Language All: Separate entities

Modular If embedded within the specification language

For example, specification is embedded as comments, which require a special compiler

Documents

Survey on Runtime Monitoring based on Formal Specification WPE-II Presentation By Usa Sammapun Oct 28, 2005