Fall 2006CS 395: Computer SecuritySlide #1 Program Security Buffer Overflows Incomplete Access Control

Fall 2006 CS 395: Computer Security Slide #1

Program Security

Buffer Overflows

Incomplete Access Control


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.


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?


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


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)


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


Three Types of Vulnerabilities

• Buffer Overflow

• Incomplete Mediation

• Time-of-check to Time-of-Use (TOCTOU) Errors


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)


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)


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?


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”


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”)


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)


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())


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


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


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


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


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.


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.


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

modified

Question: why even transmit price data?!


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


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


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


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.


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!


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.



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?



File Lock Covert Channel


File Existence Channel

Signaling 100


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

Documents

Fall 2006CS 395: Computer SecuritySlide #1 Program Security Buffer Overflows Incomplete Access Control