Java Security

Topics Intro to the Java Sandbox Language Level Security Run Time Security Evolution of Security Sandbox Models The Security Manager

Internet Security Needed Nowadays, code is downloaded from the Internet and executed transparently by millions of users. Downloaded software can hide all sorts of hazardous code. Games and music are often Trojan horses, spyware and virus installers. There is a real need for a more security mechanism for mobile code.

Writing Secure Code Software developers also have security problems to handle. Programmers unknowingly leave holes in their code that hackers can exploit. –Forgetting to deallocate resources. –An open socket connection is like an open invitation to a hacker. –Memory leaks can be exploited –Buffer overflow

The Java Solution Java Virtual Machine creates a sandbox Syntax - insecure operations cannot even be represented Automatic garbage collection prevents memory leaks Security Manager watches for anomalies during execution and can take action

JVM Java is an interpreted language. Your source code is “compiled” to “bytecode” which is executed on the JVM. The Java Virtual Machine (JVM) observes each instruction (bytecode) before it is used. This allows Java to provide the idea of a sandbox, which limits how an untrusted program can affect the system it runs on.

Language Level Security No pointers or pointer arithmetic No way to represent unstructured memory Variables, methods and classes can be final Compiler checks variable instantiation and typecasts

No Pointers Pointers and pointer arithmetic allow attackers to access any byte in memory. In C, strings and arrays are essentially unstructured memory. They start with a pointer and operations on the array are done by manipulating the pointer. There is no bounds checking. The Java programmer cannot represent or manipulate pointers.

No Pointers You just can’t write a Java program to do damage like this. void main() { int *randAddress; randAddress = (int *) rand(); *randAddress = rand(); }

No Unstructured Memory Access Unstructured memory access (or unenforced structure) can be exploited. In C and C++, character data can be written to memory allocated as integer. Character or integer data can be read and interpreted as Boolean. Java prevents data of one type from being used as a different type – cannot be expressed in bytecode.

Unspecified Memory Layout The JVM stores several types of data to execute a program –Runtime stacks – one for each thread –Bytecode for methods –Dynamic memory heap and garbage collection area The storage layout is not defined for the JVM. Each implementation does it differently.

The Keyword final This keyword can be used to prevent variables, methods and classes from being changed (and potentially exploited). The value of a variable is fixed for the duration of the execution. A method cannot be modified in subclasses (hacker tactic to use permission levels of original method) Class cannot have subclasses (subclass of API would have full system access).

The Compiler The compiler checks code and produces bytecode (intermediate representation interpreted by all JVMs). Checks that: –variables are instantiated before they are used. –Type casts are legal (prevents unstructured memory exploits) –Methods called by appropriate type objects

Run-time security Java Virtual Machine – the runtime environment –Bytecode verifier, class loader, runtime checks –Sandbox evolution –Security manager

Bytecode Verifier, Class Loader Bytecode verifier runs first and guards against circumvention of compiler checks with handwritten bytecode. Class loader checks permissions and helps to prevent the loading of “Trojan Horse” methods.

Run Time Checks Bounds checking on arrays (no buffer overflow) Type cast checking Automatic garbage collection (memory leaks can lead to DOS attacks

The Sandbox Idea The original Java release, jdk1.0, provided a system that used the basic sandbox model. Differentiated only between native code (code stored locally, trusted, given full access) and non-native code (applets downloaded, not trusted).

JDK 1.0 Sandbox Trusted code can read, write and delete any file, start and kill threads and open, use and close socket connections without any restrictions. Untrusted code cannot access any files, threads are hidden and only socket connections to the applet’s origin server are allowed.

JDK 1.1: More Flexible Native code is trusted and treated as in JDK1.0 Non-native code can be trusted or non- trusted. –If the.jar file has a valid digital signature and comes from a “trusted developer” (list is part of the JVM) code is considered trusted and given same rights as native code. –Otherwise, untrusted and restrictions apply.

JDK 1.2 ALL code (even native) is subject to a security policy that can be defined by the user. Permissions are checked against the policy when the class is loaded AND whenever restricted actions are attempted. Promotes Principle of Least Priviledge Performs Complete Mediation

JDK 1.2 Restricted Actions Accept a socket connection Open a socket connection Wait for a connection on a port Create a new process Modify a thread Cause the application to exit Load a dynamic library that contains native methods Access or modify system properties Read from a file Write to a file Delete a file Create a new class loader Load a class from a specified package Add a new class to a specified package

The Security Manager The part of the JVM that performs these run time checks is called the security manager JDK 1.2 or later (a.k.a. Access Manager) In addition the security manager watches other potential security holes and can react if needed.

Possible Problems Security features not automatic if Java program is invoked on the command line And others as yet undiscovered …

Readings