Model checking security properties of Java components Thomas Jensen - PowerPoint PPT Presentation

Model checking security properties of Java components Thomas Jensen IRISA Rennes, France DISPO meeting Ecole des Mines de Nantes 23 September 2004 Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Semantics-based security analysis Verification of software security using static program analysis and model checking. Fundamental question: Is a global security property ensured by a collection of dynamic security checks, inserted into the code? Approach inspired by the Schmidt-Steffen slogan: “Data flow analysis as model checking of abstract interpretations” Concretely, this means: formalise security properties as temporal properties, use abstract interpretation to obtain an abstract, finitary model of the program to be analysed, use model checking to verify properties of this abstraction. Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Software security holes A security hole (now fixed!) in Netscape allowed hostile applet to create illicit network conections and divulge confidential data. OpenConnection(Socket s); class Socket { . try { . close() { checkPermission("open") CloseConnection() ... ... } ... . . . ... Applette hostile : } catch (SecurityException) class EvilSocket { extends Socket { s.close() ... } close() { ; % do nothing } ... Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Overview 1. Access control in Java. 2. Modeling Java programs and security policies. 3. Extracting control flow graphs. 4. Verificaton and enforcement of security properties. 5. Towards verification of Java modules. Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Access control in Java Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Java security architecture Visibility modifiers (public, private,. . . ). Class loaders for name space creation. Code is given permissions depending on origin, signer,. . . . A Java application can check the permissions of its callers with : AccesController.CheckPermission(P) Privileged code—granting permissions to callers. Stack inspection: an operation is performed only if all code participating in the call (“on the control stack”) has permission to do so. public class ControlledVar { private float var; void write(float new) { AccessController.checkPermission(Write); var = new; } Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Stack inspection check Write P2 P3 P1 3 \ write permission ∈ Perm ( P i ) i = 1 Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Privileged calls Privileged calls: P 2 privileged ⇒ can ignore P 1 . check Write P2 privileged P3 P1 \ write permission ∈ Perm ( P 2 ) Perm ( P 3 ) Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Stack inspection - operationally check(P) check(P) check(P) P ∧¬ Priv ... ... ... ¬ P ... ... ... P ∧ Priv main() main() main() Pass Fail Pass Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Analysing stack-inspecting code priv{ } check(P) • stack inspections. • privileged calls. Extraction of a control flow graph from Java program using control flow analysis Model checking reflexive push-down automata against security properties specified eg. using LTL or security automata (Schneider). Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Model checking Java security Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Program representation n 3 : check ( γ ) n 0 : call = { n 0 } EN : TG n 1 : call n 4 : return CG : Attr : �→ { System } n 0 , n 1 n 2 : return �→ { System , Crit } n 2 �→ { Manager } n 3 , n 4 Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Operational semantics Nodes ∗ is the set of states = Stacks ⊆ Stacks × Stacks .⊲. s ⊲ s ′ one of the following rules applies: iff IS ( n ) = check ( γ ) n TG IS ( n ) = call → n ′ n CG s : n � γ → m ⊲ check ⊲ call s : n ⊲ check s : n ′ s : n ⊲ call s : n : m IS ( m ) = return n TG → n ′ ⊲ return s : n : m ⊲ return s : n ′ Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Sandboxing Code can call methods from own site/sandbox, or (certain) local methods. priv{ } check(P) G ( Site S ⇒ X ( Site S ∨ Local )) Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Resource protection Resource protection: External code can only access a resource via a check node. External Resource A B G ( ¬ External ∨ ( ¬ B U A )) . Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Security automata Notion proposed by Fred Schneider to represent “enforceable security policies”: Finite-state automata with particular sink states identifying security violations. Translation from LTL to automata. The property “all calls leading to a write must have debit permission” expressed as an automaton: true E write 1 0 ¬ P Debit ∧¬ E write E write P Debit ∧¬ E write 2 3 true ¬ E write Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Security verification Given a global security property ϕ (repr. by automaton A ϕ ) and a control flow graph G with security checks, verify that all states satisfy ϕ identify stack traces (“attacks”) leading to violation of ϕ analyse the consequence of inserting/deleting security checks. Standard model-checking solution: Calculate reachable states of product trans. system G × A ϕ . Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Automatic verification technique The set of reachable call stacks can be infinite. Identify those call stacks that satisfy the same security property and pass the same security checks. Approach: Abstract stacks into states of the automata, Define a transition relation on the abstract states and verify that transition system Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Abstraction of control states Keep enough information to decide where to call and return. predict outcome of local security check (stack inspection), check a stack against global security property Principle: Abstract a stack into its effect on the automata. Concrete state = CtrlStack × PgPoint. Abstract state = AutomataStates × TopOfCtrlStack × PgPoint. For example, with one check ψ and global policy ϕ : cs :: m :: n �→ ( A ψ ( cs :: m ) , A ϕ ( cs :: m ) , m , n ) . Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Abstract transition system Call: ( P , p , n ) ∈ [[ G ]] # IS ( n ) = call n − → m ( δ ( P , n ) , n , m ) ∈ [[ G ]] # Return: δ ( P , n ) = N ( P , p , n ) ∈ [[ G ]] # ( N , n , m ) ∈ [[ G ]] # n ······ > n ′ ( P , p , n ′ ) ∈ [[ G ]] # Check : IS ( n ) = check ( γ i ) ( P , p , n ) ⊢ γ i ( P , p , n ) ∈ [[ G ]] # n ······ > n ′ ( P , p , n ′ ) ∈ [[ G ]] # Completeness Theorem : [[ G ]] ⊢ φ ∀ E ∈ [[ G ]] # . E ⊢ φ ⇔ Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Example: accessing an account. main n1: call n2: call owner intruder n3: call n6: call n4: call n7: call n5: call dummy owner has debit canpay debit permission, n8: check(JDK(PCanpay)) n11: check(JDK(PDebit)) intruder hasn’t. n9: call n12: call n10: return n13: call n14: call n15: return read write n16: check(JDK(PRead)) n18: check(JDK(PWrite)) n17: return n19: return Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

Analysis of example Property to show: All calls leading to write must have debit permission and all calls leading to a read must have the Canpay permission: G ( ¬ E write ) ∨ ( P Debit U E write ) ∧ G ( ¬ E read ) ∨ ( P Canpay U E read ) 4 checks + 2 conjuncts in global property = 6 automata. 6 automata + TopOfCtrlStack + PgPoint ⇒ 8-tuple as abstract state: Reachable states : (( 0 , 0 , 0 , 0 , 0 , 0 ) , n 0 , n 1 ) (( 0 , 0 , 0 , 0 , 0 , 0 ) , n 1 , n 6 ) , ... (( 1 , 1 , 1 , 1 , 2 , 2 ) , n 6 , n 11 ) , (( 0 , 0 , 1 , 1 , 0 , 0 ) , n 3 , n 8 ) , ... (( 0 , 0 , 0 , 0 , 0 , 0 ) , n 9 , n 16 ) , (( 0 , 0 , 0 , 0 , 0 , 0 ) , n 9 , n 17 ) , ... . . . . . . 26 states Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004

unsafe_main n0 n3 n4 Execution being cut n11 n6 n5 intruder n14 n8 n15 n7 The of the check debit permission in n10 n9 n47 debit the debit() results in a n12 n48 n22 security exception being n13 n49 debit raised. n37 n38 n18 n40 Yellow traces in the con- trol flow graph show the n41 path to security exception n42 n34 being raised. n43 n39 n27 n44 Thomas Jensen: Model checking security properties of Java components Nantes, 23/09/2004