1 / 26

Static Analysis for Security A Case Study in the Automation of Code Auditing

Static Analysis for Security A Case Study in the Automation of Code Auditing. Omer Tripp November 9 th , 2009. Agenda. Motivation Solution space Security violations Taint analysis Demo Conclusion. Some Statistics. Average number of bugs per KLOC is 15 [1]

azana
Download Presentation

Static Analysis for Security A Case Study in the Automation of Code Auditing

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. Static Analysis for SecurityA Case Study in the Automation of Code Auditing Omer Tripp November 9th, 2009

  2. Agenda • Motivation • Solution space • Security violations • Taint analysis • Demo • Conclusion

  3. Some Statistics • Average number of bugs per KLOC is 15 [1] • Developers find 6 defects per hour in code reviews [2]

  4. Some Math • There are 30 MLOC in e-Bay’s codebase • ~45K bugs • ~7.5K hours to find • There are 50 MLOC in Windows Server 2003 • ~75K bugs • ~12.5K hours for find

  5. Some More Statistics • Heavy-weight static-analysis techniques process ~1K LOC per second • Light-weight static-analysis techniques process ~5K LOC per second • Human reviewers can only (effectively) digest 300 LOC per hour = 0.2 LOC per second [3]

  6. Bottom Line • Manual auditing is problematic: • Too costly! • Doesn’t fit into SDLC • Results influenced by subjective considerations • Sometimes it’s also impossible: • 3rd-party component packaged as binary • Human auditing leaks IP • No in-house experts

  7. What Can Automation Do? • Wide range of applications, including: • Run-time errors (e.g., NPE, unhandled exceptions, etc…) • Security analysis • Performance analysis • Liveness properties • Synchronization problems • Quality issues • Refactoring • …

  8. Static-analysis Tools

  9. Dynamic-analysis Tools

  10. Software Security • Integrity • Untrusted inputs flowing into security-sensitive areas • Confidentiality • Private information flowing into public areas • DoS • Overwhelming the system • Causing crashes

  11. Exemplary Integrity Violations • Cross-site Scripting • SQL injection (SQLi)

  12. Exemplary Confidentiality Violations • Error leakage • Insufficient anonymity

  13. Denial of Service • Classic DoS/DDoS • Through an integrity problem

  14. Code Examples public partial class Customize : System.Web.UI.Page { … protected void Page_Load(object sender, System.EventArgs e) { … string langParam = Request.QueryString["lang"]; … if (langParam != ""){lang = langParam;} … langLabel.Text = lang; … } … } XSS public partial class Transfer : System.Web.UI.Page { … protected void Page_Load(object sender, System.EventArgs e) { … string thisUser = Request.Cookies["amUserId"].Value; GetAccounts(thisUser); … } … private void GetAccounts(string userId) { … string query ="SELECT accountid, acct_type From accounts WHERE userid = " + userId; … myAccount = new OleDbDataAdapter(query , myConnection); … } … } SQLi

  15. Taint Analysis • The problem of finding flows from unchecked/poorly checked inputs to security-sensitive operations • Can be solved as graph-reachability problem • Captures vast majority of integrity/confidentiality problems

  16. Bird’s-eye View • Build index of all relevant entities (type hierarchy, methods, etc…) • Represent the program as a call graph • Track control and data flow on top of the call graph • Solve a reachability problem on top of the propagation graph (modulo some enhancements)

  17. Taint Analysis Based on Program Slicing [4,5] • Run the following algorithm: • Use statements defining untrusted inputs as slicing criterion • Find the set S of all statements that are (control-) and data-flow dependent on the slicing criterion • For each s in S such that s is a security-sensitive operation, report all flows from statements in the slicing criterion to s

  18. Taint Analysis Based on a Storeless Abstraction X x = req.getParameter(); Y y = new Y(); y.f = x; Z z = y.f; resp.getWriter().write(z); { x } { x } { x, y.f } { x, y.f, z }

  19. Challenges • The infamous precision-scalability tradeoff • External resources • Configuration files • Framework-specific configurations • Beyond graph reachability… • SDLC-induced use cases

  20. Precision versus Scalability • Modular analysis • Demand-driven strategies

  21. External Resources • Synthetic models • Sometimes ignorance is a bliss…

  22. Beyond Graph Reachability • PQL [6] • String analysis [7]

  23. SDLC-induced Use Cases • Incremental analysis • Parallelization on multi-core build servers

  24. DEMO

  25. The Remaining 8 Yards • Instead of killing n birds with 1 stone, use n stones to kill 1 bird (like humans) • How do we catch up with changes in technology? • How to tailor the analysis to the needs of different users? • Useful heuristics often resilient to formal definition

  26. References • [1] S. McConnell.Code Complete: A Practical Handbook of Software Construction • [2] W. S. Humphrey.Acquiring Quality Software in CrossTalk,18-12 • [3] Code Review at Cisco Systems • [4] O. Tripp et al..TAJ: Effective Taint Analysis of Web Applications • [5] C. Hammer and G. Snelting.Flow-sensitive, Context-sensitive, and Object-sensitive Information-flow Control Based on Program Dependence Graphs • [6] B. Livshits and M. Lam. Finding Application Errors and Security Flaws Using PQL: a Program Query Language • [7] M. Christodorescu et al..String Analysis for X86 Binaries

More Related