Exploits
-
Upload
ken-sai -
Category
Technology
-
view
4.247 -
download
2
Transcript of 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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
7
Stack Buffer Overflow cont’d.
In the stack frame for bogus(), buffer[257] would fall on top of the return address:
Spring, 2008
CS 351 Defense Against the Dark Arts
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
Stack Buffer Overflow cont’d.
5
Spring, 2008
CS 351 Defense Against the Dark Arts
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
Stack Buffer Overflow cont’d.
Spring, 2008
CS 351 Defense Against the Dark Arts
10
Stack Buffer Overflow cont’d.
bogus() is now “returning” to buffer[0]
6
Spring, 2008
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
23
Example: Uses of printf()
Immediately after the call to printf(), before the prologue code in printf():
Spring, 2008
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
47
Safe and Unsafe Coding
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
CS 351 Defense Against the Dark Arts
48
Safe and Unsafe Coding
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
CS 351 Defense Against the Dark Arts
49
Safe and Unsafe Coding
Unsafe: strcat(dst, src);
/* Enough room left in dst to catenate src? */
Safe: strncat(dst, src, DSTSIZE – strlen(dst) - 1);
Spring, 2008
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
53
Safe and Unsafe Coding
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
CS 351 Defense Against the Dark Arts
54
Safe and Unsafe Coding
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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
CS 351 Defense Against the Dark Arts
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