[E-Lang] E FAQ
Mark S. Miller
Thu, 11 Oct 2001 18:50:22 -0700
At 06:07 PM 10/11/2001 Thursday, Marc Stiegler wrote:
>It only works this badly if the applet is sharing the same jvm with another
>applet: the lock is "only" jvm-wide. An IDE written in Java that launched
>programs under development under the same jvm would, of course, get eaten
>Far more interesting from the cracking perspective is, the same technology
>allows you to listen to all keystrokes in all windows in the jvm. Great
>snooping tool! Unless your running as a caplet under eDesk with CapWT and a
>powerbox, in which case, so sorry, at least this one is shut off (or will
>be, once all is done).
>I'd guess the Java answer is, "hey, what you doin', tryin' ta run software
>from mutually suspicious parties on a single jvm anyway?"
Generally, Java has been fairly consistent at achieving the Applet security
goals they set out for themselves, or almost achieving them, and repairing
the shortfall with some iterations of bug fixing. This is especially true
for the major Applet design goal -- safety, or perimeter security. Their
stated security objectives include running mutually suspicious applets on
the same jvm in the same browser, without them being able to harm each other
(beyond denial of service attacks that E is equally susceptible to).
This is achieved by using the SecurityManager to turn off various operations
which are accessible to normal Java applications.
If what you say above is true, within the constrained applet environment,
then it would constitute a grosser breakage of the applet security
constraints than any Java has yet suffered from. While possible, I would be
surprised. Have you examined whether this exploit can in fact be used by an
applet operating under the normal applet constraints?
Our argument with Java is not primarily about whether they achieve their
stated technical security objectives. It is about the choice of objectives.