Mark Reinhold
2018/1/31
Create a secure, private forum in which trusted members of the OpenJDK Community can receive reports of vulnerabilities in OpenJDK code bases, review them, collaborate on fixing them, and coordinate the release of such fixes. Ensure that information flows efficiently, in both directions, between this forum and Oracle’s internal security teams. Encourage the forum to be used for other OpenJDK security-related discussions as needed.
At present there is no organized discussion of vulnerabilities in the OpenJDK Community. Each non-Oracle vendor organization that ships binary products based upon OpenJDK code bases (e.g., Red Hat, IBM, SAP, and Canonical) handles security vulnerabilities mostly on its own, with occasional help via private communication with Oracle.
Not only is this inefficient, but what private communication does occur is focused more on distributing fixes than on developing fixes. There are many highly-qualified external contributors who can help to analyze and fix vulnerabilities. Some are employed by the major vendors, while others are independent. Collaboration occurs only rarely, however, and in an inefficient, point-to-point fashion.
Creating a private forum in OpenJDK for the discussion of vulnerabilities would help the entire Java community invest in security in a coordinated fashion. It is common practice for open development communities to have such fora; good examples in existing communities are the Security Team of the Eclipse Foundation and the Security Group of the WebKit Project.
We propose to create a new Group, the Vulnerability Group, via the existing process and the OpenJDK Bylaws. (We can’t call this the Security Group because a group with that name already exists, for developers who work on the security components of the JDK.)
This Group will have special membership and communication requirements, detailed below, which technically violate the OpenJDK Bylaws. The OpenJDK Governing Board will be asked to approve these exceptional requirements.
Membership in the Vulnerability Group will be limited. To become a Member of this Group, an OpenJDK Contributor must:
Have a valid OCA on file;
Agree to the Communication Policy (below) and the Non-Disclosure and License Agreement;
Have an established track record of handling security issues in a professional and trustworthy manner; and
Be a recognized technical expert, or else a developer who holds an OCTLA or JCK license or works for a vendor organization that holds such a license.
Once the Group’s initial membership is established, additional members may be voted in after the above criteria are validated by the Group Lead. Voting a new member into the Vulnerability Group will require a Three-Vote Consensus rather than the weaker Lazy Consensus used for ordinary Groups.
The Group Lead of the Vulnerability Group will initially and always be appointed by Oracle.
Any decisions about the Group’s membership may, as usual, be appealed to the Governing Board.
Decisions within the OpenJDK Vulnerability Group will be made by rough consensus. If consensus cannot be reached on a particular issue then the Group Lead will make the decision. Any decision of the Group Lead may be appealed to the OpenJDK Lead.
The Vulnerability Group will establish three mailing lists, each with a specific purpose:
vuln-report@openjdk.java.net — For reports of vulnerabilities in any OpenJDK code base. Anyone may post to this list. Messages sent to this list must be encrypted, and are automatically forwarded to vuln-dev@openjdk.java.net.
vuln-dev@openjdk.java.net — For review and analysis of incoming vulnerability reports, collaborative development of fixes, and coordination of public announcements. Open only to members of the Vulnerability Group. Messages sent to this list must be encrypted.
vuln-announce@openjdk.java.net — For announcements of the release of vulnerability fixes and related news. Anyone may subscribe, but only members of the Vulnerability Group may post. Publicly archived; not encrypted.
The main web page for the Vulnerability Group will describe these lists, with particular emphasis on the first list including instructions on how to submit encrypted vulnerability reports.
The Vulnerability Group will make use of the JDK bug system (JBS) to store vulnerability reports and track the development of fixes. Only members of the Vulnerability Group will have access to such reports. Additional fields will be defined as needed for, e.g., CVE numbers and CVSS scores.
Members of the Vulnerability Group will be expected to treat information about vulnerabilities as highly confidential until publicly disclosed.
A Group Member who works for a vendor organization that ships products based upon an OpenJDK code base may share vulnerability information internally within that organization on a need-to-know basis, and may communicate such information back to the Group.
It may occasionally be necessary for the Vulnerability Group to contact external security organizations (e.g., CERT), or vice-versa, or to exchange information with the submitter of a vulnerability report, or to exchange information with the maintainers of implementations of the Java SE Platform that are not based upon an OpenJDK code base. In such situations the Group Lead handles the communication unless the Lead proposes, and there is rough consensus in support of, the delegation of a specific communication activity to another Group Member.
Members of the Vulnerability Group speak only for themselves, or as representatives of their respective employers. No Vulnerability Group member, not even the Lead, is authorized to speak on behalf of the Group, of any other OpenJDK Group or Project, or of the OpenJDK Community as a whole. The only exception to this rule is that Vulnerability Group members may post announcements to the vuln-announce list in accordance with the decisions made within the Group.
Violation of this policy, as judged by the Group Lead, is cause for immediate removal from the Group.
There will be a bi-directional flow of information between the OpenJDK Vulnerability Group (hereinafter “OJVG”) and Oracle’s internal security teams. An Oracle engineer who is a member of the Vulnerability Group, though not necessarily the Group Lead, will facilitate this flow as follows:
If a vulnerability is reported to vuln-report@openjdk.java.net:
If it’s relevant to both an OpenJDK code base and to Oracle’s JDK products then the facilitator will communicate it to Oracle’s internal security teams and thereafter act as a two-way Oracle/OJVG proxy for the issue.
If it’s relevant only to Oracle’s JDK products then the facilitator will communicate it to Oracle’s internal security teams and will notify the OJVG that it does not affect any OpenJDK code base.
If a vulnerability is reported via Oracle’s standard public channel (i.e., secalert_us@oracle.com), then:
If it’s relevant to an OpenJDK code base then the facilitator will communicate it to the private vuln-dev list for review and analysis, and thereafter act as a two-way Oracle/OJVG proxy for the issue.
If it’s not relevant to any OpenJDK code base (e.g., a Java Plug-In bug) then no action is taken with respect to the OJVG.
The OpenJDK Web Site Terms of Use will govern the content of incoming vulnerability reports and any subsequent discussion. Reports from submitters who insist on other terms will not be accepted.
Once a vulnerability is reported we envision the members of the OJVG working together as follows:
Review and validate the vulnerability — Check that the report is complete, test the proof-of-concept if one was provided, assign it a CVSS score if it does not already have one, request a CVE identifier if needed, and create a JBS issue. If the report was sent to the OpenJDK vuln-report list then send an acknowledgement to the report’s submitter.
Develop a fix — This can be done collaboratively amongst OJVG members. OJVG members can also share proposed fixes developed privately within their respective organizations, which may be further refined in OJVG discussions.
Schedule a publication date — Once a fix is settled upon, OJVG members will agree on a publication date. The date should allow vendor organizations who are represented in the OJVG adequate time to make updates to affected products available to their customers and end users. The publication date is confidential until the date itself.
Publish the vulnerability and its fix — On the publication date the fix will be integrated into the affected OpenJDK code bases and a high-level description of the vulnerability and its fix will be posted to the OpenJDK vuln-announce list.