Graham Hamilton's Blog

Help Crack The Java Verifier

Sun is asking the developer community to help attack the new bytecode verifier in Mustang. Here's some background on how and why the community can help here.

In developing Java SE 6 ("Mustang") we have adopted a more open, community-based, development model. As part of that we are releasing complete binaries and sources for all our weekly Mustang builds at mustang.dev.java.net and we are also recruiting community contributions into the release.

In previous JDK releases we had waited until the releases were functionally complete and stable before we released our first binaries as official betas. And we waited even longer (often until final release) before making available full source for the releases. After all, why bother to release incomplete builds or non-final sources? We all want to be seen and judged on our best work, not on our rough drafts, right?

Well, we were partly right and partly wrong. There are many customers who are only interested in seeing the final, stable end product. They want to download something that will work well for them and they don't want to see the intermediate development steps. That approach is perfectly valid and makes a lot of sense for many busy customers. And we don't want to delay or distract those customers.

However, it is also clear that there are many developers who would like to act as collaborators in helping to make Java SE better, both by reviewing the work in progress and by actively contributing code and insight into the release. For that community, exposing rough drafts makes perfect sense. These are our coauthors who are helping us create the final work. That is why we created the mustang.dev.java.net collaboration site so we could expose interim builds, get feedback, and incorporate changes from the community.

We've already been receiving a lot of feedback on Mustang based on the various weekly builds. That has been much appreciated and has been helping us to tune and adjust the release as we go along. Thank you.

But now we have come to a particularly scary moment and a particularly important opportunity for the community to contribute to Mustang development. As part of Mustang we will be delivering a whole new classfile verifier implementation based on an entirely new verification approach. The classfile verifier is the very heart of the whole Java sandbox model, so replacing both the implementation and the basic verification model is a Really Big Deal. See Gilad Bracha's blog for an overview of the new verifier plus links to the spec. The new verifier is faster and smaller than the classic verifier, but at the same time it doesn't have the ten years of reassuring shakedown history that we have with the classic verifier.

The new verifier led us to an interesting test of our new development philosophy. Should we delay exposing the new verifier for as long as possible? Or should we push it out, advertise it, and ask for the community's help in reviewing it? Well, I will confess that many of us had an initial fit of the heebie-jeebies about publishing the source code for the new verifier. "But what if someone finds an ugly security hole?" Gasp!

But that question does kind of answer itself, doesn't it? If someone spots a problem we can fix it and we can fix it before we finalize the release. Happiness!

We think the new verifier model is sound and we are taking various steps to review the actual implementation code. But the more eyes that can look at this before it goes into production use, the better.

As a result, Sun has launched the Crack the Verifier initiative. Read the article for more details, but broadly Sun is looking for security experts and astute hackers in the Java community who can help review the new verifier and help discover any potential holes in time for them to be fixed in Mustang.

I hope people will rise to this challenge. This is definitely a case where broad community involvement can trounce what any one individual company can hope to do on its own. I hope this will be an opportunity to demonstrate that community-based development can really help improve a core area of a key Java technology.

Now, I'll also be extremely happy if what happens is that a lot of people look at the new verifier and no one finds any holes. That will be a good outcome! But if there are any holes, let's find them now...

Comments

This work is licensed under a Creative Commons License.