1. Java Security Updated May 2007

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

3. 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.

4. Is This Code Planting a Virus? http://toilette-humor.com/computer-at-night.html

5. 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

6. 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

7. Interpreters and Compilers Most languages are either compiled (C, C++, Pascal) or interpreted (Lisp, Haskell, BASIC). MyFile.cpp MyFile.exe compiler MyFile.l interpreter Source code object code

8. JVM Java is an interpreted language. Your source code is “compiled” to “bytecode” which is executed on the JVM (interpreted). 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.

9. Java and the JVM The.class file contain Java Bytecode which is interpreted by the JVM (which is platform specific) File.java File.class Compiler javac File.class Java (JVM)

10. 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

11. 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.

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

13. 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.

14. Source / Bytecode Produced This will fail in Java if d was not an int, but a program in C assumes d is in the right format public float add(float c, int d) { return c + d; } Method float add(float, int) fload_1 iload_2 I2f fadd freturn

15. Data Types All memory and data types include format info A 2 byte integer takes up more than 2 bytes in memory – there is something to indicate that it is an integer so it can’t be used as something else.

16. 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.

17. Other Sources of Error The bytecode instructions for array operations include bounds checking Branching instructions can only branch to instructions in the same method. Only return and invoke allow transfer of control outside a given method.

18. 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).

19. 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

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

21. Class Loader, Bytecode Verifier Class loader gets the needed class 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.

22. More Checks and Verifications Version number of compiler Number and type of parameters passed to an instruction of method is legal All bytecode has valid opcodes No local variable is used before it is initialized Symbolic reference check

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

24. 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).

25. 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.

26. 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.

27. 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

28. 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

29. 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.

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

31. Readings http://java.sun.com/sfaq http://www.javaworld.com/javaworld/jw-08-1997/jw-08-hood_p.html