java security nathan moore cs 665. overview survey of java inherent security properties java runtime...

Java Security

Nathan Moore

CS 665

Overview

Survey of Java Inherent Security Properties Java Runtime Environment Java Virtual Machine

Java Security Model and Java Security Architecture

Java 6 SE Security Extensions Known Vulnerabilities of Java Future of Java Security

Inherent Java Security (1)

Every entity has an associated Access Level: Public, Protected, Default/Package, Private Provides encapsulation

A strongly typed language: Restrictions on how data types can be mixed

No direct memory access No notion of pointers Entities are accessed via references (by name)

Variables must be initialized before they are used

Inherent Java Security (2)

Objects can’t be arbitrarily cast into other objects (ensures a type safe environment): Strict use of extends, implements (inheritance) Compile time type checking of casting

Programmers stringently declare the types of all storage locations and return values

Inherent Java Security (3)

Common exceptions can easily be caught/thrown during run time NullPointer, ArrayIndexOutOfBounds, etc.

Provides automatic memory management, garbage collection, and array range-checking

Compiler and virtual machines perform compile time and run time checks (respectively)

The Java Runtime Environment (JRE)

Consists of the Java Virtual Machine (JVM) and Class Libraries

JVM: available for most platforms, provides the environment for java bytecode to execute

Class Libraries: The Core Java API, contains classes for language support and added functionality

Java Virtual Machine (JVM)

Platform Independence: “Write once, run anywhere!”

Is an abstract virtual machine Diff. implementations: Sun, IBM, Oracle, MS Each thread has its own stack Typical instruction set: Load/Store, Arithmetic, etc.

Interprets bytecode generated by Java compilers

Why Java Needs Security

SourceCode

Compiler

Web BrowserByteCode

Web Server

JVMInternet

Local SystemResources

External Control over System Resources

Java Sandbox Model

gives untrusted code a place to “play”

Java 2 Security Model

All local or remote code passes through a Security Policy to determine what resources it has access to

Configurable Security Policies provides fine-grained access control

May or may not be provided, default security settings exist for untrusted code

Java 2 Security Model (2)

Stage 1: Accessing the Classes

Need to get the local and remote classes required for program execution

By default: only built in (Core API) code is trusted Local, Remote (Applet) code is untrusted

Byte Code Verifier: performs checks on untrusted code file format, object references, method calls,

parameter and return value validity, pointer forgery, stack overflows, array indices, etc.

ClassLoader

JavaClassFile

Verifier

JVM

Stage 2: Loading Classes

Class Loader: uses dynamic linking to load classes at runtime Loads from different locations (file

system/classpath, applet class) Prevents class spoofing (has been

bypassed) Manages Java’s namespace definitions

(naming scope) cs665.String vs. Java.lang.String

Consults the Security Manager to see is program has permission to access a class

ClassLoader

JavaClassFile

Verifier

JVM

Stage 3: Program Execution

Security Manager: Core component for implementing a

custom Policy queried by the JVM each time untrusted

code attempts to access a system resource

Uses Access Controller to see if queries are permitted, throws a generic Security Exception otherwise

JavaClass

SecurityManager

JVM

SystemResource

Stage 3: Policy Class (Dev)

Manages class permissions to system resources Protection Domains: can associate one or more

classes with a set of permissions Policy assigns each class to a Protection Domain

Class C

Class BTrustedClasses

Other Resources

Class A

Domain 2 System Domain

Domain 1

Stage 3: AccessController Class

Invoked by the Security Manager Makes a decision based on: class domain in

the Security Policy, and a stack inspection Stack inspection: a check on a sequence of

class calls for resources and their resulting approval or denial

Default Security Protection

Only built in, Core API code is trusted Applets are restricted from:

Local file system access Creating network connections Creating security components (e.g.. Class Loader) Accessing user information

Applications: No default security restrictions Implementing a Security Manager is optional

Java Cryptography Architecture (JCA)

Part of Java SE 6, supports use of third party packages and is itself a “provider”

Provides many different security services: digital signatures message digests: SHA-1 certificates and certificate validation: X.509 symmetric/asymmetric block/stream ciphers

encryption: DSA, RSA key generation and management secure random number generation

JCA

Ex: A Public Key and Signature (packaged as a Certificate) can be used to verify code integrity and validity of source

Web Server

ByteCode

Private KeyAlgorithm

SignatureAlgorithm

Web Browser

ByteCode

Public Key Algorithm

SignatureAlgorithm

JVMInternet

Byte Code+ Certificate

Java Authentication and Authorization Service (JAAS)

Java Authentication and Authorization Service Can be used for two purposes:

authentication of users authorization of users

Provides access controls based on who the user is and that users associated permissions

Upon user authentication, JAAS coordinates with the Security Manager and Access Controller

Custom Security Models

Components of the Security Architecture (except for Verifier) are customizable

Users: can specify own local security policy Policy Tool: GUI used to customize JRE Policy

Developers: can customize everything else (Security Manager,

Policy, AccessController, etc.) can use JCA and JAAS

Users are responsible for their own protection

Security Weaknesses

Fine-grained control with a price: complexity Relies on user to secure their own

environment via a complex Policy Tool JVM Implementations: each have their own

unique vulnerabilities Reverse engineering of class files to source

code (obfuscation is not the answer) Many severe flaws have been addressed

over the evolution of Java and the JVM

Famous Exploits (fixed)

Jumping the Firewall: the only network connection an Applet can make is to its server of origin Steve Gibbons bypassed this security measure in

1996 using a DNS security flaw Slash and Burn: exploited the Dots and

Slashes rule, which is used to search for local class files Malicous applets were able to execute

The Future of Java Security

Java SE 6 is fully open source under GPL license Common misconceptions: open source = open

code (i.e. insecure) Reality: open sourcing Java allows all aspects to

be scrutinized by thousands of people Community Impact: existing security flaws will be

publicized and addressed swiftly Many services are already provided, the next step is

making them easier to use (hopefully!)