From: Hal <hfinney@shell.portal.com>
Date: Thu, 25 Apr 1996 11:44:38 -0700 (PDT)
To: cypherpunks@toad.com
Subject: Java security weaknesses
Message-ID: <199604251842.LAA27897@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


This is a quick summary of the attacks listed in "Java Security: From
HotJava to Netscape and Beyond", by Drew Dean, Edward W. Felten,
and Dan S. Wallach, Department of Computer Science, Princeton
University. <URL: http://www.cs.princeton.edu/sip/pub/secure96.html >.

Only attacks on Netscape will be listed here.  Several more were found
in HotJava, but that product is moribund at present.  The version of
Netscape used is 2.0.


Denial of service attacks

    Busy-wait to consume CPU cycles

    Allocate memory until no more is available

    Lock crucial system classes, e.g. java.net.INetAddress.  Blocks
    all hostname lookups.  Several other classes are suitable for this
    attack.

    Denial of service attacks can be moderated to degradation of service,
    possibly after a time delay, to make someone else's product look bad.


Covert Channels

    Can send mail via an SMTP port on server

    Lookup fictitious DNS name to send out info

    Tell browser to access fictitious URL (can be redirected back)


Information available to applets

    Can benchmark machine by reading system clock

    Java hashcode() defaults to address of object, might leak some info


Implementation errors

    DNS hack allowing connections to any machine (has been patched)

    Java disassembler (javap) has buffer overflows (not normally run by
    users)


Inter-Applet security

    Applets running from previous pages can learn of new applets by
    getting a handle to the top-level ThreadGroup and enumerating every
    thread running in the system.

    Can then call stop() and setPriority() on threads belonging to other
    applets, making them appear slow and unreliable.


Bytecode problem

    The big one: Java bytecode safety checker doesn't detect illegality of

    constructor()
    {
	try { super() } catch (Exception e) {}
    }

    This is not legal in the language - super() must not be called in a
    try clause.  But the bytecode checker erroneously allows it.

    This allows subclasses of privileged system classes to be created.
    Normally those classes throw an exception in their constructor so they
    can't be instantiated.  But this trick allows it.

    This way users can create their own ClassLoaders, SecurityManagers,
    etc.  By creating a hacked ClassLoader the Java class type system can
    be defeated by resolving different classes against each other.  Any
    non static variable can be set, any public method can be called,
    including native methods.  The security is gone.


Package name problem

    If the first character of a package name is / the system will attempt to
    load code from an absolute path, which would be trusted since it comes
    from the local disk.  Any Java class which the attacker can get onto
    the user's disk can then be loaded in trusted mode.  Classes can be
    gotten onto disk simply by fetching URL's in Netscape, which puts them
    into its cache.  If you can figure out Netscape's class naming scheme
    you can then run any class, trusted.  (I think this one has been
    patched.)