RST Labs

Sandboxing Mobile Code Execution Environments

Timothy Hollebeek

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

WidelyUsed

VeryDangerous

RST Labs

Initial Perception: JavaScript/VBscript isn’t dangerous

• Little or no security built into language originally• Not capable of a “traditional” security hole

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

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

RST Labs

Today: Scripts are very dangerous

• BUGTRAQ

messages:

• Consequences:

“Overflow” “Javascript”

2533 401

Can run arbitrary code

Can read or alter sensitive information

No need torun code

Sensitive informationalready read or altered

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

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.

RST Labs

Existing Practice: “Solutions”

• Turn off Active Scripting (CERT)• Sandbox the browser• Filter at firewalls• Analyze mobile code

RST Labs

Turn off Active Scripting?

• Used everywhere• Many forms stop functioning• Nontrivial links and indexes

• Graceful degradation is rare

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 problemGeorgi Guninski: Hotmail doesn’t filter <IMG LOWSRC=“javascript:

“penetrate and patch”

RST Labs

Consider browser to be potentiallymalicious?

• People do EVERYTHING with browsers• Preserving browser functionality would require very

complex policies and architectures

RST Labs

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

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

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

RST Labs

Script

Internet

ScriptInterpreter

Host Application

CO

MScript Script

InterpreterHost

Application

CO

M

CO

MPolicyEnforcer

All necessary implementation information givenby COM and ActiveScripting API

RST Labs

Roll back the clock: allow approved usage

• DOM:– window

• print• scrollTo• scrollBy• status• location

•Later: more sophisticated policies (if/when necessary)

RST Labs

Roll back the clock: allow approved usage

• DOM:– window

• scrollTo• scrollBy

•Later: more sophisticated policies (if/when necessary)

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

RST Labs

Accomplishments

• Developed approach for reducing risk from active scripting

• Interception technology has been validated• Able to log scripts

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

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

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 ‘00 Jul ‘00 Feb ‘01 Jul ‘01Develop Policies

RST Labs

Transition of Technology

• Release interception technology and policy enforcer for general use

• License technology to vendors

RST Labs

Contact Information

• Timothy Hollebeek (tim@rstcorp.com)• Anup Ghosh (anup.ghosh@computer.org)

• http://www.rstcorp.com/research