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

5
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

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

7
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

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

9
No Pointers

• You just cant write a Java program to do damage
  like this.

void main() int randAddress randAddress
(int ) rand() randAddress rand()
10
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.

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

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

13
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

14
Run-time security

• Java Virtual Machine the runtime environment
• Bytecode verifier, class loader, runtime checks
• Sandbox evolution
• Security manager

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

16
Run Time Checks

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

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

18
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
  applets origin server are allowed.

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

20
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

21
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

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

23
Possible Problems

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

24
Readings

• http//java.sun.com/sfaq
• http//www.javaworld.com/javaworld/jw-08-1997/jw-0
  8-hood_p.html