Preventing Software Vulnerabilities by Static Verification and Run

Скачать презентацию Preventing Software Vulnerabilities by Static Verification and Run

cff7c25723998a9e09b51fe3cdb71b4b.ppt

Количество слайдов: 33

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 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

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 ; } public int Compute. Price(Product p) requires state == Shopping. State. Product. Selection state = Shopping. State. Ready. To. Pay; topay = 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; } Action Precondition KATHOLIEKE … Secure Software - (C) 2002 -2005 F. Piessens 26 UNIVERSITEIT LEUVEN

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

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