1 / 64

Writing Applications that are Easier to Defend than Attack

Writing Applications that are Easier to Defend than Attack. Alan H. Karp. Hewlett-Packard Laboratories. ASEC-T17. Advanced. Marc Stiegler. Hewlett-Packard Laboratories. Most Common Security Patches. 75% of Microsoft security bulletins are for applications Year, after year, after year

karik
Download Presentation

Writing Applications that are Easier to Defend than Attack

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. Writing Applications that are Easier to Defend than Attack Alan H. Karp Hewlett-Packard Laboratories ASEC-T17 Advanced Marc Stiegler Hewlett-Packard Laboratories

  2. Most Common Security Patches • 75% of Microsoft security bulletins 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

  3. We Know Why

  4. Anderson’s Economic Analysis • Defender’s cost • 1,000,000 line program • 1 exploitable bug/10,000 lines • 100 hour/bug • 10,000 hours • Attacker’s cost • 1.000 hours/bug • Need to exploit 1 bug • 1000 hours • Defender’s cost/Attacker’s cost >> 1

  5. What does the attacker win? • A clue for finding an answer “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

  6. 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).

  7. 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).

  8. Root Cause of the Problem Every program you run can use all your permissions. Don’t do that!

  9. A Short Detour

  10. What is a Privilege? • Saltzer and Schroeder didn’t say precisely • Principle of Least Authority • Easier to say (POLA vs POLP) • Precise meaning

  11. May versus Can • Permission analysis tells you what may happen. • Authority analysis tells you what can happen.

  12. May versus Can • Permission analysis tells you what may happen. • Authority analysis tells you what can happen. Apache index.html (Apache,R; admin,RW)

  13. May versus Can • Permission analysis tells you what may happen. • Authority analysis tells you what can happen. • Permission analysis: Put secrets on home page Apache index.html (Apache,R; admin,RW)

  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 Random User Apache index.html (Apache,R; admin,RW)

  15. 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)

  16. Back on the Main Road

  17. 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 I care about

  18. Current Approach

  19. Where’s my paddle?

  20. It Ate My Desktop

  21. POLA at Application Granularity

  22. Can’t Hurt Anything I Care About

  23. Polaris Seems Magical • No change to operating system • No change to application • Sandboxed only with standard Windows API • No need to run in a VM • No need to intercept system calls

  24. Polaris Seems Magical • No change to operating system • No change to application • Sandboxed only with standard Windows API • No need to run in a VM • No need to intercept system calls • Use runAs to launch app in a restricted user account • Write some code to enable SaveAs, etc. Caveat • COM communications hole required special handling

  25. 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

  26. The Problem with Polaris

  27. The Problem with Polaris

  28. POLA for Application Instances

  29. The Solution • Run each instance in a different account • Surprisingly hard • Creating accounts is slow • Common operations fail • Clipboard is a security problem • Apps don’t all obey account boundaries (e.g., Firefox) • Probably need help from software vendors

  30. The Problem with App Instances AddressBook Power of restricted user account Sender Receiver RenderingEngine Mail Tool (Outlook, Evolution, etc.)

  31. The Problem with App Instances 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.)

  32. POLA for Modules

  33. Virus versus POLA Client AddressBook Sender Main Receiver Rendering Engine

  34. Virus versus POLA Client Modularize Authority, not just Code AddressBook Sender Main Receiver JPEG attack subverts renderer. No access to sender, addresses Rendering Engine

  35. The Problem with Modules Attack subverts sender, grants access to address book AddressBook Sender Main Receiver Rendering Engine

  36. POLA for Objects

  37. Object Graph of Sender

  38. Critical Objects

  39. Vulnerable Objects

  40. Exploited Objects

  41. Revised Economic Analysis • Defender’s cost • 1,000,000 line program • 1 exploitable bug/10,000 lines • 100 hour/bug • 10,000 hours • Attacker’s cost • 1,000 hours/bug • Need to exploit k bugs • Not an arbitrary k, cost α( ) α (1,000 ) • Defender’s cost/Attacker’s cost << 1 (Don’t take math too seriously. It says you are safer with more bugs, so only applies a small percentage of objects.) n k k

  42. Code Examples

  43. Through the (Cost) Looking Glass • Authority Modularization: How to quantify cost/rewards? • Security Review: lower cost, equal quality • Currently, every line of code needs review • java.io.FilepassFile = new java.io.File(“password”); • Basic Principle: Objects/Modules without strong powers do not need review (Defend Calais, not Brittany) • If only 2 in 10 modules have risky powers, reduce review cost by 80%

  44. POLArized Modules Strict Isolation + Explicit Delegation of Least Powers == Authority Modularization AddressBook 3 Threats: • SpamBot • Address Book • Sender • Private Data Theft • Receiver • Sender • SMTP Password Theft Address File, Presentation Panel Sender SMTP socket, pass, Address Book “Main” => Powerbox Receiver POP socket, Renderer 1 Special Vulnerability: Rendering Engine PresentationPanel Rendering Engine What Modules Need Review?

  45. POLArized Modules Strict Isolation + Explicit Delegation of Least Powers AddressBook 3 Threats: • SpamBot • Address Book • Sender • Private Data Theft • Receiver • Sender • SMTP Password Theft Address File, Presentation Panel Sender SMTP socket, pass, Address Book Main => Powerbox Receiver POP socket, Renderer 1 Special Vulnerability: Rendering Engine PresentationPanel Rendering Engine

  46. Powerbox A reusable pattern at many coding levelsEnables incremental retrofit of legacy apps, submodule by submodule Module Module Main SubModule Module IsolatedSubSubModule SubModule Overhauled SubModule(Powerbox) Module IsolatedSubSubModule IsolatedSubSubModule

  47. POLArized Modules Part 2

  48. Must We Review the Sender? • Small code change, big review payoff? • Must have the send authority: this is its purpose! • Does it need the smtp password? If so, must review in detail • Does it need full access to the address book? If so, must review in detail • If we can eliminate password and limit address book, no review needed

  49. Protect Address Book Behind Facet Grant Violates Threat Model Grant Required for Operation Least Privilege Grant POLA-rized Sender

  50. Protect Address Book Behind Facet Grant Violates Threat Model Grant Required for Operation Least Privilege Grant POLA-rized Sender

More Related