1. Buffer Overflows Incomplete Access Control
Program Security
Buffer Overflows
Incomplete Access Control
Fall 2006
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.
Fall 2006
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?
Fall 2006
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
Fall 2006
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)
Fall 2006
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
Fall 2006
CS 395: Computer Security

7. Three Types of Vulnerabilities
Buffer Overflow
Incomplete Mediation
Time-of-check to Time-of-Use (TOCTOU) Errors
Fall 2006
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)
Fall 2006
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)
Fall 2006
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?
Fall 2006
CS 395: Computer Security

11. Incomplete Mediation An Example:
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.
Fall 2006
CS 395: Computer Security

12. Incomplete Mediation
The problem: the sensitive data was not completely mediated -- it was placed in an exposed uncontrolled condition
A true-life example:
original
Question: why even transmit price data?!
modified
Fall 2006
CS 395: Computer Security

13. 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
Fall 2006
CS 395: Computer Security