• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Exploits
 

Exploits

on

  • 669 views

 

Statistics

Views

Total Views
669
Views on SlideShare
669
Embed Views
0

Actions

Likes
1
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Exploits Exploits Document Transcript

    • presentations Exploits and Vulnerabilities Spring, 2008 CS 351 Defense Against the Dark Arts Vulnerabilities and Exploits   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 2 Spring, 2008 1
    • CS 351 Defense Against the Dark ArtsVarieties 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 on3 Spring, 2008CS 351 Defense Against the Dark ArtsClassifying 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 lengthy4 Spring, 2008 2
    • CS 351 Defense Against the Dark ArtsFirst Generation Exploits   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 vulnerability5 Spring, 2008CS 351 Defense Against the Dark ArtsStack Buffer Overflow Example 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 }6 Spring, 2008 3
    • CS 351 Defense Against the Dark ArtsStack Buffer Overflow cont’d.  In the stack frame for bogus(), buffer[257] would fall on top of the return address:7 Spring, 2008CS 351 Defense Against the Dark ArtsStack Buffer Overflow cont’d.   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 it8 Spring, 2008 4
    • CS 351 Defense Against the Dark ArtsStack Buffer Overflow cont’d.   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 it9 Spring, 2008CS 351 Defense Against the Dark ArtsStack Buffer Overflow cont’d.  bogus() is now “returning” to buffer[0]10 Spring, 2008 5
    • CS 351 Defense Against the Dark ArtsSecond Generation Exploits: Heap BufferOverflow   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; }11 Spring, 2008CS 351 Defense Against the Dark ArtsSecond Generation Exploits: Heap BufferOverflow 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 overwritten12 Spring, 2008 6
    • CS 351 Defense Against the Dark ArtsCase 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 overwritten13 Spring, 2008CS 351 Defense Against the Dark ArtsSlapper: 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 details14 Spring, 2008 7
    • CS 351 Defense Against the Dark ArtsSecond 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?15 Spring, 2008CS 351 Defense Against the Dark ArtsOff 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 buffer16 Spring, 2008 8
    • CS 351 Defense Against the Dark ArtsOff 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[]17 Spring, 2008CS 351 Defense Against the Dark ArtsOff 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#mid18 Spring, 2008 9
    • CS 351 Defense Against the Dark ArtsSecond Generation Exploit: FunctionPointer 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.html19 Spring, 2008CS 351 Defense Against the Dark ArtsThird Generation Exploits: Format StringAttacks  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 memory20 Spring, 2008 10
    • CS 351 Defense Against the Dark ArtsFormat 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?21 Spring, 2008CS 351 Defense Against the Dark ArtsFormat 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 diagram22 Spring, 2008 11
    • CS 351 Defense Against the Dark ArtsExample: Uses of printf()  Immediately after the call to printf(), before the prologue code in printf():23 Spring, 2008CS 351 Defense Against the Dark ArtsFormat 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 address24 Spring, 2008 12
    • CS 351 Defense Against the Dark ArtsPositioning 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 */25 Spring, 2008CS 351 Defense Against the Dark ArtsOverwriting 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?26 Spring, 2008 13
    • CS 351 Defense Against the Dark ArtsOverwriting 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()27 Spring, 2008CS 351 Defense Against the Dark ArtsOverwriting 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 want28 Spring, 2008 14
    • CS 351 Defense Against the Dark ArtsWriting 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%n29 Spring, 2008CS 351 Defense Against the Dark ArtsWriting 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 memory30 Spring, 2008 15
    • CS 351 Defense Against the Dark ArtsThird 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 addresses31 Spring, 2008CS 351 Defense Against the Dark Arts 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 parsing32 Spring, 2008 16
    • CS 351 Defense Against the Dark ArtsThird Generation Exploit: URL Encodingand 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.”33 Spring, 2008CS 351 Defense Against the Dark ArtsURL 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 continue34 Spring, 2008 17
    • CS 351 Defense Against the Dark ArtsURL 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!35 Spring, 2008CS 351 Defense Against the Dark ArtsURL 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!)36 Spring, 2008 18
    • CS 351 Defense Against the Dark ArtsURL 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.37 Spring, 2008CS 351 Defense Against the Dark ArtsThird 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 application38 Spring, 2008 19
    • CS 351 Defense Against the Dark ArtsThird 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.39 Spring, 2008CS 351 Defense Against the Dark ArtsMiscellaneous 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 code40 Spring, 2008 20
    • CS 351 Defense Against the Dark ArtsSystem 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 packets41 Spring, 2008CS 351 Defense Against the Dark ArtsUser 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 attachments42 Spring, 2008 21
    • CS 351 Defense Against the Dark ArtsVulnerabilities: 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!43 Spring, 2008CS 351 Defense Against the Dark ArtsAvoiding 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 settings44 Spring, 2008 22
    • CS 351 Defense Against the Dark ArtsAvoiding 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 McGraw45 Spring, 2008CS 351 Defense Against the Dark ArtsSafe 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); }46 Spring, 2008 23
    • CS 351 Defense Against the Dark ArtsSafe 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. */47 Spring, 2008CS 351 Defense Against the Dark ArtsSafe 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);48 Spring, 2008 24
    • CS 351 Defense Against the Dark ArtsSafe and Unsafe Coding   Unsafe: strcat(dst, src); /* Enough room left in dst to catenate src? */   Safe: strncat(dst, src, DSTSIZE – strlen(dst) - 1);49 Spring, 2008CS 351 Defense Against the Dark ArtsSafe 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 slide50 Spring, 2008 25
    • CS 351 Defense Against the Dark ArtsSafe 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; }51 Spring, 2008CS 351 Defense Against the Dark ArtsSafe 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, either52 Spring, 2008 26
    • CS 351 Defense Against the Dark ArtsSafe 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 */ }53 Spring, 2008CS 351 Defense Against the Dark ArtsSafe 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 family54 Spring, 2008 27
    • CS 351 Defense Against the Dark ArtsCompiler-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 StackShield55 Spring, 2008CS 351 Defense Against the Dark ArtsStackGuard: 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 modification56 Spring, 2008 28
    • CS 351 Defense Against the Dark ArtsStack 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 string57 Spring, 2008CS 351 Defense Against the Dark ArtsProPolice: Better Stack Canaries andFrame 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 pointers58 Spring, 2008 29
    • CS 351 Defense Against the Dark ArtsStack 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 canary59 Spring, 2008CS 351 Defense Against the Dark ArtsStackShield: 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 range60 Spring, 2008 30
    • CS 351 Defense Against the Dark ArtsOperating 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 it61 Spring, 2008CS 351 Defense Against the Dark ArtsPhoenix 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 code62 Spring, 2008 31
    • CS 351 Defense Against the Dark ArtsAssignments  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 363 Spring, 2008CS 351 Defense Against the Dark ArtsExam 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 slides64 Spring, 2008 32