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 Source Code Compiler Web Browser Byte Code Web Server JVM Internet Local System Resources 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.

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

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

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

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

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: o pen 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!)