Closing this because bearer tokens, etc, are a well known weakness. ** Changed in: keystone Status: Confirmed => Won't Fix
-- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1455582 Title: Hypervisor compromise may result in malicious trust creation Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node. By default, a keystone token can be exchanged for another token. There is no restriction on scoping of the new token. A scoped token can be exchanged for an unscoped token, or a token scoped to a different project. We had set the default time limit for tokens down to 1 hour, to reduce the surface area of the attack. However, many workloads require a single token for the whole workload, and these workloads take more than one hour, so several installations have increased token lifespans back to the old value of 24 hours. A token can be used to change a password. If this is done, all tokens are revoked for the user. With the trust API, a user can set up a long term delegation that allows another user to perform an operation on their behalf. While tokens created via trusts are limited in what they can do, the limitations are only on things like change passwords or create a new token. Thus, if an attacker compromises a compute node and harvests tokens, the highest value attack for them is to automatically create a trust from the compromised user to some other account. This bypasses the time limitation of the token expiration, and will allow the attacker to perform operations on the users resources at the attackers convenience. Any site that is running a recent version of Heat would be expected to have many trusts set up from the customer user accounts to the Heat service user. Heat creates trusts using the users tokens, so we know this approach is not just theoretical, but actively used. This leaves a fairly obvious trail, in that a user can see all of the trusts created with the user as the trustor. Any trusts that do not have a Heat user as the trustee are suspect. It might even be possible to compromise Heat users, so even those should be audited. There are other ways that a harvested token can be abused, but the trust approach is the one I find the most worrysome, as it could be done as a "sleeper" agent. The same issues apply to the OAUTH1.0a extension. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp