Entries tagged [security]

Thursday October 27, 2016

Apache CloudStack registerUserKeys authorization vulnerability

The CloudStack security team recently received notice of a significant vulnerability in a CloudStack API call - registerUserKeys. The original intention for this call was for it to only be exposed for integration work - eg not to the public network in general. A weakness in the API call's implementation allows a malicious user to reset the API keys for other users on the system, thus accessing resources and services available to that user. We have released CloudStack versions and with patches for this issue. More details about the release can be read on the official announcement post.

Some users may be protected from this weakness already, if they have configured their commands.properties file to limit access to this api call from the integration API port, instead of general API port. This can be accomplished by setting registerUserKeys to 1.

Users of Apache CloudStack version 4.9 whom are using the dynamic roles feature can delete the "Allow" rule for "registerUserKeys" for each non-administrator role under the Roles/Rules section of the user interface.

This vulnerability was reported by Marc-Aurèle Brothier from Exoscale.

Friday February 05, 2016

Two late-announced security advisories

Today I sent out two CloudStack-related security advisories: CVE-2015-3251 (related to VM credential exposure) and CVE-2015-3252 (related to VNC authentication). Details about these issues can be found on the CloudStack user and dev mailing lists, as well as on the Full Disclosure and BUGTRAQ security mailing lists.

While these vulnerabilities are of moderate and low severity (respectively), the reason for this post is because the advisories were announced approximately 5 months after the first release of the patches in 4.5.2. This is personally embarrassing, unacceptable, and in a more severe case could be downright dangerous.

What happened?

The CloudStack security team worked through the related vulnerabilities through the summer of 2015. We had advisory drafts, patches, and mitigations all ready well before the release. Far enough ahead, actually, that we forgot about the release and weren't paying attention to the release (at least I wasn't - I know others were), and didn't send out the advisories at the appropriate time. Part of this is due to me having become an unofficial lead/spokesperson for the security team; In the past there has been at least one occasion when others released advisories when I was not available, but usually I'm coordinating issues and publishing announcements.

Luckily, the CloudStack Security Team works with and under the direction of the ASF security team. During one of their periodic reviews, they noticed CloudStack had loose ends on these two advisories, and asked for an update. Earlier today I realized the advisories had not been released, so here we are.

How will we improve?

Obviously, we don't want to be in this situation again. Here's some steps we're taking to minimize the chance of a repeat performance:

  • I've modified the Release Procedure to specifically request the release manager give the security team a heads up that a release is about to be announced. This can be a simple non-blocking email that shouldn't slow down the release process, but still ensure that we're aware of the upcoming release.
  • I'll be ensuring that other members of the security team feel comfortable crafting and releasing advisories. Like the rest of CloudStack and other ASF projects, the CloudStack security team does not have a named leader and should be able to operate if I or others are unavailable.

In the past I've referred to CloudStack as "critical infrastructure" - CloudStack powers infrastructure clouds for many large cloud providers. We take information security seriously, realizing that many depend upon our work. Vulnerabilities happen in most software at some point in time - the important part is how they are responded to. While in this case we did respond quickly to the issues and created and applied patches, we let the community down by not quickly releasing the advisories. This is an unfortunate chink in our armor, but we'll be taking steps to ensure it doesn't happen again.

Friday July 10, 2015

CloudStack and OpenSSL CVE-2015-1793

Updated July 11th, 2015:

After reviewing CloudStack components and seeing Debian's advisory on CVE-2015-1793 (CloudStack's "system VM" is Debian based), it looks like CloudStack is not affected by this vulnerability.

Original post follows...

On the 9th of July, the OpenSSL project announced a high severity vulnerability within the OpenSSL library. While this particular vulnerability does not seem to affect SSL servers, there are security issues with SSL clients powered by OpenSSL. Because of this, we suspect there may be issues with parts of CloudStack which initiate SSL connections.

At this point we are still reviewing which particular versions of OpenSSL are used by different versions of CloudStack. Once this review is complete, we will further update the community and this post as to our next steps.

Wednesday January 28, 2015

CloudStack and the "Ghost" glibc vulnerability

UPDATE: mitigation instructions have been improved (don't update openswan) and we forgot to mention rebooting.
UPDATE: Links to updated System VM templates are now below

Yesterday, a buffer overflow vulnerability was announced in glibc that affects most current Linux distributions. In CloudStack, the system VMs contain a vulnerable version of glibc.

CloudStack community members have built an updated system VM template, which ShapeBlue is hosting at http://packages.shapeblue.com/systemvmtemplate/ (More information on the packages at http://shapeblue.com/packages).

For instructions on how to update the SystemVM template in CloudStack, see here.

For those who wish to patch their running system VMs, ssh into each one and run:

apt-mark hold openswan
apt-get clean
apt-get update && apt-get upgrade
After updating glibc, the system will need to be rebooted.

Information about how to connect to your System VMs is available here.

Other CloudStack-related systems may be affected!

Please review security updates from Linux distributions you use on your management server, storage systems, hypervisors, as well as other Linux VMs and bare-metal systems running in your environments. This post provides instructions for determining if a system is vulnerable, as well as patching directions for common Linux distributions.

Friday June 06, 2014

Realhostip Reprieve for CloudStack Users

As mentioned previously, the realhostip.com dynamic DNS resolver service is being retired this summer. During testing of Apache CloudStack version 4.3, we found a few more issues related to realhostip.com that have been addressed for the 4.4 release.

In order to give everybody a reasonable window to update their CloudStack installations to use the updated code, the retirement date for the realhostip.com service has been pushed back to September 30th, 2014. This provides an additional 3 months from the original June 30th date.

Any questions related to the retirement of the realhostip.com service and it's affect on CloudStack installations should be send to the CloudStack Users or Development mailing lists. Further information about how to subscribe and interact with the mailing lists is available at https://cloudstack.apache.org/mailing-lists.html.

Wednesday April 09, 2014

How to Mitigate OpenSSL HeartBleed Vulnerability in Apache CloudStack

OpenSSL is an important part of Apache CloudStack. In light of the recent "HeartBleed" vulnerability disclosure, we are providing instructions on how to mitigate the vulnerability in your infrastructure.[Read More]

Tuesday March 25, 2014

Realhostip Service is Being Retired

Recently the Apache CloudStack PMC was informed that the realhostip.com Dynamic DNS service that CloudStack currently uses as part of the console proxy will be disbanded this summer. The realhostip service will be shut down June 30th, 2014, meaning users have approximately 3 months to mitigate this.

Prior to version 4.3, CloudStack used the realhostip.com service by default. With the release of CloudStack version 4.3 the default communication method with the console proxy is plaintext HTTP.

Who is Affected

CloudStack installations prior to version 4.3 that have not been reconfigured to use a DNS domain other than realhostip.com for Console Proxy or Secondary Storage must make changes to continue functioning past June 30th, 2014.

Steps You Need to Take

If you meet the criteria above, there are several options to prepare for realhostip retirement:

  • Set up wildcard SSL certificate and DNS entries: This method is already well supported within prior versions of CloudStack.
  • Upgrade to CloudStack 4.3 and disable SSL: This is only recommended for development installations, or private clouds that contain no information of importance.
  • Upgrade to CloudStack 4.3, set up static SSL certificate and configure load balancer to point to the correct IP address: While this allows an administrator to skip setting up the DNS entries from the previous option, it is a more advanced option as CloudStack 4.3 does not support automatic load balancer configuration for the Console Proxy. It is hoped this functionality will be available in future releases.

For instructions on how to set up SSL encryption for use with CloudStack console proxy, please read the console proxy section of the CloudStack administration guide.

Additionally, if you will be using an SSL vendor who requires an intermediate CA chain to be installed for proper SSL validation by web browsers, detailed instructions for configuring the intermediate CA chain in CloudStack can be found here.

The Apache CloudStack security team does not recommend running a production cloud with either the realhostip.com SSL certificate, or with no SSL encryption at all.

Friday January 10, 2014

[CVE-2013-6398] CloudStack Virtual Router stop/start modifies firewall rules allowing additional access

Product: Apache CloudStack
Vendor: Apache Software Foundation
Vulnerability type: Bypass
Vulnerable Versions: Apache CloudStack 4.1.0, 4.1.1, 4.2.0
CVE References: CVE-2013-2136
Risk Level: Low
CVSSv2 Base Scores: 2.8 (AV:N/AC:M/Au:M/C:P/I:N/A:N)


The Apache CloudStack Security Team was notified of a an issue in the Apache CloudStack virtual router that failed to preserve source restrictions in firewall rules after a virtual router had been stopped and restarted.


Upgrading to CloudStack 4.2.1 or higher will mitigate this issue.




This issue was identified by the Cloud team at Schuberg Philis

[CVE-2014-0031] CloudStack ListNetworkACL API discloses ACLs for other users

Product: Apache CloudStack
Vendor: Apache Software Foundation
Vulnerability type: Information Disclosure
Vulnerable Versions: Apache CloudStack 4.2.0
CVE References: CVE-2014-0031
Risk Level: Low
CVSSv2 Base Scores: 3.5 (AV:N/AC:M/Au:S/C:P/I:N/A:N)


The Apache CloudStack Security Team was notified of a an issue in Apache CloudStack which permits an authenticated user to list network ACLs for other users.


Upgrading to CloudStack 4.2.1 or higher will mitigate this issue.




This issue was identified by Marcus Sorensen



Hot Blogs (today's hits)

Tag Cloud