#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 Software security is a software quality problem Software bugs = security holes = bad 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, … We’ve got an application security problem

#4 Application Security Matters Application quality can make a measurable difference Browser # safe days (in 2004) # unpatched (2/18/06) days to patch Internet Explorer 7( 2%) Opera 300(82%) 0 93 Firefox 339(93%) 2 43 “unsafe” = remotely exploitable hole is publicly known and no patch available; “safe” = anything else.Sources: scanit, Secunia

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

#6 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 Approaches

#7 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 MOPS: A C Model Checker Security PropertyWarningsReal bugsBug ratio TOCTTOU790415% temporary files % strncpy (  165–468?) ~ 5-10% Total Lesson: Security bugfinding tools can be very effective

#8 Idea: static taint tracking Inputs from untrusted sources are “tainted” Prevent the flow of tainted data to trusting sinks Input Validation 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! char *name = gethostbyaddr(...)->h_name; printf(name);// BUG!

#9 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 Taint Analysis Through Type Inference Application: Detection of user/kernel vulnerabilities in the Linux kernel Linux : 11 exploitable security holes Linux : 10 exploitable security holes 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)

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

#11 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 Parting Thoughts