Upload
wesley-parrish
View
231
Download
2
Embed Size (px)
Citation preview
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!)