Article 1411 of comp.lang.java.security:
> Date: 15 Nov 1996 15:24:20 -0500
> From: David Martin <dm@cs.bu.edu>
> Subject: Good Java security doesn't imply good network security

> Many researchers have noted security flaws in existing Java implementations
> as well as fundamental weaknesses in Java's security model.  [...]

> Until now users and system designers have been content to consider these
> problems transient, confident that bugs will be mended quickly enough to
> limit any damage.  Netscape, for instance, has been admirably quick in
> responding to the most serious problems.

> However, the giant installed base of Java-enabled browsers---each inviting
> an adversary to determine the browser's actions---gives reason to suspect
> some kind of fallout even in "secure" implementations of Java.  Our paper,
> available at http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z,
> describes attacks on firewalls that can be launched from legal Java applets.

This is a very well-reasoned document, and I strongly recommend reading it.

> [...] Our paper also describes methods for preventing applets from crossing a
> firewall; this is one way to prevent such attacks.

Unfortunately, this section of the paper makes several assumptions that are
not true in practice [quotes from the paper are prefixed with #]:

# ... any document delivery mechanism can be used to obtain a class file;
# however, most untainted news and mail servers would not be capable of
# delivering the data in the correct format: every file they deliver begins
# with ASCII header lines, and these would be rejected by the 
AppletClassLoader.

Netscape allows parameters to mailbox: and news: URLs, one of which is
the "?part=" parameter, which specifies the contents of a particular 
attachment. Base64 and other encoding schemes can be used to send 
arbitrary files in an attachment, not just text files.

# This strategy uses a proxy that scans enabling documents for <applet> tags
# and rewrites such tags in a benign form, so that the web browser receiving
# the enabling document does not actually receive <applet>, and therefore never
# even attempts to fetch the attacker's applet.

JavaScript/JScript and VBScript can be used to generate and show documents
dynamically. This approach wouldn't be effective unless <script> tags were
also removed.

In addition, at least the following transformations may be performed on
documents before the applet tag is read:

- translation based on the transfer-encoding (base64, etc.)
- SGML entity expansion, both in HTML text and URLs
- conversion of non-ISO-Latin-1 character sets
- automatic decompression of x-gzip encoding, etc.
- removal of percent-escaping in URLs

MIME and HTML parsing is a complicated process, and as pointed out in 
the paper, various browsers handle it differently (and often 
incorrectly). In practice, all an attacker has to do is to use enough 
levels and types of encoding to confuse the filter; if any one of 
them is not recognized, the result will be that the applet gets through.

Here's an example (assuming I've remembered the correct syntax):

<meta http-equiv="refresh" value="0; javascript:'<%41PPLET 
CODE=foo.class HEIGHT=1 WIDTH=1></%41PPLET>'">

Since "<APPLET" appears in an URL, the A can be encoded as %41. A filter
could not detect this without parsing the HTML. In general, it would also have
to understand MIME encoding, zip files, CAB files, undocumented 
protocols like "verbatim:", and so on.

# None of the techniques discussed in this paper can prevent applets readily
# available through the client's filesystem.

This is their biggest weakness. It is fairly easy to automatically 
load files into the user's temp and cache directories (and possibly 
other directories, depending on the details of the client's network). 
I can't give details of the temp directory method for non-disclosure 
reasons, but the cache method was discussed
on the Java newsgroups and on RISKS some time ago.

The only way to reliably filter applets (or client-side scripts) is to change
the security policy *at the browser*. The simplest change would be to 
require that
all applet classfiles are served by a trusted proxy; the proxy can then make
whatever access decisions are necessary. Applets from file: URLs would have to
be either banned entirely, or restricted to carefully chosen 
directories - otherwise, there is no guarantee that they were not put 
there by an attacker.

This simplifies the problem to one of ensuring that all the client browsers
are configured properly (preferably from a central point). This is a worthwhile
thing to do even independently of Java.

> In any case we strongly
> recommend that managers of firewalled sites containing Java-enabled browsers
> take a good look at the issues involved and make appropriate policy
> decisions.

Absolutely - but note that there is currently no reliable way to selectively
filter Java applets; the only alternatives are to allow all applets, or to
disable them completely.

Even the latter option gives no absolute guarantee of security. For example,
the bug found by Ed Felton's team in the initial release version of 
Internet Explorer 3.0 (not related directly to Java) worked 
regardless of the browser's security settings.

David Hopwood
david.hopwood@lmh.ox.ac.uk, hopwood@zetnet.co.uk