CS 4803 Computer and Network SecurityAlexandra (Sasha) BoldyrevaApplication-level security. Buffer overflows. Malicious code. Worm and viruses.1Application-level security•I.e., programming-language security•Previous focus was on protocols and algorithms to prevent attacks•Are they implemented correctly?•Here, focus is on programming errors and how to deal with them•Reducing/eliminating/finding errors•Containing damage resulting from errors2Classifying flaws•Intentional flaws•E.g., “backdoors”•Unintentional flaws•E.g., programmer errors3Buffer overflows•50% of reported vulnerabilities•Overflowing a buffer results in data written elsewhere:•User’s data space/program area•System data/program code• Including the stack, or memory heap4Stack Buffers•Suppose Web server contains this functionvoid func(char *str) { char buf[126]; strcpy(buf,str); }•When this function is invoked, a new frame with local variables is pushed onto the stackAllocate local buffer(126 bytes reserved on stack)Copy argument into local bufferTop ofstackStack grows this waybuf sfpretaddrstrLocal variablesFrame of thecalling functionExecute code at this address after func()finishesArgumentsPointer topreviousframe5What If Buffer is Overstuffed?•Memory pointed to by str is copied onto stack…void func(char *str) { char buf[126]; strcpy(buf,str); }•If a string longer than 126 bytes is copied into buffer, it will overwrite adjacent stack locationsstrcpy does NOT check whether the string at *str contains fewer than 126 charactersbufstrThis will beinterpretedas return address!overflowTop ofstackFrame of thecalling function6Executing Attack Code•Suppose buffer contains attacker-created string•When function exits, code in the buffer will be executedcodestrFrame of thecalling functionretAttacker puts actual assembly instructions into his input string, e.g.,binary code of execve(“/bin/sh”)In the overflow, a pointer backinto the buffer appears inthe location where the systemexpects to find return addressTop ofstack7Problem: No Range Checking•strcpy does not check input size• strcpy(buf, str) simply copies memory contents into buf starting from *str until “\0” is encountered, ignoring the size of area allocated to buf•Many C library functions are unsafe8Home-brewed range-checking string copy void notSoSafeCopy(char *input) { char buffer[512]; int i; for (i=0; i<=512; i++) buffer[i] = input[i]; } void main(int argc, char *argv[]) { if (argc==2) notSoSafeCopy(argv[1]); }Off-By-One Overflow1-byte overflow: can’t change RET, but can change pointer to previous stack frameThis will copy 513characters intobuffer. Oops!9Finding buffer overflows•Hackers find buffer overflows as follows:•Run web server on local machine•Issue requests with long tags.All long tags end with “$$$$$”•If web server crashes:search core dump for “$$$$$” to find overflow location.10Addressing buffer overflows•Basic stack exploit can be prevented by marking stack segment as non-executable, or randomizing stack location.•Code patches exist for Linux and Solaris.•Problems:•Some apps need executable stack (e.g. LISP interpreters).•Does not block more general overflow exploits• Patch not shipped by default for Linux and Solaris11Run-time checking: StackGuard•Embed “canaries” in stack frames and verify their integrity prior to function returnstrretsfplocaltopofstackcanarystrretsfplocal canaryFrame 1Frame 212Run-time checking: Libsafe•Intercepts calls to strcpy (dest, src)•Validates sufficient space in current stack frame•If enough space, does strcpy. Otherwise, terminates application13More methods …• Address obfuscation•Encrypt return address on stack by XORing with random string. Decrypt just before returning from function.•Attacker needs decryption key to set return address to desired value.14Preventing Buffer Overflow•Use safe programming languages, e.g., Java• What about legacy C code?•Mark stack as non-executable•Make buffers (slightly) longer than necessary to avoid “off-by-one” errors•Randomize stack location or encrypt return address on stack by XORing with random string• Attacker won’t know what address to use in his string•Static analysis of source code to find overflows•Run-time checking of array and buffer bounds• StackGuard, libsafe, many other tools•Black-box testing with long strings15Viruses/malicious code16Viruses/malicious code•Virus – passes malicious code to other non-malicious programs•Or documents with “executable” components•Trojan horse – software with unintended side effects•Worm – propagates via network•Typically stand-alone software, in contrast to viruses which are attached to other programs17Viruses•Can insert themselves before program, can surround program, or can be interspersed throughout program•In the last case, virus writer needs to know about the specifics of the other program•Two ways to “insert” virus:•Insert virus in memory at (old) location of original program•Change pointer structure…18Viruses…•Boot sector viruses•If a virus is loaded early in the boot process, can be very difficult (impossible?) to detect•Memory-resident viruses•Note that virus might complicate its own detection•E.g., removing virus name from list of active programs, or list of files on disk19Some examples•BRAIN virus•Locates itself in upper memory; resets the upper memory bound below itself•Traps “disk reads” so that it can handle any requests to read from the boot sector•Not inherently malicious, although some variants were20Morris worm (1988)•Resource exhaustion (unintended)•Was supposed to have only one copy running, but did not work correctly…•Spread in three ways• Exploited buffer overflow flaw in fingerd• Exploited flaw in sendmail debug mode• Guessing user passwords(!) on current network•Bootstrap loader would be used to obtain the rest of the worm21Chernobyl virus (1998)•When infected program run, virus becomes resident in memory of machine•Rebooting does not help•Virus writes random garbage to hard drive•Attempts to trash FLASH BIOS•Physically destroys the hardware…22Melissa virus/worm (1999)•Word macro…•When file opened, would create and send infected document to names in user’s Outlook