Reporting Potential Vulnerabilities in Apache CloudStack

If you've found an issue that you believe is a security vulnerability in a released version of CloudStack, please report it to security@apache.org with details about the vulnerability, how it might be exploited, and any additional information that might be useful.

Upon notification, the ACS security team will initiate the security response procedure. If the issue is validated, the team will work on the issue and the public announcement of the vulnerability. During this time, the team will communicate with you as they proceed through the response procedure, and ask that the issue not be announced before an agreed-upon date.

The security team asks that you please do not create publicly-viewable JIRA tickets related to the issue. If validated, a JIRA ticket with the security flag set will be created for tracking the issue in a non-public manner.

Security Team

The PMC has decided to create a "Security Team" for CloudStack.  To read more about team membership and activities, please visit CloudStack Security Team

Scope of ACS Vulnerability Responses

The scope of these procedures applies to vulnerabilities found in CloudStack releases 4.0.0-incubating and later. 

CloudStack has an history that pre-dates the Apache Software Foundation.  This includes the 2.0.x, 2.1.x, 2.2.x, and 3.0.x series of CloudStack releases. Vulnerabilities that are present in only these releases will be addressed by Citrix.

Some vulnerabilities may exist in ASF code releases as well as derivative works or binary distributions.  This is discussed in the Distributors section below.

Procedure for Responding to Potential Security Issues

  • Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must entered in the private repository, apache/cloudstack-private and be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
  • Security team will send an acknoweldgement mail to the original reporter. see the acknowledgement mail template.
  • Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack
  • If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid. see the reject mail template.
  • If issue is confirmed as a CloudStack vulnerability:
    • Security team notifies the original reporter (see the accept mail template) and the Apache Security team (make sure security@apache.org is in the CC or recipient list)
    • Security team notifies release managers for target release version and all versions above.
    • Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
    • Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This will be depending on the severity and complexity of the issue.
    • Security team works with Apache Security Team to reserve a CVE Identifier for future public release
    • Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
    • Testing is conducted to verify patch mitigates issue and does not cause regression errors.
    • Once fix is confirmed, notify release manager to ensure the fix is in the appropriate release.
    • Security team creates a vulnerability announcement
    • Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability.
    • A new CloudStack release or hotfix is prepared and tested, containing the new security patch.
      • Typically these are narrowly focused maintenance release and do not require official release announcement from ACS marketing. A blog post will be published  and user and dev list will be notified.
    • Distributor coordination is implemented to enable a coordinated announcement.
    • Security team posts vulnerability announcement to...
      • CloudStack dev list
      • CloudStack users list
      • CloudStack Security alerts web page
      • The Bugtraq mailing list
    • After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.
    • Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
  • After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.

Standard Email responses for certain process steps

The following email templates could be used at certain steps on the process: https://www.apache.org/security/committers.html#possible

Acknowledge

Dear <REPORTER>,

Thank you for your report, this is to acknowledge your security report
as per our security process [1].

Please allow us some time to review it and get back to you. We'll
notify you once we (the Apache CloudStack PMC) accept or reject your
report and discuss further about the CVE ID allocation (if accepted),
as per our security process [1].

In the meanwhile, we request that no information on this report is
disclosed publicly.

[1] https://www.apache.org/security/committers.html#acknowledge

Accept

Dear <REPORTER>,

This is to confirm that the Apache CloudStack PMC have accepted your
report and we're working on a fix for the same [1].

We ask that you treat this private and confidential until this is
announced publicly. The CVE ID: CVE-XXXX-YYYY has been reserved for
it.

[1] https://www.apache.org/security/committers.html#resolve


When a fix is available the following can also be added on the response:

Please find the attached patch for the fix for review. It may include some additional changes if we find an issue during testing.

We will also share the CVE draft once ready.


Reject

Dear <REPORTER>,

After investigating and reviewing your report the Apache CloudStack
project PMC has decided not to accept it with reasons listed below. We
do not plan to allocate a CVE for the report and we request you not to
allocate one either.

Reasons for not accepting the security report:

<REASONS FOR REJECTION>