1. RST Labs Sandboxing Mobile Code Execution Environments Timothy Hollebeek

2. RST Labs 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 Widely Used Very Dangerous

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

4. RST Labs 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. RST Labs 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. RST Labs Today: Scripts are very dangerous BUGTRAQ messages: Consequences: “Overflow”“Javascript” 2533401 Can run arbitrary code Can read or alter sensitive information No need to run code Sensitive information already read or altered

7. RST Labs 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. RST Labs Java applets are (sometimes) blocked at firewall. ActiveX Controls Script ActiveX controls are not allowed unless trusted. Scripts are passed through. Attachments/macros pass through.

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

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

11. RST Labs 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. RST Labs Consider browser to be potentially malicious? People do EVERYTHING with browsers Preserving browser functionality would require very complex policies and architectures

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

14. RST Labs 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. RST Labs 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. RST Labs Script Internet Script Interpreter Host Application COM Script Interpreter Host Application COM Policy Enforcer All necessary implementation information given by COM and ActiveScripting API

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

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

19. RST Labs 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. RST Labs Accomplishments Developed approach for reducing risk from active scripting Interception technology has been validated Able to log scripts

21. RST Labs 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. RST Labs 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. RST Labs Task Schedule Instrument active scripting engine Explore “real world” usage Demonstrate proof-of-concept Benchmark technology against malicious scripts Deliver prototype implementation Feb ‘00Jul ‘00Feb ‘01Jul ‘01 Develop Policies

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

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