Java Security

1. Java Security

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). Source code object code MyFile.cpp MyFile.exe compiler MyFile.l interpreter

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 Method float add(float, int) fload_1 iload_2 I2f fadd freturn public float add(float c, int d) { return c + d; }

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 Privilege • 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