CS 378 Mobile Code Security Vitaly Shmatikov slide

CS 378 Mobile Code Security Vitaly Shmatikov slide 1

Running Untrusted Code u. Data is harmless (? ? ) u. Risks come from code received from Web • Scripts in web pages • Active. X controls and browser extensions • Java applets Browser Risk to browser? Server 2

Java. Script u. Language executed by browser • Can run before HTML is loaded, before page is viewed, while it is being viewed or when leaving the page u. Often used to exploit other vulnerabilities • Attacker gets to execute some code on user’s machine • Remember cross-scripting? Attacker inserts malicious Java. Script into a Web page or HTML email. When script is executed, it steals user’s cookies and hands them over to attacker’s site. 3

Active. X u. Active. X controls are downloaded and installed • Compiled binaries for client’s OS u. Active. X controls reside on client's machine • Activated by HTML object tag on the page • Run as binaries, not interpreted by browser u. Security model relies on three components • Digital signatures to verify the source of binary • Browser policy can reject controls from network zones • Controls can be marked by author as “safe for initialization” or “safe for scripting” Once accepted, installed and started, no control over execution! 4

Installing Controls If you install and run, no further control over the code In principle, browser/OS could apply sandboxing, other techniques for containing risks in native code 5

Active. X Risks u. From MSDN: • “An Active. X control can be an extremely insecure way to provide a feature. Because it is a Component Object Model (COM) object, it can do anything the user can do from that computer. It can read from and write to the registry, and it has access to the local file system. From the moment a user downloads an Active. X control, the control may be vulnerable to attack because any Web application on the Internet can repurpose it, that is, use the control for its own ends whether sincere or malicious. ” u. How can a control be “repurposed? ” • Once installed, control can be accessed by any page that knows its class identifier (CLSID) 6

IE Browser “Helper Objects” u. COM components loaded when IE starts up u. Run in same memory context as the browser u. Perform any action on IE windows and modules • Detect browser events – Go. Back, Go. Forward, and Document. Complete • Access browser menu, toolbar and make changes • Create windows to display information (or ads!!) • Install hooks to monitor messages and actions u. There is no protection from extensions • Spyware writers’ favorite! • Try running Hijack. This on your computer 7

Java u. Java is a general-purpose programming language u. Web pages may contain Java code • Downloadable “applets” u. Java is executed by Java Virtual Machine • Special security measures associated with Java code from remote URLs: downloaded applets run in a restricted environment (sandbox) • All accesses to local resources are filtered through Security Manager – Security manager can grant special privileges to applets created by or downloaded from trusted sources 8

Overview of Java Design u. Compiler compiles source code into bytecode class u. Virtual machine loads classes on demand, verifies bytecode properties, interprets bytecode u. Why this design? • Bytecode is portable – Can transmit bytecode across network • Minimize machine-dependent part of implementation – Do optimization on bytecode when possible – Keep bytecode interpreter simple 9

JVM Architecture Java Compiler A. java A. class Compile source code Java Virtual Machine Loader rk o tw Ne B. class Verifier Linker Bytecode interpreter 10

Java Sandbox u. Untrusted Java applets run in a sandbox • • • Cannot access local filesystem or devices Network connections only to applet load source Cannot invoke any local program or library “Untrusted” indicator on top-level windows Cannot manipulate basic classes or other threads … this is too restrictive for many applets u. Java 2 supports fine-grained security policies • Security manager may have several security policies • Policy can grant privileges to specific applets based on their source and/or digital signatures on the code 11

Overview of Sandbox Architecture u. Several complementary mechanisms u. Class loader • Associates protection domain with each class u. Bytecode verification and run-time tests • NO unchecked casts or other type errors, NO overflow u. Security manager • Library functions call it to decide if request is allowed • Uses protection domain associated with code and policy • Enforcement relies on stack inspection 12

Class Loader u. Runtime system loads classes as needed • When class is referenced, loader searches for file of compiled bytecode instructions • Namespaces of different applets are kept different – Different instances of Class. Loader • Every loaded class has a reference to loader instance that created it • Loader calls bytecode verifier on untrusted classes u. Default loading mechanism can be replaced • Define alternate Class. Loader object – Extend the abstract Class. Loader class and implementation 13

Bytecode Verifier u. Checks correctness of bytecode • • Code has only valid instruction opcodes & register use Code does not overflow/underflow stack Data types are not converted illegally Pointers are not forged Method calls use correct number & types of arguments References to other classes use legal names Every instruction obeys the Java type discipline – Type safety is fairly complicated! u. Goal: prevent access to underlying machine • Via forged pointers, overflows, crashes, etc. 14

Why Is Typing a Security Feature? u. Java security mechanisms rely on type safety u. Prevents applet from accessing arbitrary memory • Unchecked typecast lets program call any address int (*fp)(). . . fp = addr; (*fp)(n); /* variable "fp" is a function pointer */ /* assign address stored in an integer variable */ /* call the function at this address */ • Security manager has private fields that store permission information – Access to these fields would defeat the security mechanism 15

Type Safety of JVM u. Load-time type checking u. Run-time type checking • All casts are checked to make sure they are type safe • All array references are checked to be within bounds • References are tested to be not null before dereference u. Memory protection • Automatic garbage collection • NO pointer arithmetic If program accesses memory, the memory is allocated to the program and declared with correct type 16

Security Manager u. Java library functions call security manager when they are invoked at runtime • For example, check. Read(String filename) – check. Read method is defined by Security. Manager class • Method throws exception if operation is not allowed u. Security manager uses the system policy to decide whether calling code is allowed to do operation • Examines “protection domain” of calling class – Signer: organization that signed code before loading – Location: URL where the calling class came from 17

Sample Security. Manager Methods check. Exec Checks if the system commands can be executed. check. Read Checks if a file can be read from. check. Write Checks if a file can be written to. check. Listen Checks if a certain network port can be listened to for connections. check. Connect Checks if a network connection can be created. check. Create Class. Loader Check to prevent the installation of additional Class. Loaders. 18

Creating a Security Policy u. Create your own subclass of Security. Manager and instantiate • Redefine check. Read, check. Write, etc. methods to enforce your policy u. Install using System. set. Security. Manager • set. Security. Manager cannot be revoked or replaced u. If no Security. Manager installed, all privileges are granted to any applet 19

Sample Security Policy Code. Source Base URL http: //www. schwab. com/ classes/stockeditor. jar http: //*. schwab. com/ Signature Schwab’s signature (not required) Permissions · Read/write file /home/shmat/stocks · Connect/accept bankofamerica. com ports 1 -1023 · Read file /home/shmat/ logo. png 20

Stack Inspection (Sketch) u. Permission depends on • Permission of calling method • Permission of all methods above it on call stack – Up to method that is trusted and asserts this trust method f method g method h java. io. File. Input. Stream 21

Attacks From Within Sandbox u. Deny service • Spawn threads, waste CPU cycles and bandwidth • Kill other threads u. Export confidential information u. Annoy • Play irritating sound and don’t stop • Display a large window that ignores mouse input • Flashing display (causes seizures in some users) u. Steal CPU cycles • For example, help attacker to crack passwords 22

More Security with Proxies Browser Network Proxy UI u Proxy intercepts request for web page u May modify bytecode before sending it to browser u Can do other checks: filter ads, block sites, etc. 23

Bytecode Modification Techniques u. Class-level replacement • • Define subclass of a library or any other class Replace references to original class with subclass Works because of subtyping Not possible if class has been declared “final” u. Method-level replacement • Change function calls to call new function • Generally, check or modify arguments and call original function 24

Sample Bytecode Modification u. Safe. Window class • Subclass of standard Window class – Do not allow windows larger than maximum – Do not allow more than max number of windows u. Restrict network activity • Replace call to Socket object constructor – Do not allow socket connection to port 25 to prevent the applet from forging email u. Maintain appearance of browser window • Replace calls to Applet. Context methods – Displayed URL must match actual hyperlink 25

Proof-Carrying Code [Necula et al] u. A code consumer must become convinced that the code supplied by an untrusted code producer has some set of properties u. PCC approach: • Code consumer publishes a safety policy – Set of conditions that a foreign program must satisfy for its execution to be considered safe • Code producer creates a formal safety proof – Proves that his code adheres to the safety policy • Code consumer uses a simple and fast proof validator to check that the proof is valid 26

PCC Architecture Source Program Compilation & Certification PCC Binary Native Code Safety Proof Enable CPU Code producer Code consumer’s runtime system Proof Validation Safety Policy 27

Certification u. Code producer compiles source code and verifies that the program satisfies the safety policy u. A proof of successful verification together with the native code forms the PCC binary • Compiler can create the proof automatically u. Code producer can store the resulting PCC binary for future use, or can deliver it to code consumers for execution 28

Validation and Execution u. Code consumer validates the proof part of PCC binary and loads the native code for execution u. Because proof has already been created by code producer, verification can be done offline and only once for a given program, regardless of how many times it is executed 29

Advantages of PCC u. Burden is mostly on the code producer u. Code consumer only has to perform a fast, simple, easy-to-trust proof checking • It’s much easier to check an existing proof than to prove that an arbitrary piece of code is correct u. No cryptography or trusted third parties • PCC binaries are “self-certifying” u. Code is verified before execution • Detect dangerous operations early, thus avoiding the need to kill the misbehaving process after it has acquired resources or modified system state 30