Comment 17 for bug 1282865

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote : Re: Keystone middleware may confuse contexts

Many thanks for your suggestions guys!

This is the revised draft, I did not include the comprehensive affected services list because it might be overkill here and a bit risky if we miss something...
For example Nova have three differents strategies to cope with eventlet monkey patching:
* In grizzly, some services are not monkey patched at all (like the novncproxy that Thierry mentioned)
* In havanna, all services are monkey patched by default
* In icehouse, if "--remote-debug" switches are used, then "thread" is not monkey patched...

What do you think if we just say that "Only keystone middleware setups using auth_token with memcache are vulnerable" ?

@Dolph: do you know if the fix (comment #8) need to be backported for grizzly and havanna or will it works as-is ?

Draft impact description #2 -

Title: Potential context confusion in Keystone middleware
Reporter: Kieran Spear (University of Melbourne)
Products: python-keystoneclient
Versions: 0.2.0 version up to 0.6.0

Description:
Kieran Spear from the University of Melbourne reported a vulnerability in python-keystoneclient auth_token middleware. By doing repeated authenticated requests, with sufficient load on the target system, an authenticated user can 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 may be avoided if the calling process already uses eventlet to monkey patch "thread". Only keystone middleware setups using auth_token with memcache are vulnerable.