1 / 65

Chapter 6 Implementation Security

Chapter 6 Implementation Security. Sue Fitzgerald Metropolitan State University CS 328 Computer Security Fall 2008. Overview. Computer security threats related to code Unintentional: Buggy implementations Faulty installation and/or configuration Software not used as intended

favian
Download Presentation

Chapter 6 Implementation Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 6 Implementation Security Sue Fitzgerald Metropolitan State University CS 328 Computer Security Fall 2008

  2. Overview • Computer security threats related to code • Unintentional: • Buggy implementations • Faulty installation and/or configuration • Software not used as intended • Intentional (malicious code): • Trojan horses • Trap doors • Viruses • Worms

  3. Common Security/Programming Mistakes • Buffer overflow • Integer overflow • Other malicious inputs • Race conditions • Malware • Insecure programming languages • Insecure software development life cycle

  4. Buffer Overflows • Oldest, most common vulnerability • Program stack provides temporary working space for the running program int add(int A1, int A2) { int L1, L2; /* local variables L1, L2 */ L1 = A1 + A2; return(L1); /* return value */ } int main() { x = add(10,20); }

  5. Stack frames main add Stack Stack Frames

  6. Stack Frames (cont) • A stack frame contains: • Arguments • Return address of next instruction to execute upon return from subroutine • Saved registers • Local variables

  7. Stack Frames (cont) • The main routine calls add: • add’s arguments are first pushed onto the stack • the return address (the next instruction in main to execute after add finishes) is pushed • control is transferred to add

  8. Stack Frames (cont) • add’s stack frame :

  9. A Buffer Overflow int copy(char *s) /* subroutine “copy” */ { char buffer[10]; /* local variable*/ strcpy(buffer,s); } int main() /* main program */ { char name[]=”ABCDEFGHIJKLMNOPQR”; /* 18 chars */ add(name); /* call to subroutine “add” */ } Tjaden

  10. A Buffer Overflow (continued) • copy’s stack frame after prologue:

  11. A Buffer Overflow (continued) • Stack after execution of copy (but before the return):

  12. A Buffer Overflow (continued) • The string overflowed copy’s buffer: • It overwrote the return address with ‘OPQR’ (0x4F505152) • When copy finishes, control will be transferred to the instruction at address 0x4F505152 - error! • The Morris worm sent a specially crafted 243-byte string to the finger daemon: • Overflowed a buffer and overwrote the return address • The fingerd executedthe /bin/sh program which executed the grappling hook code Tjaden

  13. When Does Buffer Overflow Occur? • Code accepts input from user, remote program, another procedure • Procedure does not check inputs • Input is longer than buffer • C# and Java throw a runtime exception • C does not – assumes strings end with zero – and keeps on copying • Problems with strcpy() and gets()

  14. Memory • Text segment – where program instructions go • Data segment – where global variables and data whose size is known at compile time go • Heap – where dynamic data structures go • Libraries – previously compiled, standard code linked into programs • Stack - space for temporary variables associated with current procedure

  15. Stack Smashing • Classic buffer overflows inject code directly into the stack, then ‘return’ to that code instead of the calling procedure • The code runs with the victim’s process identity and privileges • Traditionally called ‘shellcode’

  16. Stack Smashing (continued) • return-to-libc attack • Injected return address returns to a library function (such as system()) with nasty fake arguments • Instead of overwriting the return address, the stack overflow could replace (or view) important data instead

  17. Structure of the Exploit • Replace the return address by copying the bogus return address into many locations on the stack via a buffer overflow • Payload – bad instructions, also loaded as part of the buffer overflow

  18. Structure of the Exploit (continued) • NOP sled – pad the buffer with NOPs in case the return address is close but not 100% accurate; slide down the NOPS to the bad code • Injected code cannot contain a zero – since this is interpreted as the end of the string

  19. Heap Smashing • Same as stack smashing except buffer overflow occurs in the heap (dynamic data structures) rather than the stack • Heaps are organized into blocks with data structure linking information in the header of each block • Header information is overwritten

  20. Defenses • Design operating system to prevent code from executing from the stack • Still leaves the heap vulnerable • Make writable pages non-executable – if a program can write to that part of memory, that part of memory cannot be used to store and run code • Still leaves open the possibility of changing data on stack

  21. Defenses (continued) • Canaries • put a known value on the the stack just in front of the return address • if the canary changes, assume a stack overflow occurred

  22. Defenses (continued) • Address space randomization (ASR) • the compiler shuffles the order in which the arguments and return address are stored on the stack • makes it harder for the attacker to find and overwrite the return address

  23. Defenses (continued) • Code examination • code reviews • manually read through code for known security holes • a very large job • code scanner • automatically reads through code for known security holes • lots of false positives • combined approach

  24. Input Validation • Never assume • Inputs • network-facing – listening sockets • user-facing – GUI text boxes, command line inputs • parameters sent to system library functions • Attacker simply starts with large amounts of random data • Always validate inputs

  25. Format Strings • C language printf() • Allows users to view the stack • Allows users to cause a buffer overflow

  26. Unsigned Integer Overflow • Numbers are stored in a fixed number of bits • This limits the size of the number that can be stored • If two large (unsigned) numbers are added, the most significant bits are truncated and the number is wrong

  27. Unsigned Integer Underflow • If a large (unsigned) number is subtracted from a small number , the result would be negative • If you are using unsigned (positive only) numbers, the result would be incorrectly interpreted

  28. Type Conversion • The C language has several variations on integer data types • A long int may occupy 32 bits • A short int may occupy 16 bits • The most significant part of a large integer stored in a long int would be truncated if copied to a short int

  29. Signed vs. Unsigned Integers • A signed integer could hold a negative number • If copied to an unsigned integer, the number would be incorrectly interpreted

  30. Pointers • Pointers are variables that hold addresses • Assigning an integer number to a pointer variable or performing arithmetic on a pointer can result in a bad memory access • If you are lucky, your program will stop with a memory access error • If you are not lucky, you may spend months looking for the problem

  31. Pointers (continued) • If you are a bad guy, you can read or write parts of memory you should not have access to

  32. SQL Injection Attacks • Structured Query Language (SQL) is the commonly used database manipulation language • The single quote mark (‘) is used to delimit strings • Sample input: Alice select * from Users where name=‘Alice’

  33. SQL Injection Attacks (continued) • Malicious input: carlo’ or ‘1’ = ‘1 • Results in select * from Users where name=‘carlo’ or ‘1’ = ‘1’ • Since this statement is always true, login is permitted even if carlo is not a user

  34. Defense Against Injection • Validate the inputs • Escape the characters with special meanings select * from Users where name=‘carlo\’ or ‘\1\’ = ‘\1’

  35. Internal Validation • Every subroutine should check its inputs on every call • The success or failure of every subroutine should be checked when it returns a value

  36. Race Conditions • Time of check/Time of Use (TOCTOU) errors • Program checks a property of a resource, then assumes that property does not change in the time interval between the check and the use of the resource • Example: • User is authorized to access a file • User replaces the file with another between authorization and use

  37. Malware • Malicious code - programs specifically designed to undermine the security of a system • Trojan horses • Login spoof • Root kits • Trap doors • Viruses and rabbits • Virus scanning • Macro viruses • Worms • The Morris worm • Logic bombs and Easter eggs

  38. Trojan Horses • History – a hollow wooden horse used by the Greeks during the Trojan War • Today - a Trojan horse is a program that has two purposes: one obvious and benign, the other hidden and malicious • Examples: • Login spoof • Mailers, editors, file transfer utilities, etc. • Compilers

  39. Trojan Horse Example • Root kits • A root kit is collections of Trojan Horse programs that replace widely-used system utility programs: • ls and find (hides files) • ps and top (hides processes) • netstat (hides network connections) • Goal: conceal the intruder’s presence and activities from users and the system administrator

  40. Trap Doors • Trap doors are flaws that designers place in programs so that specific security checks are not performed under certain circumstances • Example: a programmer developing a computer-controlled door to a bank’s vault • After the programmer is done the bank will reset all of the access codes to the vault • However, the programmer may have left a special access code in his program that always opens the vault

  41. Viruses • A virus is a fragment of code created to spread copies of itself to other programs • Requires a host (typically a program): • In which to live • From which to spread to other hosts • A host that contains a virus is said to be infected • A virus typically infects a program by attaching a copy of itself to the program • Goal: spread and infect as many hosts as possible

  42. Viruses (continued) • Virus may prepend its instructions to the program’s instructions • Every time the program runs the virus’ code is executed • Infection propagation – mechanism to spread infection to other hosts • Manipulation routine – (optional) mechanism to perform other actions: • Displaying a humorous message • Altering stored data or deleting files • Killing other running programs • Causing system crashes

  43. Viruses (continued) Tjaden

  44. Defenses • Virus scanning programs check files for signatures of known viruses • Signature = some unique fragment of code from the virus that appears in every infected file • Problems: • Polymorphic viruses that change their appearance each time they infect a new file • No easily recognizable pattern common to all instances of the virus • New viruses (and modified old viruses) appear regularly • Database of viral signatures must be updated frequently

  45. Macro Viruses • More than just programs can serve as hosts for viruses • Examples:spreadsheet and word processor programs • Usually include a macro feature that allows a user to specify a series of commands to be executed • Macros provide enough functionality for a hacker to write a macro virus: • Executed every time an infected document is opened • Has an infection propagation mechanism • May have a manipulation routine • Example: Microsoft Word: • AutoOpen macro – run automatically whenever the document containing it is opened • AutoClose macro – run automatically whenever the document containing it is closed

  46. The Melissa Macro Virus • Appeared in March, 1999 • Exploited Microsoft Word macros • Spread by e-mail: • Victim received an e-mail message with the subject line “Important Message From NAME” • Infected Word document as an attachment: • When an infected document was opened: • Virus attempted to infect other documents • E-mail a copy of an infected document to up to fifty other people • E-mail addresses of the new victims were taken from a user’s Outlook address book • Value to use for NAME in the subject line was read from the Outlook settings

  47. Melissa (continued) • In three days, infected more than 100,000 computers • Some sites received tens of thousands of e-mail messages in less than an hour • Mail server crashes • System performance degradation • Besides spreading the virus: • Modified the settings in Microsoft Word to conceal its presence • Occasionally modified the contents of the documents that it infected • Occasionally sent sensitive documents without the owner's knowledge

  48. Worms • Virus = a program fragment • Worm = a stand-alone program that can replicate itself and spread • Worms can also contain manipulation routines to perform other actions: • Modifying or deleting files • Using system resources • Collecting information

  49. The Morris Worm • Appeared in November, 1988 • Created by a Computer Science graduate student • Brought down thousands of the ~60,000 computers then attached to the Internet • Academic, governmental, and corporate • Suns or VAXes running BSD UNIX

  50. Morris Worm (continued) • Used four different attack strategies to try to run a piece of code called the grappling hook on a target system • When run, the grappling hook: • Made a network connection back to the infected system from which it had originated • Transferred a copy of the worm code from the infected system to the target system • Started the worm running on the newly infected system

More Related