How should OpenJDK handle security?

I recently posted a problem report to an OpenJDK mailing list. I wasn’t even sure if it was a real problem, so I thought I’d bring it up for discussion. A Sun developer then replied in private and told me that this is actually a security issue, that a (non-public) bug entry has been filed in Sun bug DB and that it will be fixed soon.

I understand that Sun has special requirements for handling security issues. But this doesn’t feel right. I post a problem in public (so the info for evil hackers is out anyway), then things happen in secret labs, and at some point a fix pops up in the repos.

It could be argued that it was my fault because I bring up security issues in public in the first place, instead of first discussing them in private. But then, where is the private channel for reporting OpenJDK security issues? And more importantly, how should an innocent hacker like me (*ahem*) know that something is infact a security issue? Of course, I had a feeling that it could be one, this is why I wanted it evaluated, but then everything must be reported private-first, because many bugs can turn out to be a security issue. In closed source days, this might have made sense, because initial bugreports didn’t become public until somebody evaluated them. But for an open project like OpenJDK it doesn’t make so much sense.

So how should OpenJDK handle security issues? Some people are in the mood of refactoring OpenJDK processes, so I thought it would make sense to bring it up now.

Advertisements

3 Responses to How should OpenJDK handle security?

  1. Lillian says:

    This is a really interesting post, considering all the patches that went out this week.

    I think it is hard to say that all security issues should be made public first. What happens if the information gets in the hands of a evil hacker that wasn’t aware initially? It is hard to say that *all* the hackers would already have this information.

    But on the other hand, I do agree with you. If these security issues are known, the general public should be made aware of it as soon as possible.

    I guess the cost of each situation needs to be weighed out. I think once a patch is created to resolve the problem, it should be made public immediately and not go through a process of waiting around for significant approval.

  2. David Herron says:

    I believe the policy is common among software platforms. It’s a commonly held belief that revealing a software security bug notifies the evil baddies and they can exploit the hole. Hence keeping the hole secret until you have fielded a fix both notifies the public of the problem, and provides the fix at the same time, hopefully preventing the hole from being exploitable. Well that assumes the users in the field quickly update their software, right? It’s not just Sun that follows this kind of policy, I can think of dozens of other organizations that do so. Security tracking organizations like CERT generally publish obfuscated notifications of security bugs, only after the bug fix has been released, and presumably the obfuscated bug description makes it even harder for the evil baddies to figure out the problem?

  3. If in doubt, the private channel is me – regardless of the issue. 😉

    As far as handling of security issues goes, there is a lot of existing practice in open source projects, and OpenJDK pretty much follows the same rules like everyone else, afaik – to coordinate in private on fixes and responsible disclosure, as a bug rarely affects just one line of code in a single project, but has potential implications for vendors/projects/distributions distributing the code, too, etc.

    See for example the track record of the lcms vulnerability (which only affects OpenJDK), in the oCERT page for it: http://www.ocert.org/advisories/ocert-2009-003.html – the vulnerability was reported to oCERT, who took action to coordinate the response between the lcms maintainer, and affected vendors like Debian.

    More information on the subject than fits in this comment box is available through http://oss-security.openwall.org/wiki/ .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: