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

Outline uLanguage Overview History and design goals uClasses and Inheritance Object features Encapsulation Inheritance uTypes and Subtyping Primitive and ref types Interfaces; arrays Exception hierarchy uGenerics Subtype polymorphism. generic programming u Virtual machine overview Loader and initialization Linker and verifier Bytecode interpreter u Method lookup four different bytecodes u Verifier analysis u Implementation of generics u Security Buffer overflow Java “sandbox” Type safety and attacks

Java Security uSecurity : “Bad stuff does not happen” Prevent unauthorized use of computational resources uJava 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

Buffer Overflow Attack uMost prevalent general security problem today Large number of CERT advisories are related to buffer overflow vulnerabilities in OS, other code uGeneral 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 uDoes not work in Java Illustrates what Java was designed to prevent Bad-input-to-good-Java-code attack:

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); } u Function Copies str into buffer until null character found Could write past end of buffer, over function retun addr u Calling program Writes 'A' over f activation record Function f “returns” to location 0x This causes segmentation fault u Variations Put meaningful address in string Put code in string and jump to it !! See: Smashing the stack for fun and profit

Java Security Mechanisms uSandboxing 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” uCode signing Use cryptography to establish origin of class file –This info can be used by security manager + Bad-Java-code-on-good-platform attacks:

The Java 1.0 sandbox uLocal code subject to Java language restrictions only uDownloaded 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

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

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

Java 1.1 trusted code uTrust code from trusted sources Local file system Signed by trusted principal JVM sandbox resources remote code (applets) local code signed and trusted unsigned, or signed and untrusted

Java 2 Finer grained access control uAll 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 “ 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 policy file

Reference Monitor u Basic concept in security Introduced by Lampson in 1970s Part of “Trusted Computing Base” (TCB) uRequirements for reference monitor Mediate all requests to access protected resources Ideally: –Tamperproof –Verifiable –Always invoked These are ideal requirements, not generally met in practice

Java Sandbox uFour 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

The Java Virtual Machine (JVM) class loader instance class file verifier JIT primordial class loader native method loader native method area execution engine Security Manager class area heap operating system Java code native code network untrusted classes trusted classes native methods local JVM More details than earlier picture...

Who loads the class loader? uClass 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

Class loader security mechanism useparate 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 uestablish the protection domain (set of permissions) for a loaded class uenforce a search order that prevents trusted system classes from being replaced by classes from less trusted sources see next two slide …

Class loading process when a class is referenced uJVM: invokes the class loader associated with the requesting program uclass 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

Class loading task delegation primordial class loader (searches on the boot class path) a class loader instance started 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 request 1 23 loads class from boot class path 4a failure 4b loads class from class path 5a success / failure 5b loads class from URL 6

Byte code verifier uperforms 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

Verifier (should be) Conservative JVML programs Safe programs Verifiable programs Slide: Nate Paul’s ACSAC talk

Complexity Increases Risk JVML programs Safe programs Verifiable programs Bug Slide: Nate Paul’s ACSAC talk

Security Manager u Java library functions call security manager uSecurity 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

The Security Manager uImplements 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 uIs effective to the extent that system resources are accessible only via trusted system classes trusted system classes cannot be overwritten uRelies on class loader To make sure trusted system classes are not overridden.

Redefining the Security Manager uJVM allows only one active SM at a time Default SM provided by the JDK uJava 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

Confused Deputy uKeyKOS 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 (…) uEarly 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

Stack Inspection u 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

Vulnerabilities in JavaVM Vulnerabilities Reported Years Since First Release July 1996 July 2005 Slide: David Evans

Where are They? Verification12 API bugs10 Class loading8 Other or unknown2 Missing policy checks3 Configuration4 DoS attacks (crash, consumption)5 several of these were because of jsr complexity Slide: David Evans

Beyond JVM security uJVM 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 (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

E: Electric Communities uElectronic communities Planned network of interacting virtual realities Example: automated garden (in Netherlands?) with watering can uE 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

Java capability example uGive untrusted object read access to a file Pass the name of the file Pass the File object Pass a ReadStream on the File object uProblem Given Java ReadStream, can request the File object of the ReadStream, then access file, directory structure, etc. uE 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

Lots more information in books, online