1 / 25

Sandboxing Mobile Code Execution Environments

Sandboxing Mobile Code Execution Environments. Timothy Hollebeek. Technical Objectives. Provide interception framework that allows policies to be enforced on mobile scripts Provide policies which mitigate problems associated with mobile scripts while preserving functionality. Very Dangerous.

drake
Download Presentation

Sandboxing Mobile Code Execution Environments

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. Sandboxing Mobile Code Execution Environments Timothy Hollebeek

  2. Technical Objectives • Provide interception framework that allows policies to be enforced on mobile scripts • Provide policies which mitigate problems associated with mobile scripts while preserving functionality Very Dangerous Widely Used

  3. Initial Perception: JavaScript/VBscript isn’t dangerous • Little or no security built into language originally • Not capable of a “traditional” security hole

  4. Evolution of Scripting Languages • More and more capabilities available • Able to interact with other technologies (Java, ActiveX, forms) • Very easy to write • used everywhere • very low code quality

  5. Evolution of Security • Servers with important information must interact with a large number of untrusted machines • Isolating machines and limiting the services they use is increasingly impractical • Same is true of applications

  6. Today: Scripts are very dangerous “Overflow” “Javascript” • BUGTRAQ messages: • Consequences: 2533 401 No need to run code Can run arbitrary code Can read or alter sensitive information Sensitive information already read or altered

  7. Why? • Have full access to browser/host application • spoofing attacks, “viruses” • Used as “Turing glue” in many attacks • copy/paste file upload • “BubbleBoy” scripting of flawed ActiveX controls • Very easy to manipulate forms and/or documents • Very little or no inherent security • CERT Advisory CA-2000-02: too easy to inject scripts almost anywhere

  8. Java applets are (sometimes) blocked at firewall. Script ActiveX Controls • ActiveX controls are not allowed unless trusted. • Scripts are passed through. • Attachments/macros pass through.

  9. Existing Practice: “Solutions” • Turn off Active Scripting (CERT) • Sandbox the browser • Filter at firewalls • Analyze mobile code

  10. Turn off Active Scripting? • Used everywhere • Many forms stop functioning • Nontrivial links and indexes • Graceful degradation is rare

  11. Ask for help? • Vendor attention to this problem is “inadequate” • Existing ActiveScripting security settings are all targetted at past security flaws GeorgiGuninski: Hotmail doesn’t filter <IMG SRC=“javascript: Microsoft Support: We’ve fixed this problem Georgi Guninski: Hotmail doesn’t filter <IMG LOWSRC=“javascript: “penetrate and patch”

  12. Consider browser to be potentiallymalicious? • People do EVERYTHING with browsers • Preserving browser functionality would require very complex policies and architectures

  13. Filter? • SSL • Lots of ways to embed scripts in HTML/DHTML/YAML • Encoding issues (UTF-7, %xx) • Malformed tags (<<SCRIPT>) • Very difficult to do correctly

  14. Analyze? • If/When a script is found: • eval(): key bits of source code could be encrypted • obfuscation commonly used to hide source code • static analysis can’t find everything

  15. Technical Approach: Enforce security at a well-defined interface • ActiveScripting API: • fully documented (Microsoft wants 3rd party engines) • likely target for future web scripting technologies • Document Object Model • control at correct level • simple, effective policies • easy to specify, implement and guarantee

  16. Internet Script Interpreter Host Application Script COM Policy Enforcer Script Interpreter Host Application Script COM COM All necessary implementation information given by COM and ActiveScripting API

  17. Roll back the clock: allow approved usage • DOM: • window • print • scrollTo • scrollBy • status • location • Later:more sophisticated policies (if/when necessary)

  18. Roll back the clock: allow approved usage • DOM: • window • scrollTo • scrollBy • Later:more sophisticated policies (if/when necessary)

  19. Major Risks • Does not solve the “authorship” problem • Attacks that fall outside scope of solution • Context-sensitive attacks • Security flaws in scripts • Performance penalties

  20. Accomplishments • Developed approach for reducing risk from active scripting • Interception technology has been validated • Able to log scripts

  21. Quantitative Metrics • Assess performance overhead with policies in place • Benchmark effectiveness of general policies against known malicious scripts • Evaluate simplicity and scope of policies

  22. Expected Major Achievements • 3rd party control over scripts with no vendor or web site designer’s cooperation • Language neutral and implementation neutral implementation • Substantial reduction of risk with minimal decrease in functionality

  23. Task Schedule Benchmark technology against malicious scripts Explore “real world” usage Feb ‘00 Jul ‘00 Feb ‘01 Jul ‘01 Deliver prototype implementation Develop Policies Instrument active scripting engine Demonstrate proof-of-concept

  24. Transition of Technology • Release interception technology and policy enforcer for general use • License technology to vendors

  25. Contact Information • Timothy Hollebeek (tim@rstcorp.com) • Anup Ghosh (anup.ghosh@computer.org) • http://www.rstcorp.com/research

More Related