Article 2560 of comp.lang.java.security:
In a post to comp.lang.java.security and BUGTRAQ, Major Malfunction &
Ben Laurie claimed on 2/25 to have discovered a couple of new
Java-based attacks.  See:

		http://www.alcrypto.co.uk/java/

The first "less serious hole" allows a miscreant "to gain access to
information from the client machine which would normally be considered
'secure'."  This works with the Netscape Navigator.  Though their
attack works as advertised on the page, there is really nothing new to
this discovery.  On their page, they say:

>All we can do is log the real identity of a client machine, despite
>most precautions they might take to prevent us from doing
>so... [firewalls, proxies, SOCKS, anonymizer...]
>we take one call to InetAddress.getLocalHost()...

And there you have it.  Since the applet is running on the client
machine and it is allowed to call InetAddress.getLocalHost(), it can
find out the client machine's IP.  Though this may surprise some users
(especially those using the anonymizer), the ferreting-out of this
information is not really a dangerous new invasion of privacy.  The
Web is currently not a private place.  This demonstration serves to
bring that point home.  Your Browser is probably a blabbermouth.  It
is a clever move to use Java to look up an IP at the client end
through several proxy layers, but not all that clever.

The second attack is more disturbing.  This one works only for the
Microsoft Internet Explorer. They claim "this loophole allows an
attacker to connect to any TCP/IP port on the client's machine."
That's a bit of an overstatement, but interesting information about
listening ports can be gathered (for possible later use). This may
leave a firewalled host more susceptible to standard TCP/IP based
attacks.  That's bad.

The Java Security Manager usually disallows port scanning behavior.
But the crackers use the well-known trick of sticking some Java code
in the browser's cache and later executing it through a file: URL
(using frames in the usual way.)  Since Microsoft's cache layout is
transparent, this attack works.  This is an interesting variation on
the Hopwood slash-and-burn attack described on page 69 of the book I
wrote with Felten "Java Security: Hostile Applets, Holes, and
Antidotes".  The attackers cheat a bit for demonstration purposes by
having the patsy clear their cache to begin with, but even without
this exercise, guessing the cache location (one of four possibilities)
would not be all that much of a challenge.

Contrary to the claim on their page, Java security rules are no longer
relaxed for code loaded out of the cache (unless the cache happens to
be in the CLASSPATH---not recommended).  That problem was fixed.  In
any case, Microsoft apparently places HTML and class files in the same
directory *stored with their original names*. Though MSIE can't browse
cache files directly, HTML pages can reference cache files by explicit
name.  Thus the file: URL, if properly constructed, can invoke the
Java class.  The applet the crackers stuff in your cache is a port
scanner. In this case, the port scanning attack works because an
applet is allowed to open a socket connection back to where it came
from.  Guess where it came from?  The client machine.  So a port scan
is carried out by their cache-bomb applet.

That leaves only the problem of getting the port scan information back
to the cracker site.  They use the URL lookup covert channel to do
this.  (The Princeton team has explained this in a paper.) This is one
of many ways of sending interesting tidbits out from an applet.

In summary, the information released on 2/25 by Major Malfunction &
Ben Laurie provides a couple of examples of some known attacks.  If
that helps educate Web users about the risks of executable content,
that's good.  If it stirs up unnecessary panic, that's bad.

				Gary McGraw

p.s. See http://www.rstcorp.com/java-security.html for information on
the book, Java Security: Hostile Applets, Holes, and Antidotes
*------------------------------------------------------------------*
|  Dr. Gary McGraw      gem@rstcorp.com   |              (__)      |
|-----------------------------------------|              (oo)      |
|  Research Scientist                     |       /-------\/       |
|  Reliable Software Technologies (RST)   |      / |     ||        |
|  Sterling, VA                           |     *  ||----||        |
|  <http://www.rstcorp.com/~gem>          |        ^^    ^^        |
*------------------------------------------------------------------*