Writing Applications that are Easier to Defend than Attack

1. Writing Applications that are Easier to Defend than Attack Alan H. Karp alan.karp@hp.com 650-857-3967 Hewlett-Packard Laboratories June 6, 2012 - Raising Security IQ

2. Disclaimer The views and opinions expressed during this conference are those of the speakers and do not necessarily reflect the views and opinions held by the Information Systems Security Association (ISSA), the Silicon Valley ISSA, the San Francisco ISSA or the San Francisco Bay Area InfraGard Members Alliance (IMA).  Neither ISSA, InfraGard, nor any of its chapters warrants the accuracy, timeliness or completeness of the information presented.  Nothing in this conference should be construed as professional or legal advice or as creating a professional-customer or attorney-client relationship.  If professional, legal, or other expert assistance is required, the services of a competent professional should be sought. June 6, 2012 - Raising Security IQ

3. Forgive me, Father, for I have sinned I stole most of the material in this talk from Marc Stiegler. June 6, 2012 - Raising Security IQ

4. Anti-Outline • Social engineering • Sweet talk • Phishing • 9 mm persuasion • Fake anti-virus • Weak passwords • Bad crypto • OS vulnerabilities June 6, 2012 - Raising Security IQ

5. Most Common Patches • 75% of Microsoft patches are for applications • Year, after year, after year “If what we were doing was effective, wouldn’t you expect things to be getting better?” -- Marcus Ranum June 6, 2012 - Raising Security IQ

6. We Know Why June 6, 2012 - Raising Security IQ http://www.youtube.com/watch?v=x0WYsKYy0ag

7. Variable Threat June 6, 2012 - Raising Security IQ

8. Anderson’s Economic Analysis • Defender’s cost • 1,000,000 line program • 1 exploitable bug/10,000 lines • 10 hour/bug • 1,000 hours • Attacker’s cost • 100 hours/bug • Need to exploit 1 bug • 100 hours • Defender’s cost/Attacker’s cost >> 1 June 6, 2012 - Raising Security IQ

9. What does the attacker win? • A clue for finding a solution “Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.” -- Microsoft Security Bulletins June 6, 2012 - Raising Security IQ

10. Principle of Least Privilege “Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” -- Jerome H. Saltzer Michael. D. Schroeder "Protection and the control of information sharing in multics“. Communications of the ACM17 (7): 389, (1974). user June 6, 2012 - Raising Security IQ

11. Root Cause of the Problem Every program you run can use all your permissions Don’t do that! June 6, 2012 - Raising Security IQ

12. A Short Detour June 6, 2012 - Raising Security IQ

13. What is a Privilege? • Saltzerand Schroeder didn’t say • Principle of Least Authority • Easier to say (POLA vs POLP) • Precise meaning June 6, 2012 - Raising Security IQ

14. May versus Can • Permission analysis tells you what may happen. • Authority analysis tells you what can happen. • Permission analysis: Put secrets on home page • Authority analysis tells why you shouldn’t Random User Apache index.html (Apache,R; admin,RW) June 6, 2012 - Raising Security IQ

15. Back on the Main Road June 6, 2012 - Raising Security IQ

16. Immutable Law - Mutated Law #1: If a bad guy can persuade you to run his program in your account, it’s not your account anymore. • Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore. • NOT with POLA applied to programs June 6, 2012 - Raising Security IQ

17. The Rest of the Story • Granularity of POLA • Machine • User • Application • Application Instance • Module of Application • Object in a module June 6, 2012 - Raising Security IQ

18. POLA for Applications June 6, 2012 - Raising Security IQ

19. Killer App • Wonderful spreadsheet • Important calculation • May have a virus • Choice today • Turn off macros – useless • Turn on macros – risk my machine • POLA approach • Leave macros on • Virus can do no harm June 6, 2012 - Raising Security IQ

20. Current Way June 6, 2012 - Raising Security IQ

21. Where’s my paddle? June 6, 2012 - Raising Security IQ

22. It Ate My Desktop June 6, 2012 - Raising Security IQ

23. The Safe Way June 6, 2012 - Raising Security IQ

24. Can’t Hurt Anything June 6, 2012 - Raising Security IQ

25. Polaris is Magic • No change to operating system • No change to application • No specialized sandbox • No need to intercept system calls • Use runAs to launch as a restricted user • Write some code to enable SaveAs, etc. June 6, 2012 - Raising Security IQ

26. A Lot of Protection • All of the 75% of Microsoft patches • Zero day attacks against Office • Drive-by downloads in IE • Other vulnerabilities • Adobe Reader • RealPlayer • QuickTime • Malicious email, including malware attachments June 6, 2012 - Raising Security IQ

27. The Problem June 6, 2012 - Raising Security IQ

28. POLA for Application Instances June 6, 2012 - Raising Security IQ

29. The Solution • Run each instance in a different account • Surprisingly hard • Creating accounts too hard to do on the fly • Common operations fail • Clipboard is a security problem • Apps don’t all obey account boundaries (e.g., Firefox) • Probably need help from software vendors June 6, 2012 - Raising Security IQ

30. The Problem Any Breach == Full Breach AddressBook Power of restricted user account Sender JPEG attack subverts renderer Uses addresses and sender Receiver RenderingEngine Mail Tool (Outlook, Evolution, etc.) June 6, 2012 - Raising Security IQ

31. POLA for Modules June 6, 2012 - Raising Security IQ

32. Virus versus POLA Client Modularize Authority, not just Code AddressBook Sender Main Receiver JPEG attack subverts renderer. No access to sender, addresses Rendering Engine June 6, 2012 - Raising Security IQ

33. The Problem Attack subverts sender, grants access to address book AddressBook Sender Main Receiver Rendering Engine June 6, 2012 - Raising Security IQ

34. POLA for Objects June 6, 2012 - Raising Security IQ

35. POLA for Objects June 6, 2012 - Raising Security IQ

36. Revised Economic Analysis • Defender’s cost • 1,000,000 line program • 1 exploitable bug/10,000 lines • 10 hour/bug • 1,000 hours • Attacker’s cost • 100 hours/bug • Need to exploit k bugs • Not an arbitrary k, cost αα (100 ) • Defender’s cost/Attacker’s cost << 1 ( ) k n k June 6, 2012 - Raising Security IQ

37. The Secret Sauce • Good object oriented design • Each object gets fewest references it needs • Easier to program • Fewer opportunity for bugs • More maintainable • Security comes nearly for free • Memory safe language (JavaScript, Python, Java) • No global mutable state June 6, 2012 - Raising Security IQ

38. Recap June 6, 2012 - Raising Security IQ

39. Our Logo The POLA Bear June 6, 2012 - Raising Security IQ

40. Questions? http://www.hpl.hp.com/personal/Alan_Karp/ June 6, 2012 - Raising Security IQ

41. Thank you • Alan H. Karp • alan.karp@hp.com • 650-857-3967 • Hewlett-Packard Laboratories Disclaimer The views and opinions expressed during this conference are those of the speakers and do not necessarily reflect the views and opinions held by the Information Systems Security Association (ISSA), the Silicon Valley ISSA, the San Francisco ISSA or the San Francisco Bay Area InfraGard Members Alliance (IMA).  Neither ISSA, InfraGard, nor any of its chapters warrants the accuracy, timeliness or completeness of the information presented.  Nothing in this conference should be construed as professional or legal advice or as creating a professional-customer or attorney-client relationship.  If professional, legal, or other expert assistance is required, the services of a competent professional should be sought. June 6, 2012 - Raising Security IQ