Summary
OpenStack keystonemiddleware before 13.0.2 may improperly trust a custom X-Service-Token header during request authorization. An attacker who possesses an access-restricted application credential could bypass intended restrictions and gain elevated privileges.
OpenStack keystonemiddleware before 13.0.2 may improperly trust a custom X-Service-Token header during request authorization. An attacker who possesses an access-restricted application credential could bypass intended restrictions and gain elevated privileges.
Affected context
The vulnerability occurs in OpenStack deployments using affected keystonemiddleware versions to process service-token authentication and authorization headers. Risk is higher when application credentials are intentionally constrained and the middleware accepts caller-controlled service-token information without sufficiently binding it to a trusted service identity.
The vulnerability occurs in OpenStack deployments using affected keystonemiddleware versions to process service-token authentication and authorization headers. Risk is higher when application credentials are intentionally constrained and the middleware accepts caller-controlled service-token information without sufficiently binding it to a trusted service identity.
Exploit preconditions
- Attack surface: HTTP requests processed by OpenStack keystonemiddleware
- Required access: An access-restricted application credential
- Trigger point: Supplying a custom
X-Service-Tokenrequest header - Why exploitation is possible: Authorization decisions may treat the supplied service-token context as trusted, allowing restrictions associated with the application credential to be bypassed
- Attack surface: HTTP requests processed by OpenStack keystonemiddleware
- Required access: An access-restricted application credential
- Trigger point: Supplying a custom
X-Service-Tokenrequest header - Why exploitation is possible: Authorization decisions may treat the supplied service-token context as trusted, allowing restrictions associated with the application credential to be bypassed
Why this happens
The underlying issue is an authorization design flaw in which caller-controlled service-token data can influence privilege decisions without adequate verification of its provenance or relationship to a trusted service.
This maps to CWE-863: Incorrect Authorization, because the middleware may permit an authenticated principal to perform actions outside the permissions intended for that credential.
The underlying issue is an authorization design flaw in which caller-controlled service-token data can influence privilege decisions without adequate verification of its provenance or relationship to a trusted service.
This maps to CWE-863: Incorrect Authorization, because the middleware may permit an authenticated principal to perform actions outside the permissions intended for that credential.
Potential impact
- An attacker may bypass application-credential restrictions
- Unauthorized API operations could be performed
- Account, project, or service resources could be accessed or modified
- Privilege escalation could enable broader compromise of an OpenStack environment
- An attacker may bypass application-credential restrictions
- Unauthorized API operations could be performed
- Account, project, or service resources could be accessed or modified
- Privilege escalation could enable broader compromise of an OpenStack environment
General mitigation guidance
Mitigation should focus on ensuring that authorization decisions rely only on authenticated, server-established security context.
Common defensive patterns include:
- Rejecting or disregarding caller-controlled service-token claims unless they are independently authenticated and validated
- Binding service-token identity and scope to trusted service-to-service authentication
- Enforcing application-credential restrictions after all authentication context is established
- Applying least privilege to service identities, application credentials, and API roles
- Centralizing authorization policy evaluation and using secure-by-default denial behavior
- Auditing existing policies for header-based privilege escalation paths
Mitigation should focus on ensuring that authorization decisions rely only on authenticated, server-established security context.
Common defensive patterns include:
- Rejecting or disregarding caller-controlled service-token claims unless they are independently authenticated and validated
- Binding service-token identity and scope to trusted service-to-service authentication
- Enforcing application-credential restrictions after all authentication context is established
- Applying least privilege to service identities, application credentials, and API roles
- Centralizing authorization policy evaluation and using secure-by-default denial behavior
- Auditing existing policies for header-based privilege escalation paths
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis and code review of request-header handling and authorization middleware
- Review signals showing caller-controlled headers influencing identity, role, scope, or policy decisions
- Negative authorization tests that use restricted credentials with conflicting or forged service-token context
- API gateway and middleware policies that restrict or normalize sensitive authentication headers
- Audit-log analysis for restricted credentials performing operations outside their expected scope
Automated security testing and policy-as-code checks can help identify inconsistent authorization behavior before deployment.
Organizations can look for this weakness through:
- Static analysis and code review of request-header handling and authorization middleware
- Review signals showing caller-controlled headers influencing identity, role, scope, or policy decisions
- Negative authorization tests that use restricted credentials with conflicting or forged service-token context
- API gateway and middleware policies that restrict or normalize sensitive authentication headers
- Audit-log analysis for restricted credentials performing operations outside their expected scope
Automated security testing and policy-as-code checks can help identify inconsistent authorization behavior before deployment.
Sources
| Source | Link |
|---|---|
| bugs. | bugs.launchpad.net/ |
| github. | github.com/ |
| openwall. | openwall.com/ |
| openwall. | openwall.com/ |
