Preventing Software Vulnerabilities by Static Verification and Run

Preventing Software Vulnerabilities by Static Verification and Run Time Checking Frank Piessens Dept of Computer Science K. U. Leuven KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 1

Introduction • How do you decrease the number of vulnerabilities in your code? • Today often realized by overloading the poor developer with guidelines, principles, checklists, best practices, … KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 2

Introduction • Key challenge: how can we automate the prevention of vulnerabilities or their exploitation? • A vulnerability is essentially a bug – Hence, a violation of some (implicit or explicit) specification • Interesting research questions: – What are these security-specific (partial) specifications? • If we can make them explicit, we might be able to prevent or detect vulnerabilities automatically KATHOLIEKE UNIVERSITEIT LEUVEN – Can we infer them? Secure Software - (C) 2002 -2005 F. Piessens – Can we use general-purpose 3

Introduction • Let’s look at some vulnerabilities from the OWASP Top Ten, and see what specification they violate: – Memory-management related bugs e. g. buffer overflow – Concurrency-management related bugs e. g race condition – I/O-management related bugs • E. g. SQL injection • E. g. Application protocol checking KATHOLIEKE UNIVERSITEIT LEUVEN – Security vulnerabilities that arise because consistent integration of security technologies in an application- is 2002 -2005 F. Piessens Secure Software (C) hard 4 • E. g. Incomplete access mediation

Introduction • Goal of this talk: “teasers” for some of the research tracks in this area: – Safe concurrency in Spec# – Run-time application protocol checking for distributed applications –… • (We’ll see how far we get) KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 5

Overview • Introduction • Safe concurrency in Spec# • Run-time application protocol checking for distributed applications • Conclusions KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 6

Safe concurrency in Spe. C# [Bart Jacobs] • Joint work with MSR Redmond: Rustan Leino and Wolfram Schulte • Problem: example in C# class Account { int balance; } Account act = …; int b 0 = act. balance; act. balance += 50; int b 1 = act. balance; b 1 == b 0 + 50? Not necessarily! KATHOLIEKE UNIVERSITEIT LEUVEN lock (act) { b 0 = act. balance; act. balance += 50; b 1 = act. balance; } b 1 == b 0 + 50? Not necessarily! 7 Secure Software - (C) 2002 -2005 F. Piessens

Race conditions as vulnerabilities void Some. Secure. Function() { if(Some. Demand. Passes()) { f. Callers. Ok = true; Do. Other. Work(); f. Callers. Ok = false(); } } void Do. Other. Work() { if( f. Callers. OK ) { Do. Something. Trusted(); } else { Demand. Something(); Do. Something. Trusted(); } } KATHOLIEKE UNIVERSITEIT LEUVEN Caching a security check Can give another thread access (Example from msdn library) Secure Software - (C) 2002 -2005 F. Piessens 8

Observations • C# offers synchronization primitives, but their correct use is not enforced • Spec#’s primitives are very similar, but their correct use is enforced acquire act; int b 0 = act. balance; act. balance += 50; int b 1 = act. balance; release act; b 1 == b 0 + 50? Always! KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 9

Spec#’s ownership system • Spec# structures the heap as a forest of objects ordered in an ownership hierarchy – Think of the owned sub tree as the component objects of the root – Rep field modifier tags owned objects • Spec# distinguishes “packed” and “unpacked” objects KATHOLIEKE UNIVERSITEIT LEUVEN – Only unpacked objects can be modified – Upon packing, it is checked if the ownership ordering remains a forest – Only root-objects can be unpacked, causing the root object to lose ownership of its components Secure Software - (C) 2002 -2005 F. Piessens 10

Illustrating pack and unpack HEAP a b x a pack a y c b x y c unpack a a Unpacked object b Packed object, with ownership domain x KATHOLIEKE UNIVERSITEIT LEUVEN Class A { rep B x; rep C y; } Rep field reference Secure Software - (C) 2002 -2005 F. Piessens 11

Achieving safety • Basic idea: – Extend ownership to threads – Writing to the fields of an object is only allowed by the owning thread – Thread ownership changes through • Acquire o: threads can acquire an object o that is a root object in the ownership hierarchy – As a consequence thread gains exclusive access to the entire ownership domain • Release o: threads can release a packed object that they own – As a consequence, the thread loses access to the entire ownership domain KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 12

Example Thread 1 class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 13

Example Thread 1 a KATHOLIEKE UNIVERSITEIT LEUVEN class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 14

Example Thread 1 a r KATHOLIEKE UNIVERSITEIT LEUVEN class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 15

Example Thread 1 a r KATHOLIEKE UNIVERSITEIT LEUVEN class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 16

Example Thread 1 a r KATHOLIEKE UNIVERSITEIT LEUVEN class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 17

Example Thread 1 a r KATHOLIEKE UNIVERSITEIT LEUVEN class Agg { rep Rep f; } class Rep {} Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 18

Example Thread 1 class Agg { rep Rep f; } class Rep {} a r KATHOLIEKE UNIVERSITEIT LEUVEN Agg a = new Agg; Rep r = new Rep; pack r; a. f = r; pack a; release a; Secure Software - (C) 2002 -2005 F. Piessens 19

Summary • Spec# ensures field accesses are thread-local operations • Supports aggregate objects • Object invariants are enforced [not discussed here] • Full dynamic enforcement • Sound thread-local static checking • More information on: KATHOLIEKE UNIVERSITEIT LEUVEN – http: //research. microsoft. com/specsharp/ – Bart Jacobs et al. Safe concurrency for aggregate objects with invariants, SEFM 2005 Secure Software - (C) 2002 -2005 F. Piessens 20

Overview • Introduction • Safe concurrency in Spec# • Run-time application protocol checking for distributed applications • Conclusions KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 21

Problem Statement Client Web Client Intranet Web Server App Server DB • Correct (secure) functioning of a distributed application can depend on the client adhering to an (often implicit) protocol or workflow – Stateless session beans on the application server KATHOLIEKE – Protocol coded in web tier or client tier 22 Secure Software - (C) 2002 -2005 F. Piessens UNIVERSITEIT LEUVEN

Problem Statement • Example: prototypical e-commerce application Product lookup. Product(String key) – Stateless process. Payment(String customer, int amou service methods void ship. Products(String customer, Basket b) int compute. Price(Basket b) 1) lookup several products – Expected client operation and possibly put in b 2) compute price of basket 3) ask confirmation from the user 4) process payment for computed amount 5) Ship all products in basket KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 23

Problem Statement • If client workflow is enforced through coding, there can be a substantial risk that workflow logic is changed or bypassed – Example: workflow is implemented in a web tier • Can be bypassed through forceful browsing or parameter tampering – Example: workflow is implemented in client tier KATHOLIEKE UNIVERSITEIT LEUVEN • Can be bypassed through reverse engineering Secure Software - (C) 2002 -2005 F. Piessens 24 of, and tampering with client-side components

Run-time verification Client General approach: Filter App Server Model program – Position a filter between the two components at the side of the trusted component – Filter is programmed with a model program – If an observed application event does not correspond to a possible action in the model program, defensive measures are taken KATHOLIEKE UNIVERSITEIT LEUVEN • Abort session • Log event • … Secure Software - (C) 2002 -2005 F. Piessens 25

Example Model Program enum Shopping. State {Product. Selection, Ready. To. Pay, Ready. To. Ship, End}; Shopping. State state = Shopping. State. Product. Selection; Client State int topay = 0; Product product = null; public Product Lookup. Product(String key) requires state == Shopping. State. Product. Se return <call real product lookup here>; } public int Compute. Price(Product p) requires state == Shopping. State. Product. Selection state = Shopping. State. Ready. To. Pay; topay = <call real price computation logic here> State Update product = p; return topay; } void Process. Payment(int amount) requires state == Shopping. State. Ready. To. Pay; requires amount == topay; { state = Shopping. State. Ready. To. Ship; <call real process payment> } Action Precondition KATHOLIEKE … Secure Software - (C) 2002 -2005 F. Piessens 26 UNIVERSITEIT LEUVEN

(Part of) Corresponding Model Automaton (graph generated with the Spec Explorer tool from Microsoft

Deriving model programs from client code • Writing the model programs can be laborintensive • An implementation of a valid client is also a specification of the protocol – But possibly an over-specification – Not immediately usable to program a filter • Our approach – Compile a non-deterministic pseudo-code client program to a model program – Possibly compact the generated model automaton through state grouping KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 28

Example pseudo client code Product p; bool buy; String key; int price; Client Program State: values for vars + PC key = choose String; p = lookup. Product(key); price = compute. Price(p); All action sequences buy = choose bool; generated by this non-deterministic if (buy) { client program are allowed process. Payment("XYZ", price); ship. Products("XYZ", p); } KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 29

Construction of corresponding model program • Client program state (cps): – Values for variables + Program Counter (PC) – Is stable if the PC points to a method call to the server • Client State CS in model program – Set of possible stable client program states • Precondition for a method call – There exists a cps in CS that is ready to perform that call • Client State update after a call KATHOLIEKE UNIVERSITEIT LEUVEN – Filter all cps that don’t have the observed call enabled Software - (C) 2002 -2005 F. Piessens Secure 30

Discussion • Advantages: – Pseudo client programs are much easier to write, – … and can even be derived from existing client code by replacing user input with choose statements – Pseudo client programs have a “default deny” semantics • Disadvantages: – Pseudo client programs sometimes over constrain the protocol – Performance of the filter is much worse KATHOLIEKE UNIVERSITEIT LEUVEN • But this could in principle be improved through more Secure Software - (C) 2002 -2005 F. Piessens 31 advanced compilation techniques

Overview • Introduction • Safe concurrency in Spec# • Run-time application protocol checking for distributed applications • Conclusions KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 32

Conclusions • Software security is a great opportunity for applications of formal methods and theory of programming • Interesting developments in: – Programming concepts – Type systems – Code analysis tools – Runtime infrastructure KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002 -2005 F. Piessens 33