1. Java Security Nathan Moore CS 665

2. 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

3. 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

4. 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

5. 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)

6. 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

7. 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

8. Why Java Needs Security Source Code Compiler Web Browser Byte Code Web Server JVM Internet Local System Resources External Control over System Resources

9. Java Sandbox Model gives untrusted code a place to “play”

10. 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

11. Java 2 Security Model (2)

12. 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.

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

23. 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

24. 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!)