This section is intended to provide guidance to Apache committers on how security vulnerabilities should be handled. The Apache Security Team is available to provide help and advice to Apache projects should it be required.
Projects with known, published vulnerabilities should provide information about those vulnerabilities as part of the project web pages e.g. the httpd security pages. The security information should be clearly linked from the project's homepage.
Security vulnerabilities should not be entered in a project's public bug tracker unless the necessary configuration is in place to limit access to the issue to only the reporter and the project team.
Projects may also wish to create a project specific security mailing list. These take the form of firstname.lastname@example.org, e.g. email@example.com
When the infrastructure team creates these lists, they are configured so that all messages are automatically copied to firstname.lastname@example.org. If is not, therefore, necessary to cc email@example.com when sending mail to a project specific security mailing list.
It is expected that a subset of project PMC members and committers will be subscribed to the project specific security mailing list. They are not intended to be used as a third-party notification system and non-committers should not be subscribed to the lists.
A typical process for handling a new security vulnerability is as follows. Projects that wish to use other processes MAY do so, but MUST clearly and publicly document their process and have security@ review it ahead of time.
Note: No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a Jira issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit.
The person discovering the issue, the reporter, reports the vulnerability privately to firstname.lastname@example.org or to email@example.com
Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in Apache software are ignored and no further action is required.
If reported to firstname.lastname@example.org, the security team will forward the report (without acknowledging it) to the project's security list or, of the project does not have a security list, to the project's private (PMC) mailing list.
The project team sends an e-mail to the original reporter to acknowledge the report.
The project team investigates report and either rejects it or accepts it.
If the report is rejected, the project team writes to the reporter to explain why.
If the report is accepted, the project team writes to report to let them know it is accepted and that they are working on a fix.
The project team requests a CVE number from email@example.com by sending an e-mail with the subject "CVE request for..." and providing a short (one line) description of the vulnerability. Guidance is available to determine if a report requires multiple CVEs or if multiple reports should be merged under a single CVE.
The project team agrees the fix on their private list.
The project team provides the reporter with a copy of the fix and a draft vulnerability announcement for comment.
The project team agrees the fix, the announcement and the release schedule with the reporter. For an example of an announcement see Tomcat's announcement of CVE-2008-2370. The level of detail to include in the report is a metter of judgement. Generally, reports should contain enough information to enable people to assess the risk associated with the vulnerability for their system and no more. Steps to reproduce the vulnerability are not normally included.
The project team commits the fix. No reference should be made to the commit being related to a security vulnerability.
The project team creates a release that includes the fix.
The project team announces the release. The release announcement should be sent to the usual mailing lists (typically the project's user list, dev list, announce list and the Apache announce list).
The project team announces the vulnerability. The vulnerability announcement should be sent after, or at the same time as, the release announcement to the following destinations:
a. the same destinations as the release announcement
b. the vulnerability reporter
c. the project's security list (or the firstname.lastname@example.org if the project does not have a dedicated security list)
d. email@example.com (subscription not required)
When posting to mailing lists it is strongly recommended that an appropriate reply-to (e.g. the project's user mailing list) is set. Note that the external addressees have their own posting rules and you may need to use a separate e-mail for each in order to comply with these rules.
e. https://cveform.mitre.org/ and use "Notify CVE about a publication". You should use your @apache.org e-mail address when submitting the form. Fill in the two required fields and put the following formatted details in the field labelled "Additional information and CVE ID description updates". Submissions should be in the following format:
[CVEID]:CVE-2017-5648 [PRODUCT]:Apache Tomcat [VERSION]:Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, 7.0.0 to 7.0.75 [PROBLEMTYPE]:Information Disclosure [REFERENCES]:https://lists.apache.org/thread.html/d0e00f2e147a9e9b13a6829133092f349b2882bf6860397368a52600@%3Cannounce.tomcat.apache.org%3E [DESCRIPTION]:While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41 and 7.0.0 to 7.0.75 did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.
Note that Mitre request that we please include the product and version information in the description itself as well as in the "[VERSION]" line in our submissions. While this may seem redundant, including the information in both places satisfies different use cases and supports automation.
The project's security pages should also be updated.
This is the first point that any information regarding the vulnerability is made public.
The log for the svn commit that applied the fix is updated to include the CVE number. Projects that use git as their primary source code control system should not do this as editing a pushed commit causes all sorts of problems.
If the project does not have a dedicated firstname.lastname@example.org mailing list, all communication regarding the vulnerability should be copied to email@example.com. There is no need to do this for messages sent to firstname.lastname@example.org since these are automatically copied to email@example.com.
Information may be shared with domain experts (eg colleagues at your employer) at the discretion of the project's security team providing that it is made clear that the information is not for public disclosure and that firstname.lastname@example.org or the project's security mailing list must be copied on any communication regarding the vulnerability.
Common Vulnerabilities and Exposures (CVE) IDs are a unique identifiers given to security flaws. The Apache Security Team maintain a pool of CVE names which we can allocate to new issues affecting Apache projects.
If you believe Mitre have the details of an issue described incorrectly, see the CVE FAQ for how to contact them with corrections.