From: fc@all.net (Dr. Frederick B. Cohen)
Date: Sat, 21 Oct 95 13:51:08 PDT
To: cypherpunks@toad.com
Subject: Sun speaks out - but not to the cypherpunks
Message-ID: <9510211053.AA22644@all.net>
MIME-Version: 1.0
Content-Type: text


This response came from Sun to Risks:

> Date: Mon, 16 Oct 1995 21:22:40 -0700
> From: Caveh.Jalali@eng.sun.com (Caveh Jalali)
> Subject: Re: Risks in Java
> 
> If we are going to "analyze" java security, let's keep in mind that there is
> an important distinction between the language (java) and the machinery which
> runs the java program.
> 
> Java is a general-purpose programming language along the lines of C/C++.
> So, there is no doubt that its expressive power overwhelms our
> theoretician's abilities to predict java-programs behavior -- this is where
> we start getting into the halting problem, computability and other black
> magic.  Basically, i don't think we can "trust" programs written in any
> *useful* programming language.

Read: We can't trust Java programs.

> The area where we can (must) build trust is the computing base.
> Traditionally, this has been the OS, but in the case of java, it is the java
> interpreter (such as netscape 2.0 and hotjava).  The browser is now the TCB
> (trusted computer base) for all practical purposes...

Read: The Java interpreter is supposed to be a TCB

> And, to address the specific concern about applets spamming the net -- from
> what I've seen, applets are only allowed to connect to the server that
> supplied the applet in the first place (by default).  The worst thing one
> could probably pull off is to spam oneself.

Read: By default only - also note, none of this invalidates attacks 30-49
from the previously posted list.

Who here truly believes that the implementations of Java meet the
requirements of a TCB?

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236