java security updated may 2007. topics intro to the java sandbox language level security run time...
TRANSCRIPT
Java Security
Updated May 2007
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.
Is This Code Planting a Virus?
http://toilette-humor.com/computer-at-night.html
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
Interpreters and Compilers Most languages are either compiled (C, C+
+, Pascal) or interpreted (Lisp, Haskell, BASIC).
MyFile.cpp MyFile.execompiler
MyFile.l
interpreter
Source code object code
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.
Java and the JVM The .class file contain Java Bytecode which is
interpreted by the JVM (which is platform specific)
File.java File.classCompiler javac
File.class
Java (JVM)
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.
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
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.
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.
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.
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
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.
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
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
http://java.sun.com/sfaq
http://www.javaworld.com/javaworld/jw-08-1997/jw-08-hood_p.html