Bugtraq mailing list archives

Re: New Java Security Flaw Found


From: garagan () borg cs dal ca (Sean Garagan)
Date: Tue, 21 Jul 1998 00:30:07 -0400


I thought this when I first read this report, but I then realized that the
report is a bit poorly written.  It describes a bug in Netscape's Java
implementation that allows an attacker take advantage of the ClassLoader
class in java.lang.  The problem with ClassLoader is it when a program
extends ClassLoader, it has no built in protection for the core Java
classes.  The Java team assumes that when you make your own ClassLoader, you
will add checks to see if a class is in java.* and load the local copy using
findSystemClass().  This also means that you can replace the core Java
classes by putting your own in the classpath before the actual ones, so if
your application allows you to specify the classpath, you can do whatever
you want.

I was actually quite surprised to see this when I wrote a ClassLoader a
while ago.  I had wrongly assumed Sun would hard code checks for the core
Java classes.  It looks like Sun relies on proper security implementations
to prevent the ClassLoader from being replaced.

Apologies for quoting the whole message, but I'm afraid that the
following will make even less sense without it:

The problem is somewhat worse than the above description; you don't
need any control over the CLASSPATH to implement the attack.  There
are three bugs in Netscape 4.0x: (1) Applets can create subclasses of
netscape.applet.AppletClassLoader -- Mark LaDue posted this one back
around April, but it didn't directly lead to an attack. (2) The system
classes aren't looked for _first_; therefore, they can be replaced.
(3) We found a new bug in Sun-derived JVM's (including Netscape's)
where replacing a system class leads to a type safety failure.

Combining these three problems allows us to cast ints to Objects and
vice versa.  This is sufficient to defeat all the security mechanisms
in the JVM.

Drew Dean http://www.cs.princeton.edu/~ddean ddean () cs princeton edu
Secure Internet Programming Group, Dept. of Computer Science, Princeton Univ.



Current thread: