CVE-2013-0270: Keystone: openstack keystone: denial of service via large http request with long tenant name
A flaw was found in OpenStack Keystone. A remote attacker could exploit this vulnerability by sending a large HTTP request, specifically by providing a long tenant name when requesting a token. This could lead to a denial of service, consuming excessive CPU and memory resources on the affected system.
Other sources
Dan Prince (dprince) reports:
When long tenantname is sent few times when requesting token, responsiveness of service decreases until finally it requests ends with MemoryError.
keystoneclient.exceptions.AuthorizationFailure: Authorization Failed: Unable to communicate with identity service: Traceback ... MemoryError Includes whole traceback.
Memory on keystone host is used up keystone-all process. Also during processing of the request CPU utilization raises for a long time (when and after the first MemoryError state was reached) - like for more than 10 seconds keystone-all can take whole cpu.
Version-Release number of selected component (if applicable): Name : openstack-keystone Arch : noarch Version : 2012.2.1 Release : 3.el6ost
How reproducible: Use something similiar to following python example few times (5 times with "len(tenant) == 195000000" for keystone host inside VM with 4GB of RAM)
Actual results: For first few tries service correctly responds with: (HTTP 400): Authorization Failed: Request attribute tenantName must be less than or equal to 64. The server could not comply with the request because the attribute size is invalid (too large). The client is assumed to be in error.
Later with: (HTTP 500): Authorization Failed: Unable to communicate with identity service: Traceback (most recent call last): ... whole backtrace here MemoryError
Most memory of keystone host is used by keystone-all process.
Expected results: The first 400 error mentioning that attribute is too big for all request (not only first few). And not such a big impact on memory of host.
Additional info: Similiar to bug #906178 and so also to related upstream bug https://bugs.launchpad.net/keystone/+bug/1098307 where they mentioned preparation of general check/defense for too big requests.
— Red Hat
OpenStack Keystone Grizzly before 2013.1, Folsom, and possibly earlier allows remote attackers to cause a denial of service (CPU and memory consumption) via a large HTTP request, as demonstrated by a long tenantname when requesting a token.
— GitHub
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/keystoneto a version that resolves this vulnerability.Fixed in 8.0.0a0 - Upgrade
Upgrade
openstack keystoneto a version that resolves this vulnerability.Fixed in Grizzly before 2013.1, Folsom, and possibly earlier - Compensating control
Apply input/request size checks before sending token requests so the long tenant_name/tenant attribute (e.g., tenant_name length too large) cannot be submitted; this mitigates the denial of service caused by large HTTP requests with long tenant names in OpenStack Keystone (bug reference: keystone/+bug/1098307 / bug #906178).
Event History
Frequently Asked Questions
What is the severity of CVE-2013-0270?
CVE-2013-0270 is considered to have a moderate severity due to its potential impact on service responsiveness.
How do I fix CVE-2013-0270?
To mitigate CVE-2013-0270, upgrade to keystone version 8.0.0a0 or later via pip.
Which versions of OpenStack Keystone are affected by CVE-2013-0270?
CVE-2013-0270 affects OpenStack Keystone versions prior to 2012.1.3 and between 2012.2.0 and 2012.2.4, as well as versions 2013.1-milestone1, 2013.1-milestone2, and 2013.1-milestone3.
What type of attack does CVE-2013-0270 represent?
CVE-2013-0270 represents a denial-of-service attack that can lead to service unresponsiveness due to memory exhaustion.
Who reported the vulnerability CVE-2013-0270?
The vulnerability CVE-2013-0270 was reported by Dan Prince.