1 / 88

Automated Tools for System and Application Security

This course introduces static and dynamic analysis methods for finding vulnerabilities in programs, with examples of security analysis and testing techniques. It covers topics such as black-box testing, fuzzing, and program analyzers.

irened
Download Presentation

Automated Tools for System and Application 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. Spring 2018 CS 155 Automated Tools for System and Application Security John Mitchell

  2. Outline • Introduction: static vs dynamic analysis • Static analysis • Program execution using state descriptions • Security examples: static analysis to find vulnerabilities • Dynamic vulnerability finding • Black-box testing: principles and web examples • Fuzzing: principles and examples

  3. Engineers Criminals Security Researchers Pen Testers Governments Hacktivists Academics Users of these methods and tools Remember this:If you develop code, you should test it using the same methods that attackers will use against you

  4. Software bugs are serious problems Thanks: Isil and Thomas Dillig

  5. Facebook missed asingle security check… • [PopPhoto.com Feb 10] • http://www.popphoto.com/news/2015/02/man-finds-easy-hack-to-delete-any-facebook-photo-album

  6. Cost of Fixing a Defect Credit: Andy Chou, Coverity

  7. People care about features, not security (until something goes wrong) Engineers typically only see a small piece of the puzzle “OMG PDF WTF” (Julia Wolf, 2010) How many lines of code in Linux 2.6.32? 10 million How many lines in Windows NT 4? 11-12 million How many in Adobe Acrobat? 13 million Engineering challenges

  8. Summary • Program bugs are ubiquitous • Security vulnerabilities are common too • Not all bugs lead to exploits • Exploits are serious and occur in many systems • Program bugs can be found through systematic methods • Better to find bugs and vulnerabilities early • Before attackers find and exploit them • Use tools and systematic methods in development, Q/A, later

  9. Outline • Introduction: static vs dynamic analysis • Static analysis • Program execution using state descriptions • Security examples: static analysis to find vulnerabilities • Dynamic vulnerability finding • Black-box testing: principles and web examples • Fuzzing: principles and examples

  10. Program Analyzers Code Program Analyzer Spec

  11. Static analysis Automated methods to find errors or check their absence Consider all possible inputs (in summary form) Find bugs and vulnerabilities Can prove absence of bugs, in some cases Dynamic analysis Run instrumented code to find problems Need to choose sample test input Can find vulnerabilities but cannot prove their absence Two options

  12. Entry Entry 1 1 2 2 4 4 1 1 3 4 1 1 2 4 1 2 4 2 3 1 2 4 1 3 4 2 4 1 2 3 1 2 4 1 3 4 Exit 1 2 4 1 2 3 1 3 4 4 Software Behaviors 1 2 3 1 2 3 1 3 4 12 1 2 4 1 2 4 1 3 4 . . . Exit

  13. Dynamic testing examines subset of behaviors Entry Entry 1 1 2 2 4 4 1 1 3 4 1 1 2 4 1 2 4 2 3 1 2 4 1 3 4 2 4 1 2 3 1 2 4 1 3 4 Exit 1 2 4 1 2 3 1 3 4 4 Software Behaviors 1 2 3 1 2 3 1 3 4 13 1 2 4 1 2 4 1 3 4 . . . Exit

  14. Static testing uses abstraction to consider all behaviors Entry 1 2 4 1 1 3 4 1 2 4 1 2 4 2 3 1 2 4 1 3 4 4 1 2 3 1 2 4 1 3 4 Exit 1 2 4 1 2 3 1 3 4 Software Behaviors 1 2 3 1 2 3 1 3 4 14 1 2 4 1 2 4 1 3 4 . . .

  15. Long history of academic research Decades of commercial products FindBugs, Fortify, Coverity, MS tools, … Commonly used in current practice Teams use development process and unit tests Static, dynamic tools find certain classes of bugs in dev, Q/A After release, hackers and support teams look for vulns Static Analysis

  16. Instrument code for testing Heap memory: Purify Perl tainting (information flow) Java race condition checking Black-box testing Black-box web application security analysis Fuzzing and penetration testing Dynamic analysis

  17. Program analyzers Find problems in code before it is shipped to customers or before you install and run it Static analysis Analyze code to determine behavior on all inputs Dynamic analysis Choose some sample inputs and run code to see what happens Sample inputs can be based on code analysis In practice, static and dynamic analysis are often combined Comparison Summary

  18. Outline • Introduction: static vs dynamic analysis • Static analysis • Program execution using state descriptions • Security examples: static analysis to find vulnerabilities • Dynamic vulnerability finding • Black-box testing: principles and web examples • Fuzzing: principles and examples

  19. “Sound” Program Analyzer Verify absence of vulnerabilities Analyze large code bases Code Program Analyzer Spec false alarm false alarm Sound:may report many warnings

  20. Soundness, Completeness Fact from logic: A  B is equivalent to (B) (A)

  21. Complete Incomplete Reports all errors May report false alarms Reports all errors Reports no false alarms Sound Undecidable Decidable May not report all errors May report false alarms May not report all errors Reports no false alarms Unsound Decidable Decidable

  22. Sound Over-approximation of Behaviors Reported Error Modules Behaviors Software . . . approximation is too coarse… …yields too many false alarms False Alarm

  23. Program execution based on abstract states Example

  24. Does this program ever crash? entry X  0 Is Y = 0 ? yes no X  X + 1 X  X - 1 Is Y = 0 ? yes no Is X < 0 ? exit yes no crash

  25. Does this program ever crash? entry X  0 Is Y = 0 ? yes no X  X + 1 X  X - 1 Is Y = 0 ? yes no Is X < 0 ? exit yes no infeasible path! … program will never crash crash

  26. Try analyzing without approximating… entry X  0 Is Y = 0 ? X = 0 yes no X  X + 1 X  X - 1 X = 2 X = 1 X = 0 Is Y = 0 ? yes no X = 1 X = 2 Is X < 0 ? exit X = 1 X = 3 X = 2 yes no non-termination! … therefore, need to approximate X = 1 X = 3 X = 2 crash X = 3 X = 1 X = 2 X = 3

  27. dataflow elements din X = 0 dout = f(din) X  X + 1 dout X = 1 f dataflow equation transfer function

  28. X = 0 din1 X  X + 1 dout1 = f1(din1) X = 1 dout1 = din2 din2 X = 1 dout1 Is Y = 0 ? dout2 = f2(din2) dout2 X = 1 f2 f1

  29. dout1 = f1(din1) dout2 = f2(din2) din2 djoin = dout1 ⊔dout2 djoin = din3 f1 f2 dout3 = f3(din3) din1 dout1 dout2 djoin din3 What is the space of dataflow elements, ? What is the least upper bound operator, ⊔? f3 dout3 least upper bound operator Example: union of possible values

  30. Try analyzing with “signs” approximation… entry X  0 Is Y = 0 ? X = 0 yes no X  X + 1 X  X - 1 X = 0 X = 0 Is Y = 0 ? yes no X = pos X = neg Is X < 0 ? exit X = T lost precision terminates... … but reports false alarm … therefore, need more precision yes no X = T X = T crash X = T X = T

  31. Sound Over-approximation of Behaviors Reported Error Behaviors Software . . . approximation is too coarse… …yields too many false alarms False Alarm

  32. X = T X  pos X  neg true X = pos X = 0 X = neg Y = 0 Y  0 false X =  signs lattice refined signs lattice Boolean formula lattice

  33. Try analyzing with “path-sensitive signs” approximation… entry X  0 Is Y = 0 ? true X = 0 yes no X  X + 1 X  X - 1 Y=0 X = 0 X = 0 Y0 Is Y = 0 ? yes no Y=0 X = pos X = neg Y0 no precision loss Is X < 0 ? exit yes no Y=0 X = pos terminates... … no false alarm … soundly proved never crashes Y0 X = neg X = neg Y0 crash Y=0 X = pos refinement X = pos Y=0

  34. Sound vs Complete Cannot be sound and complete Sound: can guarantee absence of bugs Sound analysis based on abstract states Symbolically execute code using a description of all possible states at each program point Better descriptions  more precise analysis, takes longer to analyze In practice Use the basic approach design for soundness, but possibly without soundness E.g., do not run loops to termination We discussed sound analysis using abstract states to understand the principle Summary of sound analysis

  35. Outline • Introduction: static vs dynamic analysis • Static analysis • Program execution using state descriptions • Security examples: static analysis to find vulnerabilities • Dynamic vulnerability finding • Black-box testing: principles and web examples • Fuzzing: principles and examples

  36. Program Analyzers in Practice analyze large code bases Code Program Analyzer Spec false alarm false alarm Not sound: may miss some bugs

  37. Bugs to Detect • Crash Causing Defects • Null pointer dereference • Use after free • Double free • Array indexing errors • Mismatched array new/delete • Potential stack overrun • Potential heap overrun • Return pointers to local variables • Logically inconsistent code • Uninitialized variables • Invalid use of negative values • Passing large parameters by value • Underallocations of dynamic data • Memory leaks • File handle leaks • Network resource leaks • Unused values • Unhandled return codes • Use of invalid iterators Slide credit: Andy Chou

  38. Prototype for open() syscall: Typical mistake: Result: file has random permissions Check: Look for oflags == O_CREAT without mode argument Example: Check for missing optional args int open(const char *path, intoflag, /* mode_tmode */...); fd = open(“file”, O_CREAT);

  39. 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 Example: Chroot protocol checker chroot() chdir(“/”) open(“../file”,…) Error if open before chdir

  40. Tainting checkers

  41. 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 http://www.stanford.edu/~engler/ Commercialized and extended Benefit Capture recommended expert practices in tool for everyone Application to Security Bugs

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

  43. Remote exploit, no checks Example security holes /* 2.4.9/drivers/isdn/act2000/capi.c:actcapi_dispatch */isdn_ctrlcmd;...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);

  44. Missed lower-bound check: Example security holes /* 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);

  45. Problem: which are the user pointers? Hard to determine by dataflow analysis Easy to tell if kernel believes pointer is from user! Belief inference “*p” implies safe kernel pointer “copyin(p)/copyout(p)” implies dangerous user ptr Error: pointer p has both beliefs. Implementation: 2 pass checker inter-procedural: compute all tainted pointers local pass to make sure they are not dereferenced User-pointer inference

  46. Should the return value of malloc() be checked? Environment Assumptions int *p = malloc(sizeof(int)); *p = 42; File server: Pause filesystem. Web application: 200ms downtime OS Kernel: Crash machine. IP Phone: Annoy user. Game: Annoy user. Spreadsheet: Lose unsaved changes. Library: ? Medical device: malloc?!

  47. Assume the code is usually right Statistical Analysis int *p = malloc(sizeof(int)); *p = 42; int *p = malloc(sizeof(int)); if(p) *p = 42; int *p = malloc(sizeof(int)); *p = 42; int *p = malloc(sizeof(int)); if(p) *p = 42; 1/4 deref 3/4 deref int *p = malloc(sizeof(int)); *p = 42; int *p = malloc(sizeof(int)); if(p) *p = 42; int *p = malloc(sizeof(int)); if(p) *p = 42; int *p = malloc(sizeof(int)); *p = 42;

  48. All bugs released to implementers; most serious fixed 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

  49. Static tools can detect many classes of errors Protocol errors: libraries require function calls in specific sequences, e.g. open(file) Tainting errors: untrusted values must be checked before specific kinds of use Automated tools used to find vulnerabilities in widely used systems Operating systems, device drivers, user applications, … Some simplifications used to reduce probability of false alarms Look for programmer inconsistencies – more useful to report if programmer confused Often more useful to report 10 significant bugs than a list of 1000 containing 11 Summary of security analysis

  50. Outline • Introduction: static vs dynamic analysis • Static analysis • Program execution using state descriptions • Security examples: static analysis to find vulnerabilities • Dynamic vulnerability finding • Black-box testing: principles and web examples • Fuzzing: principles and examples

More Related