introduction to computer security - software security
TRANSCRIPT
Introduction to Computer SecuritySoftware Security
Pavel LaskovWilhelm Schickard Institute for Computer Science
Software security threats
Modification of program codeviruses and self-replicating codeOS and API hooking
Control flow hijackinginteger overflowbuffer overflowheap overflowformat string vulnerabilities
Code and data injectionscript injection (e.g. XSS)SQL injection
Malicious software (“malware”)
The term malicious software denotes program codeexecuted without a user’s consent and carrying out harmfulfunctionality.
Malware carriers: boot sector
Save the original MBR in a safe locationOverwrite the MBR with an infected oneBootstrap a system using the new MBR
Viren-Infektionsvektoren Infektion des Boot-Sektors
Infektion des Boot-Sektors
Virus kopiert originalen Bootblock und überschreibt den BootblockVirus erhält Kontrolle beim Bootvorgang noch bevorBetriebssystem und Anti-Viren-SW geladen werdenGegenmaßnahme: Bootblockschutz im BIOS
Abbildung: Mehrfache Infektion durch verschiedene Viren
c© Ulrich Flegel Reaktive Sicherheit · Teil 4 21 / 130
Malware carriers: COM executables
Append a virus body to a programSave an entry point to a program in a virus bodyReplace a program entry point with a jump to a virus bodyVirus code restores the original entry point and jumps to itafter its own execution
Viren-Infektionsvektoren Infektion von Dateien
Anhängen an die Datei (1)
Abbildung: Infektion durch Anhängen
c© Ulrich Flegel Reaktive Sicherheit · Teil 4 30 / 130
Malware carriers: EXE executables
Append a virus body to a programOverwrite a program header to switch the entry point to avirusJump to the original entry point during execution
Viren-Infektionsvektoren Infektion von Dateien
Anhängen an die Datei (2)
Abbildung: Infektion durch Anhängen
c© Ulrich Flegel Reaktive Sicherheit · Teil 4 31 / 130
Malware carriers: macros and scripts
Malicious functionality is implemented in Visual Basic forApplications (VBA).If a document template are infected, so will be everydocument on a system.
Viren-Infektionsvektoren Infektion von Dateien
Dokumenten-Viren (3)Macro Viruses
Abbildung: Beispiel: Concept Virus infiziert Microsoft-Word-Dateien
c© Ulrich Flegel Reaktive Sicherheit · Teil 4 42 / 130
Modern malware threats
Malicious documents (e.g. PDF, Flash)Drive-by downloadsTrojan horsesBotnetsKeyloggers
Exploitation of unvalidated input (1)
A CGI script mails a file to an address read from a form:cat $file | mail $address
The user inputs user@host | rm -rf /
The following statement is executed:cat $file | mail user@host | rm -rf /
Root directory is wiped out.
Exploitation of unvalidated input (1)
A CGI script mails a file to an address read from a form:cat $file | mail $address
The user inputs user@host | rm -rf /
The following statement is executed:cat $file | mail user@host | rm -rf /
Root directory is wiped out.
Exploitation of unvalidated input (1)
A CGI script mails a file to an address read from a form:cat $file | mail $address
The user inputs user@host | rm -rf /
The following statement is executed:cat $file | mail user@host | rm -rf /
Root directory is wiped out.
Exploitation of unvalidated input (2)
The following script validates user name and password:$login = Request.Form(�login�)
$password = Request.Form(�password�)
$sql_command = �SELECT user FROM database WHERE
Login='$login' AND Password='$password' �
db->prepare($sql_command)
The user inputs 'OR''=' for login and 'OR''=' for passwordThe following SQL statement is executedSELECT user FROM database WHERE
Login=� OR �=� AND Password=� OR �=�
Always true (since �=� is true); login is successful.
Exploitation of unvalidated input (2)
The following script validates user name and password:$login = Request.Form(�login�)
$password = Request.Form(�password�)
$sql_command = �SELECT user FROM database WHERE
Login='$login' AND Password='$password' �
db->prepare($sql_command)
The user inputs 'OR''=' for login and 'OR''=' for password
The following SQL statement is executedSELECT user FROM database WHERE
Login=� OR �=� AND Password=� OR �=�
Always true (since �=� is true); login is successful.
Exploitation of unvalidated input (2)
The following script validates user name and password:$login = Request.Form(�login�)
$password = Request.Form(�password�)
$sql_command = �SELECT user FROM database WHERE
Login='$login' AND Password='$password' �
db->prepare($sql_command)
The user inputs 'OR''=' for login and 'OR''=' for passwordThe following SQL statement is executedSELECT user FROM database WHERE
Login=� OR �=� AND Password=� OR �=�
Always true (since �=� is true); login is successful.
Contiguous memory (buffer) allocation
C/C++static: int x[20] declaration outside any function; allocated inthe static variables memory along the program codeautomatic: int x[20] declaraiton inside some function;allocated on the stackdynamic: int *x = new int[20]; must be followed by delete
to avoid memory leaks; allocated on the heap
Javadynamic: int x = new int[20]; gets allocated in on the heap;automatic deallocation by garbage collector
Buffer overruns
What does the following program do?
#include <stdio.h>
#define SIZE 10
main() {
int matrix[SIZE*SIZE];
int total_size = SIZE*SIZE;
int* row_ind[SIZE];
for (int i = 0; i <= total_size; i++)
matrix[i] = i;
for (int i = 0; i <= SIZE; i++)
row_ind[i] = &matrix[i*SIZE];
for (int i = 0; i <= SIZE; i++)
printf("a[%d] = %d\n", i, *row_ind[i]);
}
Process memory organization
Process memory is partitioned intosegments:
.text - program code
.data - initialized static data
.bss - uninitialized static dataheap - dynamically allocated memorystack - program call stack
Each memory segment has appropriatepermissions.Access operations violating thesepermissions cause the “segmentationfault” error.
stack
unused memory
heap
bss
data
text
Higher memory addresses
Lower memory addresses
Stack organization
Stack is composed of framesEach frame comprises
functions argumentsreturn addressframe pointer: the address of thestart of the previous framelocal variables
Frames are pushed on the stackduring function invocation andpopped back after the return
Previous frames
Functionarguments
Return address
Frame pointer
Local variables
Unused stackspace
Stackframe
Overwriting the return address
A local buffer is allocated“bottom-up”, i.e. it starts at lowerand ends at higher stacklocations.Without proper bound checking abuffer content can overspill intoadjacent upper stack area.By controlling buffer content, anattacker can overwrite the returnaddress with an arbitrary valueand hijack the execution flow.
Previous frames
Functionarguments
Return address
Frame pointer
Local variables
Unused stackspace
Stackframe
Software security mechanisms
Data execution protectionmark certain areas in memory as non-executable
Address space layout randomizationchoose stack memory allocation at randommakes it difficult to guess the values to overwrite the returnaddress with
Canariespreceed the return value with a special valuebefore following the return value, check if is content has notchanged after the call
Summary
Software insecurity stems from attacker’s ability to modifysystem resources criticial for program execution, e.g.instruction pointer, function call addresses, interruptaddresses, etc.One of the key sources for software insecurity is failedvalidation of user input.Buffer overflows are a most widely used exploitationtechnique.Special techniques for strengthening software security exist,e.g. canaries, address space layout randomization and dataexecution prevention.