exploits

1

presentations

Spring, 2008

Exploits and Vulnerabilities

Spring, 2008

CS 351 Defense Against the Dark Arts

2

Vulnerability is often used to refer only to vulnerable code in an OS or applications

More generally, a vulnerability is whatever weakness in an overall system makes it open to attack

An attack that was designed to target a known vulnerability is an exploit of that vulnerability

Vulnerabilities and Exploits

2

Spring, 2008


3

Varieties of Vulnerabilities Buffer overflow on stack

– As we will see, primarily used to overwrite the return address (a.k.a. return instruction pointer)

Buffer overflow on heap – Return addresses are not on the heap – Other pointers are on the heap and can be overwritten,

such as function pointers and file pointers

Format string attacks Memory management attacks Failure to validate input URL encoding failures; … the list goes on

Spring, 2008


4

Classifying Vulnerabilities Szor classifies vulnerabilities and exploits by

generation 1. First generation: Stack buffer overflow 2. Second generation:

Off by one overflows Heap overflows File pointer overwriting Function pointer overwriting

3. Third generation Format string attacks Memory (heap) management attacks … the list is lengthy

3

Spring, 2008


5

Buffer overflow is the most common exploit – Array bounds not usually checked at run time

What comes after the buffer being overflowed determines what can be attacked – The return address is on the stack frame at a known offset

after the last local variable on the frame – Return address can be changed to cause a return to

malicious code

Buffer overflows are easy to guard against, yet they remain the most common code vulnerability

First Generation Exploits

Spring, 2008


6

void bogus(void) { int i; char buffer[256]; // Return address follows!

printf(“Enter your data as a string.\n”); scanf(“%s”, buffer); // No bounds check!

process_data(buffer); return; // Returns to the return address that follows buffer[] // on the stack frame }

Stack Buffer Overflow Example

4

Spring, 2008


7

Stack Buffer Overflow cont’d.

In the stack frame for bogus(), buffer[257] would fall on top of the return address:

Spring, 2008


8

Notice that the program does not check to make sure that the user inputs 255 characters or less

Source code is available for many operating systems and applications (or, they can be reverse engineered)

Attacker can see that it is possible to overflow the buffer

Buffer is last data item on the stack frame; the return address from this function will be at a defined distance after it


5

Spring, 2008


9

Attacker can enter a character string representation of his malicious object code, long enough to fill the buffer

At the end of the malicious code, the attacker passes the address of variable “buffer” so that it overwrites the return address of function bogus() on the stack frame

When bogus() returns, it will cause a return to the buffer address, executing the malicious code in it


Spring, 2008


10


bogus() is now “returning” to buffer[0]

6

Spring, 2008


11

Second Generation Exploits: Heap Buffer Overflow Example: overwriting a file pointer #include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int argc, char **argv) {

int ch = 0, i = 0;

FILE *f = NULL;

static char buffer[16], *szFileName = “C:\\harmless.txt”;

ch = getchar();

while (ch != EOF) { /* User input can overflow buffer[] */

buffer[i++] = ch; ch = getchar();

}

f = fopen(szFileName, “w+b”); /* Might not be C:\harmless.txt ! */

fputs(buffer, f);

fclose(f);

return 0;

}

Spring, 2008


12

Second Generation Exploits: Heap Buffer Overflow cont. Examine the key lines of the example code: static char buffer[16], *szFilename = “C:\\harmless.txt”;

Both variables are placed in global heap (because they were declared static) and will be consecutive in the heap

When buffer[] is overflowed with keyboard input, it will overwrite szFilename:

while (ch != EOF) { /* User input can overflow buffer[] */ buffer[i++] = ch; ch = getchar(); }

An attacker who can compile the code and dump it to figure out addresses can now make szFileName point anywhere he wants

For example, he could make it point to argv[1]; this means he can pass in a file name on the command line!

So, the attacker passes in C:\autoexec.bat or some other protected system file name on the command line, and if this program is a system utility that runs with admin privileges, the system file can be overwritten

7

Spring, 2008


13

Case Study: Slapper Worm

The 2002 worm known as Linux/Slapper was a very complex attack on heap buffer overflow vulnerabilities within the Apache web server

Vulnerability: In secure mode (i.e. on an https:// connection under SSL [Secure Socket Layer]), Apache copied the client’s master key into a fixed-length buffer key_arg[] that was just big enough to hold a valid 8-byte key, without doing any bounds checking, even though the key length is passed as a second parameter with the key

Exploit: Pass in a long key and key length, such that a certain magic address is overwritten

Spring, 2008


14

Slapper: The Magic Address The magic address that Slapper wanted to overwrite was the GOT

(Global Offset Table) entry for the free() function – GOT is the Unix/ELF equivalent of the IAT (Import Address Table) in a Windows PE

file; Slapper is therefore an IAT modifying EPO worm – I.e. If you redirect the GOT entry for free(), then calls into the C run-time library

that should have gone into free() are now redirected to a new address The relative distance from the key_arg[] buffer to the GOT entry for

free() differs among Apache revisions and among different Linux revisions for which Apache was compiled

The Slapper author computed the addresses and distances across 23 (!) different combinations of Apache revision/Linux system – The first client message the worm sends is a request for Apache to identify its

revision number and the Linux system version code (a legitimate request, as Apache services can depend on these numbers)

– The exploit code was then tuned for the particular revision/system Ultimately, Slapper ran its own shellcode on the server system, with

Apache privileges, when Apache executed a call to free() See Szor, 10.4.4, for lots more details

8

Spring, 2008


15

Second Generation Exploits: Off by One Attack

The C language starts array indices at zero, which is not always intuitive for beginning programmers

This often leads to off-by-one errors in code that fills a buffer void vuln(char *foobar) { int i; char buffer[512]; for (i = 0; i <= 512; ++i) /* Should be <, not <= */ buffer[i] = foobar[i]; } int main(int argc, char *argv[]) { if (2 == argc) vuln(argv[1]); return 0; }

How much damage could a one-byte exploit cause?

Spring, 2008


16

Off by One Attack

The return address is NOT located just past the local variables on the x86 stack frame; there is a saved EBP location between them

The attacker cannot directly alter the return address He can alter the last byte of the saved EBP When the vulnerable function returns, the calling

function will now have a bogus stack frame – This bogus stack frame can be arranged to lie within the buffer

that was partly filled with malicious code – When the caller of the vulnerable function returns, it will return

into the start of the malicious code section of the buffer

9

Spring, 2008


17

Off by One: Stack Frame The caller of the vulnerable

function ends up returning to a fake return address (inside buffer):

512 bytes of buffer[] received malicious code, plus a bogus stack frame, from the keyboard, as hex strings

Byte 513 from the keyboard was the new lowest byte of the valid saved EBP (lowest because the x86 is a little-endian machine), making the caller’s stack frame be inside buffer[]

Spring, 2008


18

Off by One: Real Examples

Nestea IP frame off-by-one denial of service attack: http://www.insecure.org/sploits/linux.PalmOS.nestea.html

Linux fileutils “ls” command off-by-one memory exhaustion attack (system crashes): http://www.linuxsecurity.com/content/view/105485/105/ (registration required)

Middleman printer proxy server Linux attack: http://www.linuxdevcenter.com/pub/a/linux/2003/01/13/insecurities.html#mid

10

Spring, 2008


19

Second Generation Exploit: Function Pointer Overwriting A system utility could have a function pointer to a

callback function, declared after a buffer (Szor, Listing 10.5)

Overflowing the buffer overwrites the function pointer

By determining the address of system() on this machine, an attacker can cause system() to be called instead of the callback function

Macromedia Flash example: http://www.securiteam.com/windowsntfocus/6W00J00EKQ.html

Spring, 2008


20

Third Generation Exploits: Format String Attacks Many C library functions produce formatted output

using format strings (e.g. printf, fprintf, wprintf, sprintf, etc.)

These functions permit strings that have no format control to be printed (unfortunately):

char buffer[13] = “Hello, world!”; printf(buffer); /* Bad programmer! */

printf(“%s”, buffer); /* Correct coding style */

The non-standard approach creates the possibility that an attacker will pass a format string rather than a string to print, which can be used to write to memory

11

Spring, 2008


21

Format String Attacks: Example void vuln(char buffer[256]) { printf(buffer); /* Bad; good: printf(“%s”,buffer) */ } int main(int argc, char *argv[]) { char buffer[256] = “”; /* allocate buffer */ if (2 == argc) strncpy(buffer, argv[1], 255); /* copy command line */ vuln(buffer); return 0; }

What if the user passes %X on the command line?

Spring, 2008


22

Format String Attacks: Example

If the user passes %X on the command line, then printf() will receive a pointer to a string with “%X” in it on the stack

Printf() will see the %X and assume there is another parameter above it on the stack

Whatever is above it on the stack will be printed in hexadecimal

Difference between correct and incorrect uses of printf() is seen in next diagram

12

Spring, 2008


23

Example: Uses of printf()

Immediately after the call to printf(), before the prologue code in printf():

Spring, 2008


24

Format String Attacks: Example

In the bad code, whatever is above %X on the stack will be printed in hexadecimal: the return address 401064 – Attacker can use %X%X%X, etc., to display the stack

contents and figure out return addresses, etc.

An attacker who can use an interactive utility can determine the exact address where his malicious code will be placed, where the return address is, and therefore what value to use to overwrite the return address

13

Spring, 2008


25

Positioning Within the Stack If an attacker wants to skip over 8 bytes in the

stack, he can supply 8 %x fields in the format string on the command line:

myprog.exe %x%x%x%x%x%x%x%x%s

The format string causes 8 ints to be printed off the stack in hex, unsing the %x specifiers, then prints a string (using %s) starting at the next stack position

Can also be specified with the “dot byte-count” specifier:

myprog.exe %.8x%s /* Shorter; still prints a lot of garbage */ Most Unix C compiler libraries allow the $ flag to

position directly: myprog.exe %8$s /* skips 8 bytes on stack, then %s */

Spring, 2008


26

Overwriting Within the Stack The format string can also be used to

force printf() to write to memory: printf(“foobar%n”, &nBytesWritten);

/* Prints “foobar”, writes 6 to nBytesWritten */

Attacker can supply address to write to:

myprog.exe 0x12FE7C%x%x%n

This causes the example program to execute the following printf():

printf(“%x%x%n”, 0x12FE7C);

How does this work?

14

Spring, 2008


27

Overwriting the Stack cont. When program is

invoked: myprog.exe 0x12FE7C%x%x%n

The stack will be (immediately after call to printf()):

Compiler pushes ptr to buffer on stack as only arg to printf(); also on stack as arg to vuln()

buffer itself is on stack when pushed by main() before calling vuln()

Spring, 2008


28

Overwriting the Stack cont.

The stack looks like it would if we had this code:

printf(“%x%x%n”,0x12FE7C);

The number of bytes printed (%n) is written to the pointer address given (0x12FE7C)

This causes “2” to overwrite the return address; not the value we want

15

Spring, 2008


29

Writing an Arbitrary Value on the Stack

The byte count can be made to equal the malicious code address that the attacker wants to write:

myprog.exe 0x12FE7C%.622404x%.622400x%n

622404 + 622400 = 1,244,804 = 0x12FE84, which is the address of buffer[] in our example

To avoid dumping a megabyte of junk, use the $ specifier:

myprog.exe 0x12FE7C%1244804$x%n

Spring, 2008


30

Writing an Arbitrary Value cont.

Modern C libraries do not permit huge width specifiers, so 0x12FE84 cannot be written using a single %n field

An attacker can work around this defense by writing 0x12FE84 as three separate bytes: 0x12, 0xFE, and 0x84, to three consecutive byte locations that overwrite the old return address, using three %n fields on the command line

Only works on a machine such as the x86 that permits unaligned byte stores to memory

16

Spring, 2008


31

Third Generation Exploit: Heap Management

A heap allocation (e.g. via malloc()) allocates a small control block, with pointer and size fields, just before the memory that is allocated

An attacker can underflow the heap memory allocated (in the absence of proper bounds checking, or with pointer arithmetic) and overwrite the control block

The heap management software will now use the overwritten memory pointer info in the control block, and can thus be redirected to write to arbitrary memory addresses

Spring, 2008


32

Third Generation Exploits: Input Validation Failures There are numerous ways in which an

application program can fail to validate user input

We will examine the two failures that are most important in the Internet age: – URL encoding and canonicalization – MIME header parsing

17

Spring, 2008


33

Third Generation Exploit: URL Encoding and Canonicalization The following URLs represent the same

image file: http://domain.tld/user/foo.gif http://domain.tld/user/bar/../foo.gif

Canonicalization converts URLs into a standard form (e.g. the second URL above would be converted to the first form)

Szor, p. 385: “A URL canonicalization vulnerability occurs when a security decision is based on a URL and not all of the URL representations are taken into account.”

Spring, 2008


34

URL Encoding and Canonicalization

Suppose a web server only allows external access to the /user subdirectories, but does not canonicalize URLs before checking them:

http://domain.tld/user/index.html // legal http://domain.tld/passwords.txt // illegal http://domain.tld/user/../passwords.txt // canonicalization

exploit

After many such exploits, server software began searching for “..” and converting URLs to canonical form

However, character encoding permitted canonicalization exploits to continue

18

Spring, 2008


35

URL Character Encoding Most web servers, such as Microsoft IIS, support

UTF-8 charset encoding; e.g. %2F represents a forward slash

Encoding rules: 0- 7 bits input xxxxxxx becomes 0xxxxxxx 8-11 bits input xxxxxxxxxxx becomes 110xxxxx 10xxxxxx 12-16 bits input xxxx…xxxxx becomes 1110xxxx 10xxxxxx 10xxxxxx 17-21 bits input xxxx…xxxxx becomes 11110xxx 10xxxxxx (2x more)

It is easy enough for the server to spot %2F and recognize a forward slash, but %2F can be encoded via the 8-11 bits format as %C0%AF:

http://domain.tld/user/..%C0%AFpasswords.txt // No longer looks like ../ is present, but it is!

Spring, 2008


36

URL Character Encoding cont.

Simple encoding problem was easily fixed in web servers, but multilevel encoding is possible:

%255c is not recognized as a backslash by the security checker.

After one round of decoding, %255c becomes %5c, because %25 is a code for the percent sign itself: %25 %

The result, %5c, would be flagged as a backslash by the security checker if it had been present initially; it was only searching for ‘%5c’ or ‘\’

One more round of decoding will be invoked by the server, because it sees the % sign, and %5c will become a backslash (useful in Windows path names); after the encoding exploit has passed the security checker, the web page server will serve the page (unfortunately!)

19

Spring, 2008


37

URL Character Encoding cont. Web servers such as Microsoft IIS have been

patched to fix this vulnerability Before the patch, the W32/Nimda worm used this

trick to backtrack into the root directory and use cmd.exe to copy itself over the web to the server and execute itself.

Spring, 2008


38

Third Generation Exploit: MIME Header Parsing

An email can have embedded or attached MIME files

Outlook and other email clients often use Internet Explorer to parse the MIME files

A MIME file type can be associated with an application and passed automatically to it, e.g. audio/x-wav files can be associated in Windows with Windows Media Player, so such a file would be sent by Internet Explorer directly to its associated application

20

Spring, 2008


39

Third Gen. Exploit: MIME Header Parsing cont. Vulnerability: Internet Explorer (before being fixed: http://

www.microsoft.com/technet/security/bulletin/MS01-020.mspx) would determine that the attachment should be opened automatically by an application, but would then allow the file extension to take priority in determining what application to use

Exploit: Make an attachment of MIME type audio/x-wav, for example, but make the attachment file name be virus.exe. The MIME type causes Internet Explorer to make the decision to open it automatically (even though the Outlook email client might have settings that should prevent opening *.exe files). Then, the *.exe extension causes Internet Explorer to pass it to the OS to execute.

Vulnerability fixed in 2001 (Internet Explore 5.x). – Not before W32/Badtrans and W32/Klez could exploit it.

Spring, 2008


40

Miscellaneous Vulnerabilities Mistakes by system administrators, users, bad

default security levels in applications software or firewalls, etc., can all create vulnerabilities

Most exploits (including all three generations) are referred to as blended attacks, because there is always a mixture of an exploit and a particular type of malicious code; e.g. overflowing a buffer is an exploit, but depositing a virus and running it is the second stage of the blended attack

We will review a couple of examples of vulnerabilities that are not based on source code

21

Spring, 2008


41

System Administration Vulnerabilities

Failure to provide secure utilities (e.g. SSL/SSH remote login utilities were not commonly used a decade ago)

Loose file system access rights and user privilege levels (many users have no idea that everyone can read many of their files)

Errors in firewall configuration (Szor, sec. 14.3) – Allows attackers unauthorized access – Permits denial of service attacks to continue instead of

excluding the flood of packets

Spring, 2008


42

User Behavior Vulnerabilities

Poor password selection – Too short; all alphabetic; common words – 1988 Morris worm used a list of only 432 common

passwords, and succeeded in cracking many user accounts all over the internet

– This was the main reason the worm spread more than the creator thought it would; he did not realize that password selection was that bad!

Opening executable email attachments

22

Spring, 2008


43

Vulnerabilities: Do We Ever Learn?

All of the vulnerabilities discussed have been known for years – Buffer overflow attacks were first discussed over 40 years

ago!

Yet, the number of exploits is increasing – 323 buffer overflow vulnerabilities reported in 2004 to the

national cyber-security vulnerability database (http://nvd.nist.gov/)

– 331 buffer overflow vulnerabilities reported in just the first 6 months of 2005!

Spring, 2008


44

Avoiding Vulnerabilities Good password selection

– Some newer systems even allow pass phrases, i.e. multiple words with punctuation or blanks between

– System should try its own dictionary attack and not permit you to choose a password that can be defeated

Don’t store a password unencrypted anywhere in a system, even in a temporary variable in a program

Don’t open executable email attachments Review access permissions throughout your file

directory structure Display and review your firewall settings

23

Spring, 2008


45

Avoiding Vulnerabilities cont. Good coding style

– Use only the good form of printf(); never use printf(buffer) for any function in the printf family

– Review loop bounds for off-by-one errors – Avoid unsafe C functions (e.g. strcpy(), strcat(), sprintf(), gets(),

scanf()) and learn how to use alternatives (e.g. strncpy(), strncat(), snprintf())

– Insert bounds checking code – Avoid unsafe programming languages (C, C++) and use more

modern, safe languages wherever possible (Java, Ada, C# in managed mode)

We will look at some coding style pointers from Building Secure Software by Viega and McGraw

Spring, 2008


46

Safe and Unsafe Coding

Unsafe: void main() {

char buf[1024];

gets(buf); /* Won’t stop at 1024 bytes !! */

}

Safe: #define BUFSIZE 1024

void main() {

char buf[BUFSIZE];

fgets(buf, BUFSIZE, stdin);

}

24

Spring, 2008


47


Unsafe: strcpy(dst, src); /* What prevents buffer overflow? */

Safe: #define DSTSIZE 1024

char dst[DSTSIZE];

:

:

strncpy(dst, src, DSTSIZE – 1); /* Leave room for null term */

dst[DSTSIZE – 1] = ‘\0’; /* Null terminate the string. */

Spring, 2008


48


Unsafe: strcpy(dst, src); /* What prevents buffer overflow? */

Safe: /* Another way to fix the problem: */

dst = (char *) malloc(strlen(src) + 1);

if (NULL == dst) {

/* handle error here, abort */

}

strcpy(dst, src);

25

Spring, 2008


49


Unsafe: strcat(dst, src);

/* Enough room left in dst to catenate src? */

Safe: strncat(dst, src, DSTSIZE – strlen(dst) - 1);

Spring, 2008


50

Safe and Unsafe Coding Unsafe: int main(int argc, char *argv[]) { char usage[1024]; /* Big enough for a valid file name …

right? */ sprintf(usage, “USAGE: %s –f flag [arg1]\n”, argv[0]); return 0; }

Safe: int main(int argc, char *argv[]) { char usage[1024]; char format_string = “USAGE: %s –f flag [arg1]\n”; snprintf(usage, 1024, format_string, argv[0]); return 0; }

See explanation on next slide

26

Spring, 2008


51

Safe and Unsafe Coding: sprintf()

Vulnerability: int main(int argc, char *argv[]) { char usage[1024]; /* Can this be overflowed? */ sprintf(usage, “USAGE: %s –f flag [arg1]\n”, argv[0]); /* How long can a filename be, in argv[0]? What if the

filename is not a legitimate name from the OS? See exploit below. */

return 0; }

Exploit: int main(int argc, char *argv[]) { execl(“/path/to/above/program”, [very long string here], NULL); /* Starts program in 1st arg, passes 2nd arg as argv[0] to that program. Bad news! */ return 0; }

Spring, 2008


52

Safe and Unsafe Coding: sprintf()

Problem: snprintf() is not part of all C libraries

Solutions: – Package a working snprintf() with your software – Use a width limit specifier in sprintf(): sprintf(usage, “USAGE: %.1000s –f flag [arg1]\n”,argv[0]);

Unfortunately, the width limit specifier %.1000s is not standard across all libraries, either

27

Spring, 2008


53


Unsafe: void main(int argc, char *argv[]) {

char buf[256]; sscanf(argv[0], “%s”, &buf); /* Won’t stop at 256

bytes */ }

Safe: void main(int argc, char *argv[]) { char buf[256];

sscanf(argv[0], “%255s”, &buf); /* Width limit specifier */

}

Spring, 2008


54


Each of the example applies to a family of library functions

For example, scanf(), sscanf(), fscanf(), and vfscanf() all have the same coding vulnerabilities

The safe style shown in our examples can be easily adapted to other members of the same family

28

Spring, 2008


55

Compiler-Based Prevention One approach: Modify the C language itself

with a new compiler and runtime library, as in the Cyclone variant of C: http://www.research.att.com/projects/cyclone/ – Overhead for bounds checking, garbage collection, library

safeguards, etc., ranges from negligible to >100% for the worst cases

Another approach: leave the language alone, but modify the compiler to emit stack and/or buffer overflow safeguards in the executable – Examples we will see: StackGuard, ProPolice, and

StackShield

Spring, 2008


56

StackGuard: Stack Canaries

StackGuard inserts a marker in between the frame pointer and the return address on the stack – Marker is called a canary, as in the “canary in the

coal mine”

If a buffer overflow overwrites the stack all the way to the return address, it will also overwrite the canary

Before returning, the canary is examined for modification

29

Spring, 2008


57

Stack Canary Operation

Overflowing buffer[] tramples on canary

Does not prevent trashing the EBP, local function or file pointers, etc.

Canary value: NUL-CR-LF-EOF; very difficult to write out from a string

Spring, 2008


58

ProPolice: Better Stack Canaries and Frame Layout ProPolice (a.k.a. SSP, Stack-Smashing

Protector) from IBM makes a couple of major improvements to StackGuard – Canary is placed below the saved EBP to protect

it – The stack frame layout is rearranged so that non-

array locals, such as function pointers and file pointers, are placed below arrays, so that overflowing the arrays cannot reach the pointers

30

Spring, 2008


59

Stack Canary Limitations

Stack canaries only guard against a direct attack on the stack, e.g. overwriting a portion of the stack directly from its neighboring addresses

We saw that a format-string attack is indirect: it computes the location of the return address, then overwrites just that address and does not overflow from neighboring addresses – Hence, it does not overwrite a canary

Spring, 2008


60

StackShield: Protecting Return Addresses

StackShield is a Linux/gcc add-on that modifies the ASM output from gcc to maintain a separate data segment with return addresses

Removing the return addresses from the data stack prevents both direct and indirect data attacks on the return address

Also computes the range of valid code addresses and performs a range check on all function calls and returns – A call to, or return into, a data area will be detected as

invalid because of the address range

31

Spring, 2008


61

Operating System Defenses

Don’t allow execution in the stack – Exploit could still execute code from the heap or

other global data area

Instead of read and write permission bits on pages, add an execute permission bit and set it to false on all data pages (heap, stack, etc.) – This is supported in hardware on the Intel x86-64

architecture and in the version of Microsoft Windows XP that runs on it

Spring, 2008


62

Phoenix and SDT Defenses SDT overhead for security checks is usually

lower than for the compiler-based tools described – Some security checks only need to be done once, when the

code fragment is loaded into the fragment cache, not every time it is executed

Phoenix instrumentation can accomplish the exact same things as the compiler-based tools we have studied

State of the art compiler analyses can often prove that a buffer will not overflow, allowing elimination of costly bounds checking code

32

Spring, 2008


63

Assignments Read Szor, Chapter 10; Section 13.2;

Section 13.3.4; Section 14.3 Start programming assignment 6

(Guarding the Stack with Phoenix) Study for Exam 3

Spring, 2008


64

Exam 3 Review Read Szor:

– Chapter 7 (Encrypted, oligomorphic, etc. viruses) – Chapter 10 (Vulnerabilities and exploits) – Section 13.2 (Preventing buffer overflow attacks) – Section 13.3.4 (Return-to-libc attack prevention) – Section 14.3 (Firewall protection) – Chapter 15 (Anti-virus analysis procedures)

Review Phoenix/SSA slides and assignments

Review SDT/Strata slides

exploits

Technology

buffer buffer

buffer address

frame return address

heap return addresses

fixedlength buffer key

example code

dark arts vulnerabilities

global heap