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

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

3. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens3 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, …)

4. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens4 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

5. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens5 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)

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

7. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens7 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!

8. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens8 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)

9. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens9 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!

10. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens10 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

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

12. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens12 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

13. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens13 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;

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

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

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

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

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

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

20. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens20 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/http://research.microsoft.com/specsharp/ –Bart Jacobs et al. Safe concurrency for aggregate objects with invariants, SEFM 2005

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

22. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens22 Problem Statement 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 ClientWeb ServerApp ServerDB Client Intranet

23. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens23 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

24. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens24 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

25. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens25 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 … App ServerClientFilter Model program

26. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens26 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 ; } public int ComputePrice(Product p) requires state == ShoppingState.ProductSelection; { state = ShoppingState.ReadyToPay; topay = product = p; return topay; } void ProcessPayment(int amount) requires state == ShoppingState.ReadyToPay; requires amount == topay; { state = ShoppingState.ReadyToShip; } … Client State State Update Action Precondition

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

28. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens28 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

29. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens29 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

30. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens30 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

31. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens31 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

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

33. KATHOLIEKE UNIVERSITEIT LEUVEN Secure Software - (C) 2002-2005 F. Piessens33 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