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>