co444h
play

CO444H Pointer analysis Ben Livshits 1 Approaches to Finding - PowerPoint PPT Presentation

Datalog CO444H Pointer analysis Ben Livshits 1 Approaches to Finding Reliability and Security Bugs Static Analysis Tools Black-box Testing/Fuzzing 2 Coverity: a Static Analysis Company 3 Bug Report From Coverity Actual bug Path


  1. Datalog CO444H Pointer analysis Ben Livshits 1

  2. Approaches to Finding Reliability and Security Bugs • Static Analysis Tools • Black-box Testing/Fuzzing 2

  3. Coverity: a Static Analysis Company 3

  4. Bug Report From Coverity Actual bug Path conditions report and context 4

  5. Architecture of an Analysis Platform

  6. 6 Bugs Detected by Coverity • Uninitialized variables • Null pointer dereference • Invalid use of negative • Use after free values • Double free • Passing large parameters by • Array indexing errors value • Mismatched array • Under-allocations of new/delete dynamic data • Potential stack overrun • Memory leaks • Potential heap overrun • File handle leaks • Network resource leaks • Return pointers to local • Unused values variables • Unhandled return codes • Logically inconsistent code • Use of invalid iterators

  7. 7 Coverity Checkers • Some coding patterns and some vulnerabilities are specific to the code base • Issues that apply to the Linux kernel are unlikely to apply in application software

  8. Example Checker: Missing Optional Arguments • Prototype for open() syscall: int open(const char *path, int oflag, /* mode_t mode */...); • Typical mistake: fd = open(“file”, O_CREAT); • Force setting explicit file permissions ! • Check: Look for oflags == O_CREAT without mode argument 8

  9. Example: chroot Protocol Checker • Goal: confine process to a “jail” on the filesystem • chroot() changes filesystem root for a process • Problem • chroot() itself does not change current working directory chroot() chdir(“/”) open(“../file”,…) Error if open before chdir

  10. Taint Checkers 10

  11. Sanitize Integers Before Use Warn when unchecked integers from untrusted sources reach trusting sinks Network copyin(&v, p, len) Syscall packet param v.tainted v.clean Use(v) memcpy(p, q, v) array[v] copyin(p,q,v) while(i < v) copyout(p,q,v) … ERROR Linux: 125 errors, 24 false; BSD: 12 errors, 4 false

  12. Looking for Locking Function Calls 12

  13. Missed Lower-bound Check /* 2.4.5/drivers/char/drm/i810_dma.c */ if(copy_from_user(&d, arg, sizeof(arg))) return – EFAULT; if(d.idx > dma->buf_count) return – EINVAL; buf = dma->buflist[d.idx]; Copy_from_user(buf_priv->virtual, d.address, d.used); • d is read from the user • Signed integer d.idx is upper-bound checked but not lower-bound checked • d.used is unchecked , allowing 2GB of user data to be copied into the kernel 13

  14. Remote Exploit /* 2.4.9/drivers/isdn/act2000/capi.c:actcapi_dispatch */ isdn_ctrl cmd; ... while ((skb = skb_dequeue(&card->rcvq))) { msg = skb->data; ... memcpy(cmd.parm.setup.phone, msg->msg.connect_ind.addr.num, msg->msg.connect_ind.addr.len - 1); • msg points to arbitrary network data • This can be used to overflow cmd and write data onto the stack 14

  15. 15 Example Code with Functions and Calls • We would want to reason about the flow of the input ( size ) and name provided by the user

  16. Call Graph for the Program main atoi exit free malloc say_hello fgets printf 16

  17. Control Flow Graph char * buf[8]; Represent logical structure of code in graph form if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END 17

  18. Path Traversal Conceptually Conceptually: Analyze each path through control graph separately char * buf[8]; Actually Perform some checking Actually computation once per node; combine paths at merge nodes if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END 18

  19. Apply Checking Null ll po poin inters Use Us e aft fter fr free Arr rray over errun char * buf[8]; See how three checkers are run for this path if (a) • Checker !a if (a && b) • Defined by a state diagram, with state !(a && b) transitions and error states delete [] b; *b = ‘x’; • Run Checker • Assign initial state to each program variable *a = *b; • State at program point depends on state at previous point, program actions END • Emit error if error state reached 19

  20. Apply Checking Null pointers Use after free Array overrun char * buf[8]; “ buf is 8 bytes” if (a) !a if (a && b) !(a && b) delete [] b; *b = ‘x’; *a = *b; END 20

  21. Apply Checking Null pointers Use after free Array overrun char * buf[8]; “ buf is 8 bytes” if (a) “a is null” !a if (a && b) !(a && b) delete [] b; *b = ‘x’; *a = *b; END 21

  22. Apply Checking Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) “a is null” !a if (a && b) Already knew !(a && b) a was null delete [] b; *b = ‘x’; *a = *b; END 22

  23. Apply Checking Null pointers Use after freeArray overrun char * buf[8]; “buf is 8 bytes” if (a) !a “a is null” if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; *a = *b; END 23

  24. Apply Checking Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) “a is null” !a if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; “b dereferenced!” *a = *b; END 24

  25. Apply Checking Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) “a is null” !a if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; “b dereferenced !” *a = *b; No more errors reported for b END 25

  26. False Positives • What is a bug? Something the user will fix. • Many sources of false positives • False paths • Idioms • Execution environment assumptions • Conditional compilation • “third party code” • Analysis imprecision • … 26

  27. A False Path char * buf[8]; if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END 27

  28. False Path Pruning Branch Disequality Integer Range char * buf[8]; if (a) !a if (a && b) a && b buf[8] = a; END 28

  29. False Path Pruning Branch Disequality Integer Range char * buf[8]; if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) a && b buf[8] = a; END 29

  30. False Path Pruning Branch Disequality Integer Range char * buf[8]; if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) “a != 0” a && b buf[8] = a; END 30

  31. False Path Pruning Branch Disequality Integer Range char * buf[8]; Impossible if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) “a != 0” a && b buf[8] = a; END 31

  32. Application to Security Bugs • Stanford research project • Ken Ashcraft and Dawson Engler, Using Programmer-Written Compiler Extensions to Catch Security Holes, IEEE Security and Privacy 2002 • Used modified compiler to find over 100 security holes in Linux and BSD 32

  33. Results for BSD and Linux Linux BSD Violation Bug Fixed Bug Fixed Gain control of system 18 15 3 3 Corrupt memory 43 17 2 2 Read arbitrary memory 19 14 7 7 Denial of service 17 5 0 0 Minor 28 1 0 0 Total 125 52 12 12 33

  34. Fuzzing Basics • A form of vulnerability analysis and testing • Many slightly anomalous test cases are input into the target application • Application is monitored for any sign of error 34

  35. Example of Fuzzed Input • Standard HTTP GET request • GET /index.html HTTP/1.1 • Anomalous requests • AAAAAA...AAAA /index.html HTTP/1.1 • GET ///////index.html HTTP/1.1 • GET %n%n%n%n%n%n.html HTTP/1.1 • GET /AAAAAAAAAAAAA.html HTTP/1.1 • GET /index.html HTTTTTTTTTTTTTP/1.1 • GET /index.html HTTP/1.1.1.1.1.1.1.1 • etc... 35

  36. Early Successes (1989 Fuzz Project) 36

  37. 37 IPhone Security Flaw: July 2007 Shortly after the iPhone was released, a group of security researchers at Independent Security Evaluators decided to investigate how hard it would be for a remote adversary to compromise the private information stored on the device

  38. 38 Ultimately, Success • Within two weeks of • Notified Apple of the part time work, we had vulnerability and successfully proposed a patch. • discovered a • Apple subsequently vulnerability resolved the issue. • developed a tool chain • Released an advisory for working with the iPhone's architecture • created a proof-of- concept exploit capable of delivering files from the user's iPhone to a remote attacker

  39. CVE-2007-3944 Issued and Patched 39

  40. iPhone Attack • iPhone Safari downloads malicious web page • Arbitrary code is run with administrative privileges • Can read SMS log, address book, call history, etc. • Can transmit collected data to attacker • Can perform physical actions on the phone • system sound and vibrate the phone for a second • could dial phone numbers, send text messages, or record audio (as a bugging device) 40

Recommend


More recommend