[4107] in bugtraq
Re: "New" Java hole
daemon@ATHENA.MIT.EDU (Ben Laurie)
Fri Feb 28 10:47:13 1997
Date: Fri, 28 Feb 1997 11:54:56 +0000
Reply-To: ben@algroup.co.uk
From: Ben Laurie <ben@GONZO.BEN.ALGROUP.CO.UK>
X-To: gem@rstcorp.com
To: BUGTRAQ@netspace.org
In-Reply-To: <199702272135.QAA05445@rstcorp.com> from "Gary McGraw" at Feb 27,
97 04:35:39 pm
Gary McGraw wrote:
> 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.
Why is that an overstatement? Admittedly we don't actually establish a two-way
connection - but that was not the point - we demonstrate that we _could_ do
it.
>
> 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.
In fact, the final page uses frames to get the page from eight possible
locations, so there is no need to guess. The real problem is that if the cache
is not clear, the files may get renamed. As you correctly state, for demo
purposes we clear the cache. A real attack would not be 100% successful because
of the renaming problem, but any non-zero percentage risk needs fixing.
>
> 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.
We may have expressed ourselves poorly - as you say, the security rules stay
the same - the important point is that the application is loaded from the
client machine. However, MS state that this was not their intention - the
security manager was intended to prevent this behaviour for locally loaded
classes.
>
> 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.
It was not our intention to stir up panic. It was our intention to report and
get fixed a security hole in MSIE, and get ourselves some publicity at the same
time (we don't get paid for doing this, after all). If these attacks were
known already, why is it that MS have issued a patch as a result of our
report?
If this is all so obvious, as you seem to be trying to imply, why has no-one
else done it?
Cheers,
Ben.
--
Ben Laurie Phone: +44 (181) 994 6435 Email: ben@algroup.co.uk
Freelance Consultant and Fax: +44 (181) 994 6472
Technical Director URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd, Apache Group member (http://www.apache.org)
London, England. Apache-SSL author
