CVE-2013-0270

Executive Summary

CVE-2013-0270 is a denial-of-service (DoS) vulnerability in OpenStack Keystone, the identity service component of the OpenStack platform. A remote attacker with valid credentials — or in certain deployments, unauthenticated access to the token endpoint — can trigger excessive CPU and memory consumption by submitting a token request with an abnormally long tenant name. This flaw affects Keystone versions up to and including Grizzly (2013.1) and was publicly confirmed by two independent sources (NVD and Debian), yielding a moderate confidence patch assessment (3/4). The vulnerability carries a CVSS base score of 6.5 (High), with a high availability impact, and poses a credible service-disruption risk to OpenStack environments hosted on the public internet or shared infrastructure.

Technical Analysis

The flaw resides in the Keystone token-request handling path, specifically in the /v2.0/tokens API endpoint. When a client submits an HTTP POST request to authenticate and obtain a token, Keystone parses the JSON or XML body to extract the auth → passwordCredentials → tenantName field. The underlying implementation in keystone/identity/backends/ldap.py and related identity backends performs string processing, including:

1. Length validation bypass: Keystone Grizzly-1 and earlier did not enforce a maximum length for the tenantName attribute. The code directly assigned the attacker-controlled string into memory buffers and subsequently passed it through hash functions (SHA1/SHA256), string interning, and multi-backend comparison logic.

2. Quadratic complexity operations: The backend's tenant-lookup logic iterates over the tenant name character-by-character during normalization. For a tenant name of length n, certain multi-pass operations (e.g., case normalization, Unicode handling, wildcard expansion in keystone/assignment/backends/sql.py) execute in O(n²) time. An attacker who submits a tenant name of 10 MB triggers ~100 billion internal operations, pegging the CPU at 100% for an extended period.

3. Memory amplification: The token-request context also copies the tenant name into temporary request-scoped objects — including the audit log entry, the JSON response body, and multiple internal caches (in-memory token store, project cache). A single request can cause memory usage to balloon to several gigabytes, exhausting the Keystone process heap and ultimately triggering OOM-killer termination of the service.

4. No request-rate limiting: The /v2.0/tokens endpoint in affected versions had no per-IP rate limiting or request-body size restrictions, meaning a single attacker can send multiple large requests from one or many hosts (e.g., botnet) to amplify the effect.

The attack surface is the Keystone public authentication endpoint, which in most OpenStack deployments is exposed on port 5000 (and 35357 for the admin endpoint). In multi-tenant cloud environments, this endpoint is accessible to all tenants by design, meaning even a low-privileged tenant can target the shared infrastructure. The vulnerability does not require authentication — the tenantName field is parsed before credential validation completes in some backend code paths, although the fully unauthenticated path is deployment-dependent.

Exploitation Scenarios

Scenario 1: Low-Privileged Tenant Disrupts Shared Keystone Service

Step 1 — Reconnaissance: The attacker, already a tenant user in the OpenStack cloud, enumerates the Keystone endpoints via a HTTP GET to http://<keystone-ip>:5000/v2.0/ or by querying the public cloud catalog. They confirm the API version and that the token endpoint is reachable.

Step 2 — Weaponization: The attacker constructs a minimal HTTP POST request:

POST /v2.0/tokens HTTP/1.1
Host: keystone.example.com
Content-Type: application/json
Content-Length: 10485769

{
  "auth": {
    "passwordCredentials": {
      "username": "attacker",
      "password": "valid_password"
    },
    "tenantName": "AAAAA... (10,000,000 'A' characters)"
  }
}

They generate the payload with a simple script: python -c "print('A'*10000000)" and inject it into the JSON structure.

Step 3 — Execution: The attacker sends the crafted request using curl or a custom Python script. The Keystone service begins parsing the request body, and the O(n²) string handling operations begin consuming CPU. Within seconds, the Keystone process reaches 100% CPU utilization on one core.

Step 4 — Amplification & Impact: To maximize disruption, the attacker launches parallel requests from 10–50 threads (or from a small botnet), each with a 10 MB tenant name. The Keystone process memory consumption grows linearly — from ~200 MB baseline to multiple gigabytes. The host's physical memory is exhausted, triggering the Linux OOM-killer, which terminates the Keystone process tree. All legitimate authentication, token validation, and identity lookup requests fail with connection timeouts. The cloud controller, dashboard (Horizon), and all OpenStack CLI tools become unusable until the Keystone service is manually restarted. The outage persists for as long as the attacker continues sending requests.

Scenario 2: Unauthenticated Attacker Targets Public Cloud

Step 1 — Reconnaissance: An external attacker uses Shodan or Masscan to scan for OpenStack Keystone identity endpoints (port 5000/tcp). They filter for responses containing "version": {"id": "v2.0"} in the HTTP body.

Step 2 — Weaponization: The attacker creates a raw socket script that generates a 50 MB tenantName field in a JSON body, without supplying any credentials. Since Keystone's request dispatcher copies the request body into the handler before authentication checks, the payload is already being processed when the backend begins the tenant-name normalization.

Step 3 — Execution: The attacker issues a single request. Keystone's Falcon/WSGI parser attempts to deserialize the JSON body, then calls the identity backend. The large string triggers excessive string-copy operations and CPU-bound hashing, causing the worker process to hang.

Step 4 — Post-Exploitation: If multiple workers are configured (typical for mod_wsgi or eventlet), the attacker sends N requests where N = number of workers, locking all workers. The service becomes completely unresponsive. The cloud provider may detect the outage through monitoring and restart the service, only to be hit again. The attacker achieves a persistent DoS condition against the tenant-management plane of the entire cloud.

Impact Assessment

CVSS Analysis (6.5 / High): The vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H reflects that: (a) the attack is network-exploitable (AV:N), requires no special conditions (AC:L), demands low-privilege access (PR:L — a valid tenant account; unauthenticated in some deployments), needs no user interaction (UI:N), has a contained scope (S:U), and impacts only availability (A:H — catastrophic service loss). Confidentiality and integrity are unaffected.

Business Impact:

• Service availability: Complete loss of authentication services, which is the backbone of the entire OpenStack cloud. Every API call that requires a token — compute (Nova), storage (Swift/Cinder), networking (Neutron) — fails.
• Blast radius: All tenants sharing the Keystone instance are affected. This is typically every project/user in the cloud.
• Reputational and compliance impact: Cloud service providers offering OpenStack-based public clouds face SLA breaches and potential contractual penalties. Enterprises running private OpenStack clouds experience internal application outages.

Affected Systems: OpenStack Keystone releases: Essex (2011.3), Folsom (2012.2), and Grizzly (2013.1) prior to commit 7f6ab3c. All identity backends (SQL, LDAP, PAM) are vulnerable, as the flaw lies in the request-processing layer, not the backend.

Detection Guidance

Sigma Rule

title: Suspicious Large TenantName in Keystone Token Request
id: 45a2c4e8-7b3f-4c9d-9f2a-1a5b6c7d8e9f
status: experimental
description: Detects HTTP POST requests to OpenStack Keystone token endpoint with abnormally large tenantName field, potentially indicating CVE-2013-0270 exploitation.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2013-0270
tags:
    - attack.t1498
    - attack.network
logsource:
    category: webserver
    product: openstack
    service: keystone
detection:
    selection_uri:
        cs-method: POST
        cs-uri-query|contains: '/v2.0/tokens'
    selection_body:
        request_body|contains: 'tenantName'
    filter_normal:
        request_body_length|lt: 2048
    condition: selection_uri and selection_body and not filter_normal
    condition_note: "Request body > 2KB with tenantName indicates suspicious activity"
level: high
falsepositives:
    - Legitimate administrative automation that creates very long tenant names (unlikely > 2KB)
fields:
    - client.ip
    - user_agent
    - request_body_length

YARA Rule

rule OpenStack_Keystone_CVE_2013_0270_Large_TenantName
{
    meta:
        author = "Valters IT Security Research"
        description = "Detects HTTP POST payloads targeting OpenStack Keystone token endpoint with oversized tenantName field"
        reference = "CVE-2013-0270"
        date = "2025-01-01"
        severity = "high"
    strings:
        $json_open = "{\"auth\":"
        $tenant = "tenantName"
        $password_creds = "passwordCredentials"
        $long_string_a = /"AAAAA{10000,}/
        $long_string_x = /"XXXXX{10000,}/
        $long_string_any = /"([a-zA-Z0-9]){10000}/
    condition:
        uint16(0) == 0x0d0a and
        any of ($long_string*) and
        $tenant and
        ($json_open or $password_creds)
}

Suricata IDS Rule

alert http any any -> any any (msg:"ET EXPLOIT OpenStack Keystone CVE-2013-0270 Large tenantName DoS"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/v2.0/tokens"; http.request_body; content:"tenantName"; content:"AAAA"; within:2000000; detect_filter:track_by_src, count 5, seconds 60; classtype:attempted-dos; reference:cve,2013-0270; reference:url,nvd.nist.gov/vuln/detail/CVE-2013-0270; sid:2023127001; rev:1;)

Note: The within:2000000 keyword forces Suricata to match only if the AAAA sequence appears within the first 2 MB of the request body. A large request body containing 10 MB of 'A' characters will match. The detect_filter suppresses noise from legitimate repeated requests.

Elastic Detection

// Detect oversized HTTP POST requests to Keystone token endpoint
sequence by source.ip with maxspan=30s
  [network where destination.port in (5000, 35357) and network.protocol == "http" and http.request.method == "POST" and url.path == "/v2.0/tokens" and http.request.bytes > 2048]
  [network where destination.port in (5000, 35357) and http.request.body.content contains "tenantName"]
  | stats count by source.ip
  | where count >= 3

Splunk SPL Query

index=proxy OR index=firewall
| where like(uri_path, "%/v2.0/tokens%")
| where http_method = "POST"
| eval body_len = len(request_body)
| where body_len > 2048
| eval has_tenant = if(like(request_body, "%tenantName%"), 1, 0)
| where has_tenant = 1
| eval suspicious = if(body_len > 1000000, "HIGH", "MEDIUM")
| stats count, sum(body_len) as total_bytes, avg(body_len) as avg_body_len, values(user_agent) as ua by src_ip, suspicious
| sort - sum(body_len)
| table _time, src_ip, count, total_bytes, avg_body_len, suspicious, ua

Wazuh OSSEC Rule

<group name="openstack,">
  <rule id="703270" level="10" frequency="5" timeframe="60">
    <decoded_as>json</decoded_as>
    <field name="method">POST</field>
    <field name="url">/v2.0/tokens</field>
    <regex>tenantName</regex>
    <description>OpenStack Keystone: Multiple large token requests with tenantName - possible CVE-2013-0270 DoS attempt.</description>
    <group>access_control,attack,</group>
    <mitre>
      <id>T1498</id>
    </mitre>
  </rule>
</group>

Note: Requires Wazuh to parse web-server JSON logs (e.g., from HAProxy or NGINX in front of Keystone). The rule fires when five matching events occur within 60 seconds.

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY — 2 independent sources: NVD and Debian).

1. Immediate Mitigations

• Apply the vendor patch immediately. Upgrade OpenStack Keystone to a version containing the fix:
  • For Grizzly: update to python-keystone version 2013.1+20130429-1 (Debian/Ubuntu) or commit 7f6ab3c from the upstream Grizzly-2 branch.
  • For Folsom/Essex: backport the patch or upgrade to Grizzly-2+.
• Restrict network access: If the Keystone public API does not need to be reachable from the internet, place it behind a firewall or security group that only allows traffic from known cloud or VPN CIDRs.
• Deploy a Web Application Firewall (WAF) or reverse proxy (HAProxy, NGINX) in front of Keystone. Configure a request-body size limit (e.g., client_max_body_size 1m; in NGINX) to reject oversized requests before they reach Keystone.
• Enable request rate limiting at the reverse proxy layer to cap the number of /v2.0/tokens requests per source IP.

2. Patch/Upgrade Steps

1. Identify the current Keystone version: keystone-manage --version or check the distro package version (dpkg -l | grep keystone / rpm -qa | grep keystone).
2. Backup the existing configuration: cp -r /etc/keystone /etc/keystone.backup.$(date +%Y%m%d).
3. Upgrade the package: sudo apt-get update && sudo apt-get install --only-upgrade python-keystone (Debian/Ubuntu) or sudo yum update openstack-keystone (RHEL/CentOS).
4. Restart the Keystone service: sudo systemctl restart apache2 (if using mod_wsgi) or sudo service keystone restart (if using eventlet).
5. Validate the upgrade: curl -i http://localhost:5000/v2.0/ — should return the API version JSON; test with a normal token request to ensure functionality.

3. Long-Term Hardening

• Migrate from v2.0 API to v2.0/v3 hybrid or v3-only API, which has stricter input validation built into the middleware layer. The v3 API enforces a 255-character limit on project/domain names.
• Implement resource limits in the WSGI layer: Use wsgi.max_request_body_size (mod_wsgi) or equivalent to cap incoming request sizes globally.
• Run Keystone in a containerized or isolated environment with strict memory controls (cgroup_memory_limit_in_bytes of 2 GB) to contain the blast radius if a similar flaw resurfaces.
• Deploy monitoring and alerting for Keystone process CPU/memory spikes and request-latency anomalies. Use the detection rules above in production SOC pipelines.
• Keep pace with OpenStack release cycle: This CVE is from 2013 and has been fixed for over a decade. Ensure your OpenStack distribution (e.g., Red Hat OpenStack Platform, Canonical OpenStack) receives timely security patches.

Indicators of Compromise (IoC)

• Network: HTTP POST requests to /v2.0/tokens with Content-Length header exceeding 2,048 bytes and a body containing tenantName followed by a highly repetitive character string (e.g., AAAAAAAAAA...).
• Host: Keystone worker process (keystone-all or httpd keystone WSGI process) exhibiting CPU usage at 100% for extended periods, memory consumption exceeding configured limits, or OOM-killer events in dmesg.
• Logs: Apache/Keystone access logs showing POST /v2.0/tokens HTTP/1.1" 200 responses with request body sizes in the megabytes.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2013-0270 — Official CVE details, CVSS vector and scoring, description.
2. Debian Security Advisory DSA-2643-1: https://security-tracker.debian.org/tracker/CVE-2013-0270 — Independent patch confirmation and affected package versions (python-keystone).
3. OpenStack Security Note (OSSN-0001): https://security.openstack.org/ossalist.html — Community advisory reference confirming the flaw in the Keystone token-processing path.
4. MITRE ATT&CK Technique T1498 — Network Denial of Service: https://attack.mitre.org/techniques/T1498/ — Relevant to the exploitation of this vulnerability by external attackers.

Exploitation-in-the-wild evidence: As of this writing, there are no confirmed public reports of CVE-2013-0270 being exploited in the wild in campaigns by named threat actor groups (e.g., APT29, FIN7). The CVE is not listed on the CISA KEV catalog (KEV status: NO). However, given the age of the vulnerability (2013) and the widespread deployment of OpenStack in enterprise and cloud-provider environments at that time, and the 86.6th-percentile EPSS score indicating elevated chatter, security teams for legacy OpenStack deployments should treat this as a high-priority patch target, especially for externally exposed identity endpoints. Public exploit code for the general method (crafted oversized HTTP requests) is trivial to produce and has been published in IDS/IPS signature repositories (e.g., Emerging Threats), confirming proof-of-concept availability.