Program Security

1. Program Security Buffer Overflows Incomplete Access Control CS 395: Computer Security

2. Why Program Security? • Because program flaws are the gateway through which many attacks are launched: • Intrusion detection, network security (e.g. firewalls) are necessary because computers (and specifically the programs they run) are vulnerable to attack. • Because understanding how programs are attacked can help you to write more secure code. CS 395: Computer Security

3. Secure Programs • How do we define the term secure program? • Program that meets specification? • Specifications can be incorrect, incomplete, or vague • Consider example in text (p. 96) of “locked” computers that all used same keys • How do we identify secure programs? • # of faults discovered and fixed during design, development, etc? CS 395: Computer Security

4. History: Fixing Faults • Software engineering research has shown that software that has many faults early on is likely to have many others waiting to be found • ``Penetrate and Patch’’: Analysts search for and repair faults • Badness: pressure to repair specific fault often causes tunnel vision (failure to consider context) • Faults often have non-obvious side effects in places other than immediate area of fault • Fixed faults can cause system performance or operation to suffer CS 395: Computer Security

5. Secure Programs • Often (somewhat vaguely) based on the notion of expectation: does a program behave as the designer and users expect? • Program security flaw: unexpected behavior • Lots of terminology(vulnerability, flaw, faults, failures, etc) • Who cares: only need to know cause (what fault caused the problem) and effect (what failure is visible to user) CS 395: Computer Security

6. Intention • Textbooks makes big deal out of notion of malicious versus non-malicious • Misleading: • Buffer overflow is non-malicious? • Yes, because the flaw is often the result of an accidental oversight of the programmer • No, because a buffer overflow attack can be, well, not good CS 395: Computer Security

7. Three Types of Vulnerabilities • Buffer Overflow • Incomplete Mediation • Time-of-check to Time-of-Use (TOCTOU) Errors CS 395: Computer Security

8. Buffer Overflow • Simply put, trying to squeeze too much stuff into too small a space • Defn: a buffer (or array or string) is a space in which data can be held • Usually, programmer needs to have declared size of the buffer beforehand (but not always) • Also, size cannot always be determined through static analysis (may be run-time decision) CS 395: Computer Security

9. Buffer Overflow • Is this access out of bounds? • Upshot: compiler cannot identify all out-of-bounds accesses • Hope that language run-time flags this (if bad). Many don’t (e.g. C) CS 395: Computer Security

10. Buffer Overflow • Effect of overflow is that data outside buffer is overwritten • Exact effect depends on what is overwritten • User’s data? • User’s program code? • System data? • System program code? CS 395: Computer Security

11. Buffer Overflow Details • You read about them (“Smashing the Stack for Fun and Profit”). • Two parts: • Buffer overrun operation that modifies control flow • Execution of the payload • Other good references are • Pincus and Baker “Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns” • DilDog “The Tao of Windows Buffer Overruns” CS 395: Computer Security

12. Trampolining • Allows attacker to apply buffer overflow when the attacker doesn’t know absolute address of buffer (buff) • Key insight: if a program register R contains a value relative to buff, control can be transferred to buff by first translating control to a sequence of instructions that indirectly transfers via R. • Key: finding such a sequence of instructions at a well-known or predictable address (this is the “trampoline”) CS 395: Computer Security

13. Another Enhancement • Separate two parts of buffer overflow • Useful if the buffer being overrun is too small for payload • Attacker arranges for payload to be in another location, possibly executed later • Payload in programs memory space? • Stored in an environment variable (because typically accessible on linux systems from well-known address near base of the stack) CS 395: Computer Security

14. Heap Overflow • Stack is used to store local variables • Heap stores memory that is global and also memory that is dynamically allocated (e.g. via call to malloc()) CS 395: Computer Security

15. Arc Injection Attack • Instead of supplying code, instead supply data that will lead to desired effect when programs existing code operates on it. • E.g. attacker supplies a command line that the program under attack will use to spawn another process • Called arc injection because the attack causes a new arc (control-flow transfer) into the programs control flow graph, as opposed to code injection (e.g. smashing the stack) which also inserts a new node into graph CS 395: Computer Security

16. Arc Injection Basic Example • Stack buffer overrun modifies saved return address to point to location in the program’s address space • Specifically to location within system function in C standard library • system function takes arbitrary command line as argument, checks arguments validity, loads it into a register R, and makes a call to create the process CS 395: Computer Security

17. Arc Injection Example (cont) • Attacker arranges for R to point to attacker supplied string, then jumps directly to location target, bypassing validity check and assignment • C standard library loads most processes at a well known location, so computing target’s absolute address is straightforward CS 395: Computer Security

18. Arc Injection Example (cont) • How does attacker get R to point to attacker supplied string? • It can be trivial: programs routinely reuse registers, so it would not be unusual that the program uses R in the procedure in which a buffer overrun occurs (e.g., pointing to buff in code below). • Attacker simply writes command line string into buff and ensures that target’s location appears at correct offset in buffer to overwrite return address • Then on return, control is passed to middle of system function CS 395: Computer Security

19. Pointer Subterfuge • Four flavors • Function-pointer clobbering • Data-pointer modification • Exception-handler hijacking • Virtual Pointer (VPTR)smashing • Bottom line is that if you can control pointers, you can cause memory to be overwritten, etc. CS 395: Computer Security

20. Incomplete Mediation • An Example: http://www.somesite.com/subpage/userinput.asp?parm1=(808)5551212&parm2=2009Jan17 • This URL causes the execution of code on the server that reads the two parameters parm1 and parm2. • There may be code on the client (browser) page that checks validity of parameters. • It’s likely also that the values were entered using forms that prohibit certain kinds of entries for various fields • But the parameters are packed into the URL line, which is user modifiable. So whatever checks were made are ineffective. CS 395: Computer Security

21. Incomplete Mediation • The problem: the sensitive data was not completely mediated -- it was placed in an exposed uncontrolled condition • A true-life example: http://www.things.com/order.asp?custID=101&part=55&qy=20&price=10&ship=boat&shipcost=5&total=205 http://www.things.com/order.asp?custID=101&part=55&qy=20&price=10&ship=boat&shipcost=5&total=25 original Question: why even transmit price data?! modified CS 395: Computer Security

22. TOCTOU Errors • Time-of-check to Time-of-Use Errors • Synchronization error: basically, exploitable gap between (time condition for accessing object is checked) and (time access actually occurs) • Ex: Sculpture costs $100. Buyer counts $100 and places it on table. Seller turns around to write receipt, buyer takes $20 back and hands stack to seller (who assumes there is still $100 in stack) • Between time security was checked (counting bills) and object accessed (get sculpture) the condition changed CS 395: Computer Security

23. TOCTOU Error • File system: • Data structure “work ticket” presented to access control module. • Work ticket requires “stamp” authorizing access • Module places copy of ticket in its own work area for checking validity of request, actual ticket remains in user address space. • User modifies data structure in its own address space while access control module is checking the requested file name, etc. • Ticket is validated by access control module (e.g. by returning an auxiliary ticket) • User uses modified data structure with ticket validation for illegal access CS 395: Computer Security

24. Privilege Escalation • Access rights and privileges of programs are dictated by program context, which is typically dictated by user running program • You can modify, delete, etc, files you own, but not critical system files • Privilege Escalation attack is one in which malicious code is launched by a user with low privilege but run with high privilege CS 395: Computer Security

25. Example (April 2006) • Symantec Live Update • Runs with elevated privilege since it needs to download and install programs in system directory • Uses four modules, LU1, LU2, Sys3, and Sys4 • First two are part of Live Update, other two are functions in the OS. • In some releases for Mac, Symantec allowed Live Update to locate Sys3 and Sys4 by using the PATH environment variable rather than specifying the location explicitly. CS 395: Computer Security

26. Example (April 2006) • But the LU modules run with escalated privilege, and this is passed automatically to the Sys modules. • So an attacker can write their own function, call it Sys3 or Sys4, and modify the PATH variable so that this is what is run when Live Update runs. • The end result is a user written function running with elevated privileges! CS 395: Computer Security

27. Covert Channels • A much researched topic • Defn: Programs that communicate information to people who should not receive it. • Communication usually travels unnoticed, accompanying other communications • Example: Student helping others cheat on multiple choice exam by coughing, wheezing, moving foot, etc, to indicate choice (a), (b), etc. CS 395: Computer Security

28. CS 395: Computer Security

29. Covert Channels • Problem: these are easy to create • Timing • Existence of files • Exact format of files • Number of blank spaces in fields • Incorrect (but unnoticed) information • Availability of resources • Dynamically allocated memory available? • File locked or unlocked? CS 395: Computer Security

30. CS 395: Computer Security

31. File Lock Covert Channel CS 395: Computer Security

32. File Existence Channel Signaling 100 CS 395: Computer Security

33. Timing Channel • Pass information by using speed at which things happen • Example: two process system where info passed by accepting(1) or rejecting(0) offered processing time CS 395: Computer Security