[E-Lang] E FAQ

[Mark S. Miller]

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
>alive :-)
>
>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.


        Cheers,
        --MarkM