1 / 11

The Future of Software Security

The Future of Software Security. David Wagner U.C. Berkeley. The Scale of the Problem. Viruses and worms prevalent — and especially nasty ones can cost > $1 billion per occurrence Phishing, pharming, botnets, rootkits, privacy spills

cherylf
Download Presentation

The Future of Software 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. The Future of Software Security David Wagner U.C. Berkeley

  2. The Scale of the Problem • Viruses and worms prevalent — and especially nasty ones can cost > $1 billion per occurrence • Phishing, pharming, botnets, rootkits, privacy spills • Cybercrime profits for 2004 ($105 billion) claimed to exceed those of drug crime [Treasury Dept.] • 80% of home users infected with spyware [NCSA] • MTTI (Mean Time To Infection) for WinXP out-of-box: 15 minutes [SANS] • Why? (1) Because we haven’t made security usable. (2) Because our software is riddled with defects.

  3. Where is Software Security Heading? • Traditional approaches aren’t adequate • operating system security — a good OS can’t make up for a buggy app • virus detectors, IDS — a kludge on its last legs • patch-and-pray — can’t keep up with the blackhats • working around buggy end hosts in the network — a nice idea, killed by HTTP, SOAP, … • Software security is a software quality problem • Software bugs = security holes = bad • We’ve got an application security problem

  4. Application Security Matters “unsafe” = remotely exploitable hole is publicly known and no patch available; “safe” = anything else. Sources: scanit, Secunia • Application quality can make a measurable difference

  5. Complexity: No End in Sight • Complexity is the enemy of security — yet is on the rise

  6. Approaches • What can we do about it? • Try harder • Hardened languages and execution environments • Tools to find security bugs in legacy code • Languages, programming disciplines, tools to eliminate security bugs in new code

  7. MOPS: A C Model Checker • Experiment: Analyze an entire Linux distribution • Redhat 9, all C packages (732 pkgs, ~ 50 MLOC) • Examined 5 sample security rules • Team of 4 manually examined 900+ warnings • Laborious: multiple person-months of effort • Found 108 new security holes in Linux apps • Lesson: Security bugfinding tools can be very effective

  8. Input Validation char *name = gethostbyaddr(...)->h_name; printf(name); // BUG! • Idea: static taint tracking • Inputs from untrusted sources are “tainted” • Prevent the flow of tainted data to trusting sinks • Crude implementation — abuse the C type system: struct taintedstr { char *p; }; struct taintedstr name = mktaintedstr(gethostbyaddr(...)->h_name); printf(name); // TYPE ERROR! • Cheesy hack — augmented (Apps) Hungarian: char *tszName = gethostbyaddr(…)->h_name; printf(tszName); // BUG!

  9. Taint Analysis Through Type Inference • A better way: type qualifier inference (CQual) • New types: $tainted int, $untainted int, etc. • Tool infers these qualifiers, where needed, so you don’t have to • Application: Detection of format string vulnerabilities • Partial results: 3 vulnerabilities in 200K LOC • In progress: analysis of an entire Linux distribution (260M LOC, 16K packages) • Application: Detection of user/kernel vulnerabilities in the Linux kernel • Linux 2.4.20: 11 exploitable security holes • Linux 2.4.23: 10 exploitable security holes

  10. User/Kernel Security Holes • Experiment: Can CQual verify absence of u/k bugs? • Sound whole-kernel analysis • Found 10 exploitable holes in Linux 2.4.23 core • Sparse: missed all 10 bugs; 7000 annotations; many FPs • MECA: missed 6/8 bugs; 75 annotations; very few FPs • Lesson: Verifying absence of (certain) bugs is within reach • Lesson: Verification tools find more bugs

  11. Parting Thoughts • Security (quality) is a whole-systems problem • Affects all elements of the system • Pervades SW lifecycle: design, implementation, QA • Security (quality) is a people problem • Training, user testing, processes, ... • Program analysis tools can help with the gruntwork • Bottom line: Better tools and better languages can help, but there’s no silver bullet • If we haven’t solved the software quality problem yet, we probably won’t solve the software security problem any time soon, either

More Related