Transcript Lecture 20 - University of Virginia

(Duke suicide picture by Gary McGraw.)
CS201j: Engineering Software
University of Virginia
Computer Science
Lecture 20:
Security in Java /
Java (In?) Security
David Evans
http://www.cs.virginia.edu/evans
Menu
• Low-level Code Safety
– Java Byte Code Verifier
• Policy Code Safety
– Reference Monitors
– Java’s Security Manager
14 November 2002
CS 201J Fall 2002
2
Java Security
Real or Decaf?
14 November 2002
CS 201J Fall 2002
3
Java : Programming Language
“A simple, object-oriented,
distributed, interpreted, robust,
secure, architecture neutral,
portable, high-performance,
multithreaded, and dynamic
language.”
[Sun95]
14 November 2002
CS 201J Fall 2002
4
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.
14 November 2002
CS 201J Fall 2002
5
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.
14 November 2002
CS 201J Fall 2002
6
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 run-time
bounds checking
• Control Flow Safety
– Structured control flow, no arbitrary jumps
14 November 2002
CS 201J Fall 2002
7
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
14 November 2002
CS 201J Fall 2002
8
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)
14 November 2002
CS 201J Fall 2002
9
JVML
malcode.java

Java
Source
Code
javac
Compiler
malcode.class
JVML
Object
Code
JavaVM
Joe User
14 November 2002
Joe wants to know JVML code satisfies
Java’s safety properties.
CS 201J Fall 2002
10
Does JVML satisfy Java’s
safety properties?
iconst_2
istore_0
aload_0
arraylength
push integer constant 2 on stack
store top of stack in variable 0 as int
load object reference from variable 0
replace array on top of stack with its
length
No! This code violates Java’s type rules.
14 November 2002
CS 201J Fall 2002
11
Do Java Byte Codes provide
these?
• Type Safety
iconst_3
iconst_3
fadd
astore_1
iload_1
• Memory Safety
iconst_3
iadd
• Control Flow Safety
ifeq 2359
14 November 2002
CS 201J Fall 2002
12
malcode.class
JVML
Object
Code
Bytecode Verifier
Trusted Computing Base
Java Bytecode Verifier
Invalid
“Okay”
STOP
JavaVM
Joe User
14 November 2002
CS 201J Fall 2002
13
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
14 November 2002
CS 201J Fall 2002
14
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
check this in bytecode verifier, VM must
– Array bounds? Can’t
check array bounds at run time.
• Control flow safe
– Jumps must be to valid addresses within
function, or call/return
14 November 2002
CS 201J Fall 2002
15
Are Java Bytecode Verifiers
Complicated?
• ~700 rules to enforce, JVML specification is (not
all clearly specified)
• Emin Gün Sirer found > 100 bugs in commercial
bytecode verifiers (using automatic test
generation)
– At least 15 of them were security vulnerabilities
• JVML includes jsr instruction (jump to
subroutine), can be called with different types in
variables and on stack
Added to allow implementations to reuse code in finally blocks
to save code size. Would have saved more space to
keep original language name (“Oak”).
14 November 2002
CS 201J Fall 2002
16
Java
malcode.java
javac
Compiler
malcode.class
JVML
Trusted Computing Base
Java Bytecode Verifier
Invalid
“Okay”
STOP
JavaVM
Joe User
14 November 2002
CS 201J Fall 2002
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
14 November 2002
CS 201J Fall 2002
18
Reference Monitors
14 November 2002
CS 201J Fall 2002
19
Program Execution
Monitor
Program
Speakers
Network
Disk
14 November 2002
Memory
CS 201J Fall 2002
SuperSoaker 2000
20
Program Execution
Reference Monitor
Monitor
Program
Speakers
Network
Disk
14 November 2002
Memory
CS 201J Fall 2002
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...
14 November 2002
CS 201J Fall 2002
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
14 November 2002
CS 201J Fall 2002
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
14 November 2002
CS 201J Fall 2002
24
Reference Monitor as Finite
State Automaton [Schneider99]
All other
instructions
0
All other
instructions
Aim
Aim
1
Aim
Fire
2
All other
instructions
Fire
STOP
Policy Violation
14 November 2002
CS 201J Fall 2002
25
What policies can be enforced?
• Assume:
– Security Automaton can see entire state of
world, everything about instruction about to
execute
– Security Automaton has unlimited memory,
can do unlimited computation
• Are there interesting policies that still can’t
be enforced?
14 November 2002
CS 201J Fall 2002
26
What’s a Security Policy?
• What’s a program?
– A set of possible executions
• What’s an execution?
– A sequence of states
• What’s a security policy?
– A predicate on a set of executions
14 November 2002
CS 201J Fall 2002
27
Reference Monitors cannot
enforce all Security Policies
• Some policies depend on:
– Knowing about the future
• If the program charges the credit card, it must
eventually ship the goods
– Knowing about all possible executions
• Information flow – can’t tell if a program reveals
secret information without knowing about other
possible executions
• Reference Monitors can only know
about past of this particular execution
14 November 2002
CS 201J Fall 2002
28
Safety Policies
• Reference monitors can only enforce
safety policies
• Safety policy is a predicate on a prefix
of states (see Schneider98 for more
formal definition)
– Cannot depend on future: prefix means
once it is false, it is always false
– Cannot depend on other possible
executions
14 November 2002
CS 201J Fall 2002
29
JavaVM Policy Enforcment
[JDK 1.0 – JDK 1.1]
From java.io.File:
public boolean delete() {
SecurityManager security =
System.getSecurityManager();
if (security != null) {
security.checkDelete(path);
}
if (isDirectory()) return rmdir0();
else return delete0();
}
14 November 2002
CS 201J Fall 2002
30
java.lang.SecurityManager
/**
Throws a SecurityException if the calling
thread is not allowed to delete the specified
file.
This method is invoked for the current security
manager by the delete method of class File.
*/
(Some other comments deleted.)
public void checkDelete(String file) {
throw new SecurityException();
}
14 November 2002
CS 201J Fall 2002
31
Security Manager
• Reference monitor
– How well does it satisfy the requirements?
• Complete mediation
• Can stop execution/prevent action
• Limited effect on execution until policy violation
• User/host application creates a subclass
of SecurityManager to define a policy
14 November 2002
CS 201J Fall 2002
32
JavaVM Policy Enforcment
[JDK 1.0 – JDK 1.1]
From java.io.File:
public boolean delete() {
SecurityManager security =
System.getSecurityManager();
if (security != null) {
security.checkDelete(path);
}
if (isDirectory()) return rmdir0();
else return delete0();
}
What could go seriously wrong with this?!
14 November 2002
CS 201J Fall 2002
33
HotJava’s Policy (JDK 1.1.7)
public class AppletSecurity
extends SecurityManager {
...
public synchronized void
checkDelete(String file) {
checkWrite(file);
}
...
}
14 November 2002
CS 201J Fall 2002
34
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.
14 November 2002
CS 201J Fall 2002
35
inApplet
boolean inApplet() {
return inClassLoader();
}
Inherited from java.lang.SecurityManager:
protected boolean inClassLoader() {
return
currentClassLoader() != null;
}
14 November 2002
CS 201J Fall 2002
36
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();
14 November 2002
CS 201J Fall 2002
37
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
14 November 2002
CS 201J Fall 2002
38
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
14 November 2002
CS 201J Fall 2002
39
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
14 November 2002
CS 201J Fall 2002
40
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 and allows damaging
behavior
14 November 2002
CS 201J Fall 2002
41
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)
• After your PS6 phylogeny programs finish
on all the ITC machines, try
http://www.cigital.com/hostile-applets/index.html
14 November 2002
CS 201J Fall 2002
42
Charge
• No classes next week
• Exams due before 4:30pm Tuesday, drop
off to Brenda Perkins
14 November 2002
CS 201J Fall 2002
43