From: dp@world.std.com (Jeff DelPapa)
Date: Sat, 27 Apr 1996 17:19:11 +0800
To: cypherpunks@toad.com
Subject: re: Joy of Java
Message-ID: <199604270335.AA06305@world.std.com>
MIME-Version: 1.0
Content-Type: text/plain


Scott Brickner  <sjb@universe.digex.net> wrote:
>
>And later:
>
>    The Java bytecode is where the security properties must ultimately
>    be verified . . . .  Unfortunately, it is rather difficult to verify
>    the bytecode. . . .  The present type verifier cannot be proven
>    correct, because there is not a formal description of the type
>    system.  Object-oriented type systems are a current research topic;
>    it seems unwise for the system's security to rely on such a
>    mechanism without a strong theoretical foundation.  It is not
>    certain that an informally specified system as large and complicated
>    as Java bytecode is consistent.
>
>And in the conclusions:
>
>    We conclude that the Java system in its current form cannot easily
>    be made secure.  Significant redesign of the language, the bytecode
>    format, and the runtime system appear to be necessary steps toward
>    building a higher-assurance system. . . . Execution of remotely-
>    loaded code is a relatively new phenomenon, and more work is
>    required to make it safe.
>
>I do think that the ideas embodied in Java are very important, and will
>significantly shape the future of computing, but Java itself may be just
>a stepping stone on the way.

Given the crowd here, this is likely stating the obvious, but it has
never failed to provoke spluttering from the Sun employees I have
tried it on.

The thing not mentioned in this excerpt is that at best, the
verification will have been done for the Sun implementation of the
byte code engine.  There have been announcements of competing
implementations of the the engine, and any assumptions of safety are
out the window in that case.

Sun doesn't have any control over Java the byte code engine, anyone
who wants can build one.  (and at 40kb total size, it is a tractable
thing for an undergrad that didn't manage to find a summer job).  Sun
does control Java the logo, and can deny a license to use it.  That is
likely to become a meaningless distinction -- If somone will install a
disk recieved unsolicited in the mail, or handed to them at a trade
show (how hard can it be to re-seal AOL packaging, such that a casual
recipient won't notice), they aren't bright enough to insist on
genuine Sun brand Java.

If it becomes an expected thing, that all browsers/os's/toaster-ovens
have a java byte code engine in them, there will be a sizable number
sold without "benifit" of trademark (at the low end if nothing else,
Sun does expect to be paid to use the steaming cup).  Not all of them
will have sufficient rigor applied to their development.

Once common, then things get interesting.  The press will (for lack of
anything else to do, as all the engines are supposed to act
identically) start to benchmark the competing implementations.  At
that point, under pressure to "get good numbers", some of the more
"expensive" operations will be "tuned".  Other restrictions might be
sacrificed in order to have something ready for Comdex...

Can't happen you say?  I still remember when some of the PC video
makers got caught special casing the strings in one of the big
magazines benchmarks.

Unfortunately, Sun has designed a fine example of a "Square Peg".  As
OAK, it was a moderately good fit for the intended use.  With zillions
of set top boxes, and a limited number of sources of product
(national/regional controlled entry broadcaster model), you had to
have remote execution, nobody could build a big enough set of servers.
Since it was coming from a broadcaster, you could get away with
trusting signed code -- not just any bozo can get video broadcast
nationally (unless it is violent, and even then they time base correct
it), the same would be true of set top code.

Since it meant selling hardware (engine in rom), there would be a
limited number of sources of system code -- the above mentioned
undergrad would find it difficult to find enough capital to get a mass
market hardware product to market.  And when you get down to it, with
only a few meg of ram, and no disk, there really wasn't a huge amount
of data to compromise.

Now lets examine what they are trying to do with it.  It is a software
only item currently, thus it has very low entry barriers.  Code can be
put up by any bozo with $10/month to pay a local web provider -- even
if the code is signed, you may not be able to get at the author of an
applet, either because of national boundries, or anonymity. And you
get to run the stuff on a machine with a lot of state (all the dells
and gateways sold today had at least a gig of state spinning there to
browse), and a live net connection (back to the source if nothing
else) to transmit interesting things back with.

Looks like a bad fit to me.  But the PR department does have a big
hammer, and they are beating on it, and the hole is starting to give a
bit -- they have it forced about halfway now...

To get a round peg, they have to build a system at the A2 trust level.
That means a verified design, and an implementation checked against
that design.  Sun hasn't done the design side of the game, if the
comments made about the design by the Princeton group are accurate.

Lacking a verifiable design, even Sun's implementation must be
doubted.  But it doesn't end there, the browser that surrounds the
byte code engine can compromise even a good implementation (as
netscape has demonstrated), and last, Sun has no way to ensure that
everything that executes the byte codes is a "good" implementation.
We don't even have to assume malicious intent on the engine builder,
accidents have already supplied us with enough examples of how it can
go wrong. (tho it is easier if you put the hole there -- you don't
have to be skilled enough to find a hole to exploit, just good enough
to add a hole to an existing implementation)

<dp>