The memcache signing middleware in python-keystoneclient is improperly implemented, such that it does not provide the advertised data integrity features. An attacker with access to the memcache instance used as a cache could insert false or changed data which would be silently accepted by the client.
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/memcache_crypt.py
When the 'MAC' security strategy is enabled, the middleware falls through to silently trusting data which is missing the "MAC_MARKER" prefix. When this mode is enabled, the middleware should require all data to be signed, and raise an error when encountering unsigned or incorrectly signed data.
Furthermore, the construction of the MAC:
h(data || token)
is improper, accepting attacker generated signatures with trivial effort since it involves no data which is not available to an attacker.
Instead, it should use the standard HMAC construction:
HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))
where K is a secret key, m is the message, and opad and ipad are standard constants.
The secret key should be produced using an approved key derivation function which differs from the key used when the 'ENCRYPTION' security strategy is in use. More details on appropriate functions are available in NIST Special Publication 800-108.
As currently written, this feature provides no security benefits whatsoever. I will be proposing a patch later today to fix the issues outlined above. I plan to fix this issue in a forwards-compatible way, with the side effect of invalidating existing ephemeral cache values for users who enabled this feature. This should have a CVE. I'm ok with marking this bug as public given the minimal potential for exploitation (an attacker needs access to the memcache instance, which should never happen in a proper deployment) and the assumed low usage rate of this feature.
Adding Keystone core