introduction to computer security - software security

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.