(Duke suicide picture by Gary McGraw.)
CS201j: Engineering Software
University of Virginia
Computer Science
Lecture 19:
Security in Java
Real or Decaf?
David Evans
http://www.cs.virginia.edu/evans
Java : Programming Language
“A simple, object-oriented,
 distributed, interpreted, robust,
secure, architecture neutral,
portable, high-performance,
 multithreaded, and dynamic
 language.”
[Sun95]
6 November 2003
CS 201J Fall 2003
2
What is a secure programming
language?
1. Language is designed so it cannot
express certain computations
considered insecure.
A few attempt to do this: PLAN, packet filters
2. Language is designed so that
(accidental) program bugs are likely
to be caught by the compiler or runtime environment instead of leading
to security vulnerabilities.
6 November 2003
CS 201J Fall 2003
3
Safe Programming Languages
• Type Safety
– Compiler and run-time environment ensure that
bits are treated as the type they represent
• Memory Safety
– Compiler and run-time environment ensure that
program cannot access memory outside defined
storage
• Control Flow Safety
– Can’t jump to arbitrary addresses
Which of these does C/C++ have?
Is Java the first language to have them?
No way! LISP had them all in 1960.
6 November 2003
CS 201J Fall 2003
4
Java Safety
• Type Safety
– Most types checked statically
– Coercions, array assignments type checked
at run time
• Memory Safety
– No direct memory access (e.g., pointers)
– Primitive array type with mandatory runtime bounds checking
• Control Flow Safety
– Structured control flow, no arbitrary jumps
6 November 2003
CS 201J Fall 2003
5
Malicious Code
Can a safe programming language
protect you from malcode?
1. Code your servers in it to protect from
buffer overflow bugs
2. Only allow programs from untrustworthy
origins to run if the are programmed in
the safe language
6 November 2003
CS 201J Fall 2003
6
Safe Languages?
• But how can you tell program was
written in the safe language?
– Get the source code and compile it (most
vendors, and all malicious attackers refuse
to provide source code)
– Special compilation service
cryptographically signs object files
generated from the safe language (SPIN,
[Bershad96])
– Verify object files preserve safety
properties of source language (Java)
6 November 2003
CS 201J Fall 2003
7
JVML
malcode.java

Java
Source
Code
javac
Compiler
malcode.class
JVML
Object
Code
JavaVM
Joe User
6 November 2003
Joe wants to know JVML code satisfies
Java’s safety properties.
CS 201J Fall 2003
8
Does JVML satisfy Java’s
safety properties?
iconst_2
istore_0
aload_0
push integer constant 2 on stack
store top of stack in variable 0 as int
load object reference from variable 0
No! This code violates Java’s type rules.
6 November 2003
CS 201J Fall 2003
9
Running Mistyped Code
.method public static main([Ljava/lang/String;)V
…
iconst_2
istore_0
> java Simple
aload_0
Exception in thread "main" java.lang.VerifyError:
iconst_2
(class: Simple, method: main signature:
iconst_3
([Ljava/lang/String;)V)
iadd
Register 0 contains wrong type
…
return
.end method
6 November 2003
CS 201J Fall 2003
10
malcode.class
JVML
Object
Code
Bytecode Verifier
Trusted Computing Base
Java Bytecode Verifier
Invalid
“Okay”
STOP
JavaVM
Joe User
6 November 2003
CS 201J Fall 2003
11
Bytecode Verifier
• Checks class file is formatted correctly
– Magic number: class file starts with
0xCAFEBABE
– String table, code, methods, etc.
• Checks JVML code satisfies safety
properties
– Simulates program execution to know types
are correct, but doesn’t need to examine any
instruction more than once
6 November 2003
CS 201J Fall 2003
12
Verifying Safety Properties
• Type safe
– Stack and variable slots must store and load as same
type
• Memory safe
– Must not attempt to pop more values from stack than
are on it
– Doesn’t access private fields and methods outside
class implementation
• Control flow safe
– Jumps must be to valid addresses within function, or
call/return
6 November 2003
CS 201J Fall 2003
13
Running Mistyped Code
.method public static main([Ljava/lang/String;)V
…
iconst_2
istore_0
> java Simple
aload_0
Exception in thread "main" java.lang.VerifyError:
iconst_2
(class: Simple, method: main signature:
iconst_3
([Ljava/lang/String;)V)
iadd
Register 0 contains wrong type
…
return
.end method
6 November 2003
CS 201J Fall 2003
14
Running Mistyped Code
.method public static main([Ljava/lang/String;)V
…
iconst_2
istore_0
> java –noverify Simple
aload_0
result: 5
iconst_2
iconst_3
iadd
…
return
.end method
6 November 2003
CS 201J Fall 2003
15
Running Mistyped Code
.method public static main([Ljava/lang/String;)V
…
> java –noverify Simple
ldc 201
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION
(0xc0000005) occurred at PC=0x809DCEB
istore_0
Function=JVM_FindSignal+0x1105F
Library=C:\j2sdk1.4.2\jre\bin\client\jvm.dll
aload_0
iconst_2
Current Java thread:
at Simple.main(Simple.java:7)
iconst_3
…
iadd
#
…
# HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION
return
# Error ID : 4F530E43505002EF
.end method # Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
6 November 2003
CS 201J Fall 2003
16
Java
malcode.java
javac
Compiler
malcode.class
JVML
Trusted Computing Base
Java Bytecode Verifier
Invalid
“Okay”
STOP
JavaVM
Joe User
6 November 2003
CS 201J Fall 2003
17
JavaVM
• Virtual machine – interpreter for JVML
programs
• Has complete access to host machine
• Bytecode verifier ensures some safety
properties, JavaVM must ensure rest:
– Type safety of run-time casts, array
assignments
– Memory safety: array bounds checking
– Resource use policy
6 November 2003
CS 201J Fall 2003
18
Reference Monitors
6 November 2003
CS 201J Fall 2003
19
Program Execution
Monitor
Program
Speakers
Network
Disk
6 November 2003
Memory
CS 201J Fall 2003
SuperSoaker 2000
20
Program Execution
Reference Monitor
Monitor
Program
Speakers
Network
Disk
6 November 2003
Memory
CS 201J Fall 2003
SuperSoaker 2000
21
Ideal Reference Monitor
1. Sees everything a program is about to do
before it does it
2. Can instantly and completely stop
program execution (or prevent action)
3. Has no other effect on the program or
system
Can we build this?
Probably not unless we can build a time machine...
6 November 2003
CS 201J Fall 2003
22
RealReference Monitor
Ideal
most things
1. Sees everything a program is about to do
before it does it
2. Can instantly and completely stop
program execution (or prevent action)
limited
3. Has no other effect on the program or
system
6 November 2003
CS 201J Fall 2003
23
Operating Systems
• Provide reference monitors for most
security-critical resources
– When a program opens a file in Unix or
Windows, the OS checks that the principal
running the program can open that file
• Doesn’t allow different policies for different
programs
• No flexibility over what is monitored
– OS decides for everyone
– Hence, can’t monitor inexpensive operations
6 November 2003
CS 201J Fall 2003
24
Java Security Manager
• (Non-Ideal) Reference monitor
– Limits how Java executions can manipulate
system resources
• User/host application creates a subclass of
SecurityManager to define a policy
6 November 2003
CS 201J Fall 2003
25
JavaVM Policy Enforcment
[JDK 1.0 – JDK 1.1]
From java.io.File:
public boolean delete() {
SecurityManager security =
System.getSecurityManager();
checkDelete throws a
if (security != null) {
SecurityExecption if the
security.checkDelete(path); delete would violate the policy
(re-thrown by delete)
}
if (isDirectory()) return rmdir0();
else return delete0();
}
What could go seriously wrong with this?!
6 November 2003
CS 201J Fall 2003
26
HotJava’s Policy (JDK 1.1.7)
public class AppletSecurity
extends SecurityManager {
...
public synchronized
void checkDelete(String file)
throws Security Exception {
checkWrite(file);
}
}
6 November 2003
CS 201J Fall 2003
27
AppletSecurity.checkWrite
(some exception handling code removed)
public synchronized void checkWrite(String file) {
if (inApplet()) {
if (!initACL) initializeACLs();
String realPath =
(new File(file)).getCanonicalPath();
for (int i = writeACL.length ; i-- > 0 ;) {
if (realPath.startsWith(writeACL[i])) return;
}
throw new AppletSecurityException
("checkwrite", file, realPath);
}
}
Note: no checking if not inApplet!
Very important this does the right thing.
6 November 2003
CS 201J Fall 2003
28
inApplet
boolean inApplet() {
return inClassLoader();
}
Inherited from java.lang.SecurityManager:
protected boolean inClassLoader() {
return
currentClassLoader() != null;
}
6 November 2003
CS 201J Fall 2003
29
currentClassLoader
/**
Returns an object describing the most recent class
loader executing on the stack.
Returns the class loader of the most recent
occurrence on the stack of a method from a class
defined using a class loader; returns null if there is
no occurrence on the stack of a method from a
class defined using a class loader.
*/
protected native ClassLoader currentClassLoader();
6 November 2003
CS 201J Fall 2003
30
Recap
• java.io.File.delete
calls
before deleting
• HotJava overrides SecurityManager with
AppletSecurity to set policy
• AppletSecurity.checkDelete calls
SecurityManager.checkDelete
AppletSecurity.checkWrite
• AppletSecurity.checkWrite checks if
any method on stack has a ClassLoader
• If not no checks; if it does, checks ACL list
6 November 2003
CS 201J Fall 2003
31
JDK 1.0 Trust Model
• When JavaVM loads a class from the
CLASSPATH, it has no associated
ClassLoader (can do anything)
• When JavaVM loads a class from
elsewhere (e.g., the web), it has an
associated ClassLoader
6 November 2003
CS 201J Fall 2003
32
JDK Evolution
• JDK 1.1: Signed classes from
elsewhere and have no associated
ClassLoader
• JDK 1.2:
– Different classes can have different policies
based on ClassLoader
– Explict enable/disable/check privileges
– SecurityManager is now AccessController
6 November 2003
CS 201J Fall 2003
33
What can go wrong?
• Java API doesn’t call right SecurityManager
checks (63 calls in java.*)
– Font loading bug, synchronization
• ClassLoader is tricked into loading external
class as internal
• Bug in Bytecode Verifier can be exploited to
circumvent SecurityManager
• Policy is too weak (allows damaging behavior)
• Next class: how to break everything with a hair
dryer!
6 November 2003
CS 201J Fall 2003
34
Hostile Applets
• See http://java.sun.com/sfaq/chronology.html
(about 1 new vulnerability/month)
• Easy to write “annoying” applets (policy is
too imprecise; no way to constrain many
resource operations)
• Don’t try these until you finish PS5:
http://www.cigital.com/hostile-applets/index.html
6 November 2003
CS 201J Fall 2003
35
Charge
•
•
PS5 Due Tuesday
Two options for turning in PS5: read the
notes carefully
If your program works, you do not need to
turn in a printout of all your code.
6 November 2003
CS 201J Fall 2003
36