1 / 33

Preventing Software Vulnerabilities by Static Verification and Run Time Checking

Preventing Software Vulnerabilities by Static Verification and Run Time Checking. Frank Piessens Dept of Computer Science K.U.Leuven. Introduction. How do you decrease the number of vulnerabilities in your code?

yamka
Download Presentation

Preventing Software Vulnerabilities by Static Verification and Run Time Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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,… Secure Software - (C) 2002-2005 F. Piessens

  3. 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 • Can we infer them? • Can we use general-purpose specification/verification toolsets to check them? (Spec#, JML tool suite, …) Secure Software - (C) 2002-2005 F. Piessens

  4. 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 • Security vulnerabilities that arise because consistent integration of security technologies in an application is hard • E.g. Incomplete access mediation Secure Software - (C) 2002-2005 F. Piessens

  5. 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) Secure Software - (C) 2002-2005 F. Piessens

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

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

  8. Race conditions as vulnerabilities void SomeSecureFunction() { if(SomeDemandPasses()) { fCallersOk = true; DoOtherWork(); fCallersOk = false(); } } void DoOtherWork() { if( fCallersOK ) { DoSomethingTrusted(); } else { DemandSomething(); DoSomethingTrusted(); } } Caching a security check Can give another thread access (Example from msdn library) Secure Software - (C) 2002-2005 F. Piessens

  9. 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 b0 = act.balance; act.balance += 50; int b1 = act.balance; release act; b1 == b0 + 50? Always! Secure Software - (C) 2002-2005 F. Piessens

  10. 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 • 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

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

  12. 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 the 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 Secure Software - (C) 2002-2005 F. Piessens

  13. 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; Secure Software - (C) 2002-2005 F. Piessens

  14. 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; a Secure Software - (C) 2002-2005 F. Piessens

  15. 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; a r Secure Software - (C) 2002-2005 F. Piessens

  16. 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; a r Secure Software - (C) 2002-2005 F. Piessens

  17. 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; a r Secure Software - (C) 2002-2005 F. Piessens

  18. 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; a r Secure Software - (C) 2002-2005 F. Piessens

  19. 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; a r Secure Software - (C) 2002-2005 F. Piessens

  20. 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: • 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

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

  22. Problem Statement Client Intranet • 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 • Protocol coded in web tier or client tier Web Client Web Server App Server DB Secure Software - (C) 2002-2005 F. Piessens

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

  24. 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 • Can be bypassed through reverse engineering of, and tampering with client-side components Secure Software - (C) 2002-2005 F. Piessens

  25. Run-time verification General approach: • 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 • Abort session • Log event • … Client Filter App Server Model program Secure Software - (C) 2002-2005 F. Piessens

  26. Example Model Program enum ShoppingState {ProductSelection, ReadyToPay, ReadyToShip, End}; ShoppingState state = ShoppingState.ProductSelection; int topay = 0; Product product = null; public Product LookupProduct(String key) requires state == ShoppingState.ProductSelection; { return <call real product lookup here>; } public int ComputePrice(Product p) requires state == ShoppingState.ProductSelection; { state = ShoppingState.ReadyToPay; topay = <call real price computation logic here> product = p; return topay; } void ProcessPayment(int amount) requires state == ShoppingState.ReadyToPay; requires amount == topay; { state = ShoppingState.ReadyToShip; <call real process payment> } … Client State State Update Action Precondition Secure Software - (C) 2002-2005 F. Piessens

  27. (Part of) Corresponding Model Automaton (graph generated with the Spec Explorer tool from Microsoft Research) Secure Software - (C) 2002-2005 F. Piessens

  28. Deriving model programs from client code • Writing the model programs can be labor-intensive • 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 Secure Software - (C) 2002-2005 F. Piessens

  29. Example pseudo client code Product p; bool buy; String key; int price; key = choose String; p = lookupProduct(key); price = computePrice(p); buy = choose bool; if (buy) { processPayment("XYZ",price); shipProducts("XYZ", p); } Client Program State: values for vars + PC All action sequences generated by this non-deterministic client program are allowed Secure Software - (C) 2002-2005 F. Piessens

  30. 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 • Filter all cps that don’t have the observed call enabled • Reduce all remaining cps’s to a stable cps Secure Software - (C) 2002-2005 F. Piessens

  31. 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 • But this could in principle be improved through more advanced compilation techniques Secure Software - (C) 2002-2005 F. Piessens

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

  33. 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 Secure Software - (C) 2002-2005 F. Piessens

More Related