Application Security (part 1)

1. Application Security (part 1) CSG 3/21/2011 Presented By: Kevin Hulin

2. Outline • Overview • Definitions • Application: Types of Errors • Defense • Program Correctness • Formal Methods • Model Checking • Automatic Discovery of Vulnerabilities • Smart fuzzing through symbolic execution

3. Definitions Application Security - Measures taken to prevent malicious application users and programs from exploiting program vulnerabilities Trusted Computing Base – The foundation of trust for computing. It is the goal of researchers to shrink the TCB as much as possible

4. Types of Errors Generally three types of errors: • Failure to sanity check user inputs • Insecure protocol implementation • Other security failures • Homebrew Crypto • Weak crypto / passwords • Security through obscurity

5. Find the errors //C void copyData(char *userData){ char buf[10]; strcpy(buf,userData) }

6. Find the errors //java String query(String uName, String pass){ return sql.query(“SELECT * FROM USERS WHERE UNAME = “ + user + “ AND PASSWORD = “ + pass + “;”); }

7. Find the errors //C void printFilename(char* args){ printf(args[0]); }

8. Find the errors //python def encrypt(x): if(len(x)%2==1): x = x + "\n" return "".join(chr(0xAB^ord(x[i]))+chr(0xCD^ord(x[i+1]))for i in range(0,len(x),2))

9. Find the errors <!-- Server side --> <?php $color = 'blue'; if (isset( $_GET['COLOR'] ) ) $color = $_GET['COLOR']; require( $color . '.php' ); ?> <!-- Client side --> <form method="get"> <select name="COLOR"> <option value="red">red</option><option value="blue">blue</option> </select><input type="submit"></form>

10. Easy to make mistakes There are many ways to write insecure code How to prevent these security mistakes from being made?

11. Defenses Detect • Code review / auditing • Static analysis • Symbolic execution Prevent • Code/binary rewriting • Sandboxing Prove • Formal Methods - Model checking / Theorem proving

12. Detect

13. Detect - Code review/auditing Manual review (often by someone other than the programmer) of source / binary code to find potential vulnerabilities Pros Could potentially find all vulnerabilities Cons Manual, Slow, Requires expert understanding of language / assembly

14. Detect - Static Analysis Like auditing, but automatic! Don’t execute the code. Pros Automatic! Fast Cons Unlikely to find everything, Some constructs are difficult to discover (E.g. dynamically computed jump addresses)

15. Detect - Symbolic Execution Represent the program state symbolically to be used in a logic engine (e.g. SAT Solver) Pros Powerful, Fast, Automatic Cons Difficult to implement, Limited by SAT solver, Computing loop invariants is difficult

16. Prevent

17. Prevent – Rewriting Insert code around security relevant functions to ensure security policies are upheld (binary and source level) Pros Robust, Effective, Provably secure in some cases Cons Rewrite rules are specific to a single policy, so any changes require making new rules

18. Prevent - Sandboxing Add an extra layer around potentially vulnerable programs to reduce the breadth of susceptibility Pros Easy, Relatively secure Cons Depends on sandbox security - May contain it’s own vulnerabilities, resource intensive

19. Prove

20. Prove - Formal Methods Use mathematically founded solution to prove the adherence of an implementation to specifications Pros Powerful, Fast, Automatic, Guaranteed security Cons Requires expertise, Expensive to implement, Limited by state-space explosion problem

21. Security

22. Security • Do you trust your… • Programmer • Compiler • Operating System • Do you NEED to trust them? • No… IRMs, Sandboxing, Static/Dynamic analysis, Certifying compilers, Proof carrying code, etc

23. Non-Formal Methods = Not Enough • Validation and testing • Not exhaustive – Test it a lot => “Looks like it works” • History of non-security minded development • Not good enough for certain High Consequence systems • Eg: High profile banking applications, aviation controls, shuttle sensors, weapons controllers

24. Brief History The need for provable security is known Intel Pentium FDIV bug (1995) Arianne 5 – European Space Agency (1996) North East America Blackout (2003) High cost of consequences leads industry giants to move toward provably correct code

25. Background Boolean Satisfiability(SAT) – Determination of whether there exists an assignment of Boolean values to variables that will make a given formula true. Example: Solution:

26. Model Checking • Formally define program as a finite state machine • FSM = States (variable assignments) and transitions between them • Take advantage of advances in SAT to determine validity of policies (temporal logic statements) • If a policy is upheld, returns true. • If a policy is violated, returns false + counter example

27. Example Policy: Do not allow sending of e-mail after a confidential document has been opened Opened Secret = True Opened Secret = False * Secure to send E-mail NOT Secure to send E-mail

28. Model Checking MODULE send-mail-ok(opened-secret) VAR secure : word[1]; ASSIGN init(secure) := 0b_1; next(secure) := secure & !opened-secret CTLSPEC AG (opened-secret -> AX !secure) => True CTLSPEC AG EF secure => False <counter-example>

29. Symbolic Execution

30. Symbolic Execution • Symbolically execute a program by maintaining a table of value updates • Requires simulation of register/stack updates • Ex: • add EAX 0x0F // • xor EBX EBX// • not EBX // • cmp EAX EBX // • je error • Resulting constraint:

31. Constraint Solving • Constraint: • In bitvector expressions: • x1 : BITVECTOR(8) • x2 : BITVECTOR(8) • QUERY(BVPLUS(8,x1,0b00001111)=~BVXOR(x2,x2)) • => Invalid. • ASSERT( x1 = 0hexE0 ); • ASSERT( x2 = 0hex00 );

32. Tools (Actually useful for CTFs maybe?) • Fuzzgrind • Based off Valgrind • Uses symbolic execution to find memory leaks • Feed in a program and an initial input file • Executes the program on the input file and tracks register / memory changes to build constraints • Solves constrains using STP constraint solver to generate a new input (that will take a different execution path) • Effectively a super efficient fuzzer!

33. Demo Fuzzgrind!

34. Conclusion Application security is hard (yay job security) Formal approaches to application security are growing in popularity as computers become more powerful

35. Questions ?

36. Announcements Nuit du Hack PrequalsMarch 23 6:00pm - March 25 6:00 pm(48 hours long) Top 15 teams qualify for NDH2k12 in Paris