yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #46795
[Bug 1455582] Re: Hypervisor compromise may result in malicious trust creation
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