[7328] in bugtraq
Re: New Java Security Flaw Found
daemon@ATHENA.MIT.EDU (Mikolaj J. Habryn)
Tue Jul 21 14:03:26 1998
Date: Tue, 21 Jul 1998 14:07:33 +0800
Reply-To: "Mikolaj J. Habryn" <dichro-7f3e596@ERIS.RCPT.TO>
From: "Mikolaj J. Habryn" <dichro-7f3e596@ERIS.RCPT.TO>
X-To: Sean Garagan <garagan@BORG.CS.DAL.CA>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Sean Garagan's message of "Mon, 20 Jul 1998 22:25:58 -0300"
>>>>> "SG" == Sean Garagan <garagan@BORG.CS.DAL.CA> writes:
SG> I was actually quite surprised to see this when I wrote a
SG> ClassLoader a while ago. I had wrongly assumed Sun would hard
SG> code checks for the core Java classes. It looks like Sun
SG> relies on proper security implementations to prevent the
SG> ClassLoader from being replaced.
Forcing java.lang.* to go through the system ClassLoader would be
somewhat unfortunate in somce cases. There are circumstances
(specifically in environments where you are handling potentially
hostile foreign code) where you will want to either totally refuse
access to some classes (java.lang.reflect leaps to mind), or redefine
them (make methods final, or potentially remove some methods
altogether). Yes - you're violating bits of the specification, but
sometimes information leaks are things you really don't want.
To reiterate, not protecting java.lang.* is *not*, IMHO, a
bug. ClassLoaders are dangerous things, and you want to be very
careful about who gets to play with them. And ClassLoader isn't the
only class worth having a good, long look at. If you're trying to
maintain the integrity of separate protection domains, all running
foreign code but interacting in a single VM, then java.lang.Object is
where you start worrying.
m.
