Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

33
Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008

Transcript of Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Page 1: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java Security

John Mitchell

CS 242

Reading: Chapter 13 (+Slides contain additional material)

2008

Page 2: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Outline

Language Overview• History and design goals

Classes and Inheritance• Object features• Encapsulation• Inheritance

Types and Subtyping• Primitive and ref types• Interfaces; arrays• Exception hierarchy

Generics• Subtype polymorphism.

generic programming

Virtual machine overview• Loader and initialization• Linker and verifier• Bytecode interpreter

Method lookup• four different bytecodes

Verifier analysis Implementation of generics Security

• Buffer overflow• Java “sandbox”• Type safety and attacks

Page 3: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java Security

Security : “Bad stuff does not happen”• Prevent unauthorized use of computational resources

Java security• Java code can read input from careless user or

malicious attacker• Java code can be transmitted over network – code may be written by careless friend or malicious

attacker– Distributed applications– Browser applets

Java is designed to reduce many security risks

Page 4: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Buffer Overflow Attack

Most prevalent general security problem today• Large number of CERT advisories are related to

buffer overflow vulnerabilities in OS, other code

General network-based attack• Attacker sends carefully designed network msgs• Input causes privileged program (e.g., Sendmail)

to do something it was not designed to do

Does not work in Java• Illustrates what Java was designed to prevent

Bad-input-to-good-Java-code attack:

Page 5: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Sample C code to illustrate attack

void f (char *str) { char buffer[16]; … strcpy(buffer,str);}void main() { char large_string[256]; int i; for( i = 0; i < 255; i++)

large_string[i] = 'A';

f(large_string);}

Function• Copies str into buffer until null

character found• Could write past end of buffer,

over function retun addr

Calling program• Writes 'A' over f activation record• Function f “returns” to location

0x4141414141• This causes segmentation fault

Variations• Put meaningful address in string• Put code in string and jump to it !!

See: Smashing the stack for fun and profit

Page 6: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java Security Mechanisms

Sandboxing• Run program in restricted environment

– Analogy: child’s sandbox with only safe toys

• This term refers to – Features of loader, verifier, interpreter that restrict

program– Java Security Manager, a special object that acts as

access control “reference monitor”

Code signing• Use cryptography to establish origin of class file

– This info can be used by security manager

+ Bad-Java-code-on-good-platform attacks:

Page 7: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

The Java 1.0 sandbox

Local code subject to Java language restrictions only Downloaded code (applet) further restricted to sandbox

• cannot access the local file system• cannot access system resources,• can establish network connection only to originating web server

JVM

sandbox

resources

remote code(applets)

local code

Page 8: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

JavaVM Policy Enforcment

From java.io.File: public boolean delete() { SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkDelete(path); } if (isDirectory()) return rmdir0(); else return delete0(); }

[JDK 1.0 – JDK 1.1]

What could go seriously wrong with this?!

checkDelete throws a SecurityExecption if the delete would violate the policy (re-thrown by delete)

Slide: David Evans

Page 9: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

HotJava’s Policy (JDK 1.1.7)

public class AppletSecurity extends SecurityManager {...public synchronized

void checkDelete(String file) throws Security Exception { checkWrite(file); }}

Slide: David Evans

Page 10: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java 1.1 trusted code

Trust code from trusted sources• Local file system• Signed by trusted principal

JVM

sandbox

resources

remote code(applets)

local code

signed andtrusted

unsigned, orsigned and

untrusted

Page 11: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java 2 Finer grained access control

All access to system resources based on policy file• Protection domain: code source and permissions granted• Code source consists of a URL and an optional signature • Permissions granted in policy file

grant CodeBase “http://java.sun.com”, SignedBy “Sun” { permission java.io.FilePermission “${user.home}${/}*”, “read,

write”; permission java.net.SocketPermission “localhost:1024-”,

“listen”;};

JVM

resources

local or remote code(signed or unsigned)

class loaders

policyfile

Page 12: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Reference Monitor

Basic concept in security• Introduced by Lampson in 1970s• Part of “Trusted Computing Base” (TCB)

Requirements for reference monitor• Mediate all requests to access protected

resources• Ideally:

– Tamperproof– Verifiable– Always invoked

These are ideal requirements, not generally met in practice

Page 13: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java Sandbox

Four complementary mechanisms• Class loader

– Separate namespaces for separate class loaders– Associates protection domain with each class

• Verifier and JVM run-time tests– NO unchecked casts or other type errors, NO array

overflow– Preserves private, protected visibility levels

• Security Manager– Called by library functions to decide if request is allowed– Uses protection domain associated with code, user policy– Coming up in a few slides: stack inspection

Page 14: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

The Java Virtual Machine (JVM)

class loaderinstance

class fileverifier

JIT

primordialclass loader

native methodloader

native methodarea

executionengine

SecurityManager

classarea

heap

operating system

Java code

native code

network

untrusted classes

trusted classes

native methods

local

JVM

More details than earlier picture ...

Page 15: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Who loads the class loader?

Class loaders• locate and load classes into the JVM• primordial class loader

– loads trusted classes (system classes on the boot class path)

– integral part of the JVM

• class loader instances– Implemented by applications– Load untrusted classes from file system or network– Instances of java.net.URLClassLoader

• which extends SecureClassLoader

Page 16: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Class loader security mechanism

separate name spaces• classes loaded by a class loader instance belong to the same

name space• since classes with the same name may exist on different Web

sites, different Web sites are handled by different instances of the applet class loader

• a class in one name space cannot access a class in another name space

classes from different Web sites cannot access each other establish the protection domain (set of permissions) for a

loaded class enforce a search order that prevents trusted system classes

from being replaced by classes from less trusted sources• see next two slide …

Page 17: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Class loading process

when a class is referenced JVM: invokes the class loader associated with the requesting program class loader: has the class already been loaded?

• yes: – does the program have permission to access the class?

• yes: return object reference• no: security exception

• no: – does the program have permission to create the requested class?

• yes:– first delegate loading task to parent– if parent returns success, then return (class is loaded)– if parent returned failure, then load class and return

• no: security exception

Page 18: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Class loading task delegation

primordial class loader(searches on

the boot class path)

a class loader instancestarted at JVM startup

(searches on the class path)

a class loader instance associated with a URL(searches on the site specified by the URL)

class request1

2

3

loads class from boot class path

4a

failure4b

loads class fromclass path

5a

success / failure5b

loads class from URL6

Page 19: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Byte code verifier

performs static analysis of the bytecode• syntactic analysis

– all arguments to flow control instructions must cause branches to the start of a valid instruction

– all references to local variables must be legal– all references to the constant pool must be to an entry of appropriate

type– all opcodes must have the correct number of arguments– exception handlers must start at the beginning of a valid instruction– …

• data flow analysis– attempts to reconstruct the behavior of the code at run time without

actually running the code– keeps track only of types not the actual values in the stack and in

local variables• it is theoretically impossible to identify all problems that may

occur at run time with static analysis

Page 20: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Verifier (should be) Conservative

JVML programs

Safe programs

Verifiable programs

Slide: Nate Paul’s ACSAC talk

Page 21: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Complexity Increases Risk

JVML programs

Safe programs

Verifiable programs

Bug

Slide: Nate Paul’s ACSAC talk

Page 22: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Security Manager

Java library functions call security manager Security manager object answers at run

time • Decide if calling code is allowed to do operation • Examine protection domain of calling class

– Signer: organization that signed code before loading– Location: URL where the Java classes came from

• Uses the system policy to decide access permission

Page 23: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

The Security Manager

Implements a checkPermission() method• CheckPermission() is called from trusted system classes

– e.g., if you want to open a socket you need to create a Socket object

– the Socket class is a trusted system class that always invokes the checkPermission() method

Is effective to the extent that• system resources are accessible only via trusted system

classes• trusted system classes cannot be overwritten

Relies on class loader• To make sure trusted system classes are not

overridden.

Page 24: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Redefining the Security Manager

JVM allows only one active SM at a time• Default SM provided by the JDK

Java programs can replace the default SM • Two permissions are needed:

– create an instance of SecurityManager– set an SM instance as active

• Example:grant CodeBase “…”, SignedBy “…” { permission java.lang.RuntimePermission “createSecurityManager”; permission java.lang.RuntimePermission “setSecurityManager”;};

– SecurityManager constructor, setSecurityManager() call the checkPermissions() method of current SM to verify the caller has needed permissions

Page 25: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Confused Deputy

KeyKOS story• Compiler writes errors into user-designated log file• User can’t change accounting file, but compiler can• User designates accounting file as compiler log file• Reference: Norm Hardy , The Confused Deputy (…)

Early Netscape problem• Applet asks font manager for “password file” font• Font manager can’t find it so asks system registry• System registry trusts font manager, so turns it over• Font manager gives password file to applet

Page 26: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Stack Inspection

Permission depends on• Permission of calling

method• Permission of all methods

above it on stack– Up to method that is

trusted and asserts this trust

Many details omitted here

java.io.FileInputStream

method f

method g

method h

Stories: Netscape font / passwd bug; Shockwave plug-in

Page 27: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Vulnerabilities in JavaVM

0

5

10

15

20

25

30

35

40

45

0 1 2 3 4 5 6 7 8 9

Vuln

era

bili

ties

Report

ed

Years Since First ReleaseJuly 1996 July 2005

Slide: David Evans

Page 28: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Where are They?

Verification 12

API bugs 10

Class loading 8

Other or unknown 2

Missing policy checks 3

Configuration 4

DoS attacks (crash, consumption) 5

several of these were because of jsr complexity

Slide: David Evans

Page 29: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Beyond JVM security

JVM does not prevent• Denial of service attacks

– Applet creates large windows and ignores mouse

• Certain network behavior– Applet can connect to port 25 on client machine,

forge email (on some implementations)

• URL spoofing– Applet can write false URL on browser status line

• Annoying behavior– Applet can play loud sound– Applet can reload pages in new windows

Page 30: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

E: Electric Communities

Electronic communities• Planned network of interacting virtual realities• Example: automated garden (in Netherlands?) with watering

can

E programming language • Distributed communication

– An object may send messages directly to objects that exist in other machines

• Capability system– Goal: detailed control over sensitive functions within a single

machine or across a network

• Optimistic computation– Reduces the effect of communications latency in distributed

systems

Page 31: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Java capability example

Give untrusted object read access to a file• Pass the name of the file • Pass the File object • Pass a ReadStream on the File object

Problem• Given Java ReadStream, can request the File object of the

ReadStream, then access file, directory structure, etc. E approach

• Capabilities are granted to E objects at load time. – A cryptographic signature and a set of capability requirements are

attached to every E object

See Amoeba OS papers for good description of capability system

Page 32: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.

Lots more information in books, online

Page 33: Java Security John Mitchell CS 242 Reading: Chapter 13 (+Slides contain additional material) 2008.