Upload
jacob-cook
View
217
Download
1
Embed Size (px)
Citation preview
Chapter-4
Software Security
Why Software? Why is software as important to security as
crypto, access control and protocols? Virtually all of information security is
implemented in software If your software is subject to attack, your
security is brokenRegardless of strength of crypto, access control or
protocols
Software is a poor foundation for security
Software Issues
Attackers Actively look for bugs
and flaws Like bad software… …and try to make it
misbehave Attack systems thru
bad software
“Normal” users Find bugs and flaws
by accident Hate bad software… …but must learn to
live with it Must make bad
software work
Complexity “Complexity is the enemy of security”
Netscape 17,000,000
Space shuttle 10,000,000
Linux 1,500,000
Windows XP 40,000,000
Boeing 777 7,000,000
system Lines of code (LOC)
Software Security Topics Program flaws (unintentional)
Buffer overflowIncomplete mediationRace conditions
Malicious software (intentional)VirusesWorms
Program Flaws
An error is a programming mistakeDone by human
An error may lead to incorrect state: faultA fault is internal to the program
A fault may lead to a failure, where a system departs from its expected behaviorA failure is externally observable
error fault failure
Examplechar array[10];for(i = 0; i < 10; ++i)
array[i] = `A`;array[10] = `B`;
This program has an error This error might cause a fault
o Incorrect internal state
If a fault occurs, it might lead to a failureo Program behaves incorrectly (external)
We use the term flaw for all of the above
Secure Software In software engineering, try to insure that a
program does what is intended Secure software engineering requires that
the software does what is intended… …and nothing more Absolutely secure software is impossible
Absolute security is almost never possible
Program Flaws Program flaws are unintentional
But still create security risks
We’ll consider 3 types of flawsBuffer overflow (smashing the stack)Incomplete mediationRace conditions
Many other flaws can occur These are most common
Buffer Overflow• In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory.
• This may result in abnormal program behavior, including memory access errors, incorrect results, a crash, or a breach of system security.
Buffer Overflow
Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array.
Buffer Overflow
Most commonly this occurs when copying strings of characters from one buffer to another.
Buffer Overflow
a program has defined two data items which are adjacent in memory: an 8-byte-long string buffer, A, and a two-byte integer, B.
Initially, A contains nothing but zero bytes, and B contains
the number 1979. Characters are one byte wide.
Buffer Overflow Now, the program attempts to store the null-
terminated string "excessive" in the A buffer. By failing to check the length of the string, it overwrites the value of B:
Although the programmer did not intend to change B at all, B's value has now been replaced by a number formed from part of the character string. That uses ASCII "e" followed by a zero byte would become the number 25856.
Exploitation The techniques to exploit a buffer overflow
vulnerability vary per architecture, operating system and memory region. For example, exploitation on the heap (used for dynamically allocated memory) is very different from on the call stack.
Stack-based exploitation Heap-based exploitation
Buffer Overflow
Q: What happens when this is executed? A: Depending on what resides in memory at
location “buffer[20]”Might overwrite user data or codeMight overwrite system data or code
int main(){
int buffer[10];
buffer[20] = 37;}
Simple Buffer Overflow Consider Boolean flag for authentication Buffer overflow could overwrite flag allowing
anyone to authenticate!
buffer
FTF O U R S C …
Boolean flag
In some cases, attacker need not be so lucky as to have overflow overwrite flag
Memory Organization
Text == code Data == static variables Heap == dynamic data Stack == “scratch paper”
Dynamic local variablesParameters to functionsReturn address
stack
heap
data
text
high address
low address
SP
Stack-based exploitation The malicious user may exploit stack-based buffer
overflows to manipulate the program in one of the following method
By overwriting a local variable that is near the buffer in memory on the stack to change the behavior of the program which may benefit the attacker.
By overwriting the return address in a stack frame. Once the function returns, execution will resume at the return address as specified by the attacker.
By overwriting a function pointer
Heap-based exploitation A buffer overflow occurring in the heap data area is
referred to as a heap overflow and is exploitable in a different manner to that of stack-based overflows.
Memory on the heap is dynamically allocated by the application at run-time and typically contains program data.
Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers.
Typical Attack Scenario Users enter data into a Web form Web form is sent to server Server writes data to buffer, without
checking length of input data Data overflows from buffer Sometimes, overflow can enable an attack Web form attack could be carried out by
anyone with an Internet connection
Simplified Stack Example
high
void func(int a, int b){
char buffer[10];
}
void main(){
func(1, 2);
}
::
buffer
ret
a
b
return address
low
SP
SP
SP
SP
Smashing the Stack
high
What happens if buffer overflows?
::
buffer
a
b
ret…
low
SP
SP
SP
SP
ret
Program “returns” to wrong location
NOT!
???
A crash is likelyoverflow
overflow
Smashing the Stack
high
Trudy has a better idea… :
:
a
b
low
SP
SP
SP
SP
ret
Code injection Trudy can run
code of her choosing!
evil code
ret
Smashing the Stack
Trudy may not knowo Address of evil codeo Location of ret on stack
Solutionso Precede evil code with
NOP “landing pad” o Insert lots of new ret
evil code
::
::
ret
ret
:
NOP
NOP
:
ret
ret
Stack Smashing Summary A buffer overflow must exist in the code Not all buffer overflows are exploitable If exploitable, attacker can inject code Trial and error likely required Stack smashing is “attack of the decade”
Example Source code of the buffer overflow
Flaw easily found by attacker
Even without the source code!
Stack Smashing Example Program asks for a serial number that the
attacker does not know Attacker does not have source code Attacker does have the executable (exe)
Program quits on incorrect serial number
Example By trial and error, attacker discovers an
apparent buffer overflow
Note that 0x41 is “A” Looks like ret overwritten by 2 bytes!
Example Next, disassemble bo.exe to find
The goal is to exploit buffer overflow to jump to address 0x401034
Example Find that 0x401034 is “@^P4” in ASCII
Example Reverse the byte order to “4^P@” and…
Success! We’ve bypassed serial number check by exploiting a buffer overflow
Overwrote the return address on the stack
Stack Smashing Prevention 1st choice: employ non-executable stack
“No execute” NX bit (if available) Memory can be flagged so that the code can’t
execute on specified location.
2nd choice: use safe languages (Java, C#)
3rd choice: use safer C functionsFor unsafe functions, there are safer versionsFor example, strncpy instead of strcpy
Incomplete mediation Inputs to programs are often specified by
untrusted usersWeb-based applications are a common example
Users sometimes mistype data in web formsPhone number: 51998884567Email: iang#cs.uwaterloo.ca
The web application needs to ensure that what the user has entered represents a meaningful request
This is called mediation
Incomplete mediation Incomplete mediation occurs when the
application accepts incorrect data from the user Sometimes this is hard to avoid
Phone number: 519-886-4567This is a reasonable entry, that happens to be wrong
We focus on catching entries that are clearly wrongNot well formed
○ DOB: 1980-04-31Unreasonable values
○ DOB: 1876-10-12Inconsistent with other entries
Why do we care? What's the security issue here?
What happens if someone fills in:DOB: 98764874236492483649247836489236492
○ Buffer overflow?DOB: '; DROP DATABASE clients --
○ SQL injection?
We need to make sure that any user-supplied input falls within well-specified values, known to be safe
Client-side mediation You've probably visited web site with forms that
do client-side mediationWhen you click “submit”, Javascript code will first run
validation checks on the data you enteredIf you enter invalid data, a popup will prevent you from
submitting it
Related issue: client-side stateMany web sites rely on the client to keep state for
themThey will put hidden fields in the form which are
passed back to the server when the user submits the form
Client-side mediation Problem: what if the user
Turns off Javascript?Edits the form before submitting it? (Greasemonkey)Writes a script that interacts with the web server
instead of using a web browser at all?Connects to the server “manually”?
(telnet server.com 80)
Note that the user can send arbitrary (unmediated) values to the server this way
The user can also modify any client-side state
Example At a bookstore website, the user orders a copy
of the course text. The server replies with a form asking the address to ship to. This form has hidden fields storing the user's order<input type=“hidden” name=“isbn” value=“0-13-239077-9”><input type=“hidden” name=“quantity” value=“1”><input type=“hidden” name=“unitprice” value=“111.00”>
What happens if the user changes the “unitprice” value to “50.00” before submitting the form?
Defences against incomplete mediation Client-side mediation is an OK method to use in order
to have a friendlier user interface, but is useless for security purposes.
You have to do server-side mediation, whether or not you also do client-side.
For values entered by the user:Always do very careful checks on the values of all fields
For state stored by the client:Make sure the client has not modified the data in any way
TOCTTOU errors / Race Condition TOCTTOU (“TOCK-too”) errors
Time-Of-Check To Time-Of-UseAlso known as “race condition” errors
These errors occur when the following happens:User requests the system to perform an actionThe system verifies the user is allowed to perform
the actionThe system performs the action
Race Condition
Security processes should be atomicOccur “all at once”
Race conditions can arise when security-critical process occurs in stages
Attacker makes change between stagesOften, between stage that gives authorization, but
before stage that transfers ownership
Example: Unix mkdir
mkdir Race Condition mkdir creates new directory How mkdir is supposed to work
1. Allocate space
mkdir
2. Transfer ownership
mkdir Attack
Not really a “race”o But attacker’s timing is critical
1. Allocate space
mkdir
3. Transfer ownership
2. Create link to password file
The mkdir race condition
Race Conditions Race conditions are common Race conditions may be more common than
buffer overflows But race conditions harder to exploit To prevent race conditions, make security-
critical processes atomicOccur all at once, not in stages