Move Over Princeton

This week a team at the University of Washington is making news with a slew of security bugs discovered in the new Sun JVM.

Following a typical journalistic proclivity toward writing about concepts with snappy names or catch phrases, this particular bug was so named as it euphemistically reflects its ability to suck headlined reports.

Word has not yet filtered down as to whether the bugs are largely design or implementation related. Our impression is that the work was largely done by feeding randomly generated malformed data to the interpreter and seeing what bad behavior they could inspire--a venerable and effective technique.

Of course, any problem in the Java-type verifier is a serious one. The Kimera team has found several dozen. All in all, we're pretty impressed. Java remains one of the few newly developed commercial products to appear to be under any kind of serious security review, unlike some other Internet software products we could name.

Rumor has it Sun has quietly shipped some fixes to licensees already, and we anticipate the release of JDK 1.1.3 in the very near future. We presume that the other virtual machine vendors are moving to understand and incorporate discoveries by the Washington group.

The group's work is very interesting and worth a serious look for those trying to educate themselves about Java or security, and perhaps computer science in general. It's hallmarked by the exposure of some organizational weaknesses in commercial JVMs and their code verifiers, and the development of a better written and more secure verifier.

On a larger scale, the group seems to be working on a rather unorthodox re-engineering of Java, one with a more "distributed" feel for a community venue, one in which a central (and secure) server handles all Java verification, just-in-time compilation, and compiled code caching for all the Java clients within its sphere of influence.

It's a unique idea, and one that has the advantage of allowing centralized management of security policies and lightened demands on client desktops. Still, it's not without some obvious drawbacks: Central servers are, of course, central points of failure, and, in general, such a system wouldn't touch the majority of standalone Java applications. This is definitely inspiration from mainframe domesticated academia, but pretty good inspiration nonetheless.

Stolen Source Code, Anyone?

We've been remiss, due to time constraints, about covering a particularly interesting development in the Java world until now, but with our few remaining words this week, we'll give it just a bit of the mention it deserves.

In late 1996, a beta release of a Java decompiler began circulating, written by the late Hanpeter van Vliet. Decompilers are old news in the computer world, and we're always surprised at the number of people who aren't aware of their existence.

It's always possible, of course, to look at the machine code instructions that make up the programs you purchase to see how they work, although for most modern, overstuffed applications such analysis, by hand, would be unthinkably time-consuming and complex. Tools have come and gone with varying success that attempt to recreate parts of the higher level instructions used to create an application from the machine language. Decompilers are programs that fall within this description.

Because of the way most conventional programs are compiled into executable machine code, such efforts are ultimately impossible, as a great deal of information about the original source code of a program is lost in compilation unless deliberately kept. Now enter the great anomaly: Java.

The Java class, for all its compactness, retains a remarkable amount of information from its source code: The names of classes, variables, and methods are all preserved, for instance, although comments, notably, are not.

This situation paved the way for a decompiler to be written that would be startlingly effective compared to conventional decompilers servicing other architectures--and it was. van Vliet called it Mocha.

Minus comments, it really is startlingly effective at turning compiled .class files back into .java files, a fact that struck ice cold fear into the hearts of many corporate developers who were very comfortable hiding what they were doing behind the shield of obscurity created by earlier binary formats.

The controversy added some new life to some old and important ideological debates, not to mention spurring some hastily written, but at least partially effective, systems for defeating the decompilers.

This is all very, very interesting. We'll be back to talk about it in more detail soon. Stay tuned.