Anatomy of an Apache vulnerability report

Working with Savoir Technologies I get the opportunity to travel around the world helping companies, institutions, and other organizations design, implement and deploy large scale software systems. A large aspect of these deployments is introducing Apache projects as the underlying infrastructure. In general these projects are in Apache Servicemix, Karaf, ActiveMQ, CXF, and Camel as well as many other supporting libraries and frameworks. As part of this practice I've also taken to offering less formalized but highly attended lunch and learn opportunities to the sites I've visited. A pair of these talks I've bundled into a presentation I delivered at the BSides St Johns Security Conference 2012. In this post I'd like to share with you the first half of that talk "Anatomy of an Apache vulnerability report" - all of the information in this talk is available at the Apache Software Foundation's Security page (http://www.apache.org/security/), this talk's purpose is to raise awareness of the process for users and project communities alike.

Anatomy of an Apache vulnerability report

The Apache Software Foundation is the home of over 190 as of this post's writing, among them are some of the most widely deployed and relied upon software packages in the world. Chances are that you probably have some Apache software running somewhere with in your organization. This leads to an important question that all organizations must ask - what do we do if we find a security vulnerability within one of these projects? Luckily all Apache projects have a common process that they follow for addressing such situations, producing a report that other users may follow to mitigate or resolve known issues.

There is an established process for reporting security vulnerabilities to an Apache project, of which I'll now break down into it's component parts:

1. The reporter reports the vulnerability privately to security@project.apache.org or to security@apache.org.
2. Messages that do not relate to the reporting or management of an undisclosed security vulnerability in Apache software are ignored and no further action is required.
3. If reported to security@apache.org the security team will forward the report (without acknowledging it) to the project’s security list or to the PMC private list if no security email list exists.
4. The project team sends an email to the original reporter to acknowledge the report.
5. The project team investigates the report and either rejects it or accepts it. 
6.  If the report is rejected, the project team writes the reporter to explain why.
7. If the report is accepted, the project team writes to reporter to let them know it is accepted and that they are working on a fix.
8. The project team requests a Common Vulnerability and Exposures (CVE) number from security@apache.org by sending them an email with the subject “CVE request for...” and providing a short description of the vulnerability.
9. The project team agrees the fix on their private list.
10. The project team provides the reporter with a copy of the fix and a draft vulnerability announcement for comment.
11. The project team agrees the fix, the announcement and the release schedule with the reporter.
12. The project team commits the fix.
13. The project team creates a release that includes the fix.
14. The project team announces the release and the vulnerability: 
• Typically this is sent to the reporter, project user, dev, and announce list. 
• security@apache.org, full-disclosure@lists.grok.org.uk, and bugtrak@securityfocus.com are notified. 
• Project security page is updated. 
• This is the first point that any information is made public.
15. The log for the svn commit that applied the fix is updated to include the CVE number.

Following this process a Common Vulnerability and Exposures report is recorded for the project. So what does a CVE include? Let's take a look at an example (click image on left for sample report - http://httpd.apache.org/security/CVE-2011-3192.txt):

• Project website includes page titled: ${Project Name} Security Advisory
• Header: Title, CVE #, Last change, Date created, Product, Versions affected.
• Change log: Brief updates on verification, resolution.
• Description: Describes the vulnerability, and how it behaves on different versions.
• Type of Attack: DDOS, Permissions escalation, etc.
• Background of vulnerability.
• The Fix: What version does the fix appear in.
• Caveats: Changes in behaviour.
• Mitigation: Approaches to mitigating vulnerability in absence of fix.
• OS and Vendor specific information: Platform specific reports/patches.
• Actions: What users should do, and how to verify if susceptible.
• Planning: future work regarding this CVE.

Each CVE will contain the sections as above, which should allow your organization to safely handle the challenges presented by any known issue.

I hope by reviewing the reporting process, and the contents of a CVE that users, developers, administrators, and operators in all organizations gain more confidence in their use of Apache projects, knowing that the community have planned for the worst case scenario and are prepared with processes and standards for addressing them in a timely manner.