Re: New(?) bytecode verification weakness

Bill Frantz (frantz@communities.com)
Wed, 04 Jun 1997 12:20:25 -0700

Message-Id: <3.0.32.19970604122024.0071dbd0@homer.communities.com>
Date: Wed, 04 Jun 1997 12:20:25 -0700
To: Marianne Mueller <mrm@Eng>
From: Bill Frantz <frantz@communities.com>
Subject: Re: New(?) bytecode verification weakness

At 02:26 PM 6/3/97 -0700, Marianne Mueller wrote:
>(Actually since you're about two blocks away, we should meet for
>coffee at Starbuck's!)

Sounds like fun.

>Anyway, this is a known feature or a known bug, depending on many
>interesting debates that people have about how the Java keyword
>"final" is defined and enforced.
>
>Your example shows that a class is able to assign to its own final
>variable more than once. (at the bytecode level)
>
>...
>
>I don't feel this is a security hole, since if a malicious class can
>launch an attack by assigning to one of its own final fields, what's
>preventing the same class file from declaring the field as non-final
>in the first place?

We are interested in defining this behavior as a bug because it impacts our
ability to define objects which are manifestly constant. A class with
non-final fields would fail such a test, while one with final fields would
pass. While I haven't taken the time to develop an attack based on being
able to change a constant in a distributed system, I certainly don't feel
comfortable about allowing it to happen.

>This does lead to the interesting discussion that the Princeton people
>have raised, about how best to define the distribution layer for Java.

I would certainly be interested in such a discussion.

>
>Marianne
>
>p.s. Here's my version of your test, and also the jasm version of the
>bytecode. We have jasm and jdis, a couple interesting tools. jdis
>takes as input a .class file and produces a .jasm file. jasm takes a
>.jasm file and produces a .class file.

Are these tools available? We had thought we would have to write an
assembler ourselves until we stumbled across the Kimera web page.