Re: WSJ on Big Java Flaw

[snip]
> >    Mr. Felten said that unscrupulous people who discovered the
> >    flaw could boobytrap a Web page on the Internet,
> >    essentially seizing control of the browser software of any
> >    PC that tapped into that page. At that point, the hackers
> >    could read or delete an entire hard disk of data files.
> >    "The consequences of this flaw are as bad as they can be,"
> >    he said.[..]
>
> The generalized halting problem comes to mind...
>
> Since it can be proved that there's no complete set of heuristics
> to tell if a given program has a characteristic (such as "secureness")
> then sooner or later someone will discover another security flaw.
>
> A question is whether a simple patch is made or if the set of heuristics
> is widened (ie, learn from mistakes) so that similar flaws can be found
> based on knowledge of that one flaw.

Since this Java error is probably deep in the bytecode interpreter,
the question is will Sun patch this *particular* problem, still allowing
others, or will it have to rewrite the interpreter so that it enforces
the language more rigorously?  They are under pressure to make a
"quick fix" (they've promised something in two days), but real
security needs to be built in to a system from the ground up,
with disciplline and thorough design.  If they need to redesign their
approach to implementing the bytecode interpreter, that could take
weeks, months?

BTW, its a testament to security through code review, as the Princeton
team probably could not have discovered this deep flaw without looking
through the code.

	David Macfarlane.

We are doing several things: 

1) continuing a "scrubbing" of the code, to look for holes so we
can fix them

2) listening (really) to all comments about the applet security model
and mechanisms - some people fault the model, others fault
the mechanisms, and I'm interested in all critical feedback and
find it helpful

3) continuing to be committed to source code releases to continue vetting
by internet community

4) working with others in the networking security community to 
design ways to expand the functionality allowed to applets in a secure way

5) working on mechanisms to support signed classes, so that people
will be able to authenticate downloaded code.  Granted
just because code is authenticated, that doesn't necessarily 
mean it's trusted

As technical info on those things is written down, we'll put it
on our web site for review and criticism - 

Marianne
JavaSoft, Sun Microsystems
mrm@eng.sun.com
mrm@netcom.com