Cloudanix VulnDB

CVE-2014-3476

None

CVSS

—

EPSS

2.3%

Published

Jun 17, 2014

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in the OpenStack login service lets users who already have some access create new login tokens that give them extra permissions they were never supposed to receive.

Exploit Available
Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
Application
Class
Privilege Escalation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Improper handling of chained delegation in Keystone allows an authenticated user holding a trust or OAuth token with impersonation enabled to mint a new token that includes additional roles beyond those originally granted.

Why it matters to the business

Attackers who already possess limited cloud credentials can expand their access inside the identity service, potentially reaching administrative functions, tenant data, or infrastructure controls without further authentication.

How an attack unfolds

An attacker first obtains a valid trust or OAuth token configured for impersonation, then submits a token request that chains delegation; because role filtering is missing, the returned token contains extra roles, immediately elevating the attacker's effective permissions within the OpenStack deployment.

How to fix it

Upgrade OpenStack Keystone to 2013.2.4 or later, 2014.1.2 or later, or Juno-2 or later. After upgrade, review existing trusts and OAuth clients to ensure impersonation is granted only to intended users.

How to confirm the fix worked

Confirm the installed Keystone package version matches or exceeds the fixed releases; attempt to create a chained token with extra roles and verify the request is now rejected or the resulting token contains only the originally permitted roles.

Typical attack path

  1. Acquire or create a trust/OAuth token with impersonation enabled
  2. Issue a token creation request that specifies additional roles via the delegation chain
  3. Receive a new token containing the escalated roles
  4. Use the escalated token to perform privileged API operations

How to detect it

Search Keystone logs for token creation events that include role lists larger than those present in the originating trust or OAuth token; correlate with user or project identifiers that do not normally hold administrative roles.

What your security team should do

  • Apply the version-specific Keystone patches immediately given the public exploit availability
  • Audit all existing trusts and OAuth tokens for unnecessary impersonation privileges
  • Enable detailed Keystone token and delegation logging for at least 90 days
  • Add alerting on token requests that reference roles outside the caller's original assignment

The record

OpenStack Identity (Keystone) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-2 does not properly handle chained delegation, which allows remote authenticated users to gain privileges by leveraging a (1) trust or (2) OAuth token with impersonation enabled to create a new token with additional roles.

Affected packages

Ecosystem Package Introduced Fixed
PyPI keystone 0 8.0.0a0
Debian:11 keystone 0 2014.1.1-2
Debian:12 keystone 0 2014.1.1-2
Debian:13 keystone 0 2014.1.1-2
Red Hat:openstack:3::el6 openstack-keystone 0 0:2013.1.5-3.el6ost
Red Hat:openstack:3::el6 openstack-keystone-doc 0 0:2013.1.5-3.el6ost
Red Hat:openstack:3::el6 python-keystone 0 0:2013.1.5-3.el6ost
Red Hat:openstack:4::el6 openstack-keystone 0 0:2013.2.3-7.el6ost
Red Hat:openstack:4::el6 openstack-keystone-doc 0 0:2013.2.3-7.el6ost
Red Hat:openstack:4::el6 python-keystone 0 0:2013.2.3-7.el6ost
Ubuntu:14.04:LTS keystone 0 1:2014.1.2.1-0ubuntu1
Ubuntu:14.04:LTS keystone 0 1:2014.1.2.1-0ubuntu1.1

Related vulnerabilities