Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
python-keystoneclient before 0.2.4, as used in OpenStack Keystone (Folsom), does not properly check expiry for PKI tokens, which allows remote authenticated users to (1) retain use of a token after it has expired, or (2) use a revoked token once it expires.
Recommended action: Upgrade to 0.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
keystone/middleware/authtoken.py in OpenStack Nova Folsom, Grizzly, and Havana uses an insecure temporary directory for storing signing certificates, which allows local users to spoof servers by pre-creating this directory, which is reused by Nova, as demonstrated using /tmp/keystone-signing-nova on Fedora.
Recommended action: Upgrade to 0.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack keystonemiddleware (formerly python-keystoneclient) 0.x before 0.11.0 and 1.x before 1.2.0 disables certification verification when the "insecure" option is set in a paste configuration (paste.ini) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate.
Recommended action: Upgrade to 1.2.0 or 0.11.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The s3token middleware in OpenStack keystonemiddleware before 1.6.0 and python-keystoneclient before 1.4.0 disables certification verification when the "insecure" option is set in a paste configuration (paste.ini) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate, a different vulnerability than CVE-2014-7144.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The user-password-update command in python-keystoneclient before 0.2.4 accepts the new password in the --password argument, which allows local users to obtain sensitive information by listing the process.
Recommended action: Upgrade to 0.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A context confusion vulnerability was identified in Keystone authtoken middleware (shipped in python-keystoneclient) before 0.7.0. By doing repeated requests, with sufficient load on the target system, an authenticated user may in certain situations assume another authenticated user's complete identity and multi-tenant authorizations, potentially resulting in a privilege escalation. Note that it is related to a bad interaction between eventlet and python-memcached that should be avoided if the calling process already monkey-patches "thread" to use eventlet. Only keystone middleware setups using authtoken with memcache are vulnerable.
Recommended action: Upgrade to 0.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPSConnections in OpenStack Keystone 2013, OpenStack Compute 2013.1, and possibly other OpenStack components, fail to validate server-side SSL certificates.
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
python-keystoneclient version 0.2.3 to 0.2.5 has middleware memcache encryption bypass.
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
python-keystoneclient version 0.2.3 to 0.2.5 has middleware memcache signing bypass
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.