Open Stack

*** This bug is a security vulnerability ***

You have been subscribed to a private security bug by Grant Murphy (gmurphy):

This issue is being treated as a potential security risk under embargo.
Please do not make any public mention of embargoed (private) security
vulnerabilities before their coordinated publication by the OpenStack
Vulnerability Management Team in the form of an official OpenStack
Security Advisory. This includes discussion of the bug or associated
fixes in public forums such as mailing lists, code review systems and
bug trackers. Please also avoid private disclosure to other individuals
not already approved for access to this information, and provide this
same reminder to those who are made aware of the issue prior to
publication. All discussion should remain confined to this private bug
report, and any proposed fixes should be added to the bug as
attachments.

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.

** Affects: keystone
     Importance: Undecided
         Status: Confirmed

** Affects: ossa
     Importance: Undecided
         Status: Incomplete

-- 
Hypervisor compromise my result in malicious trust creation
https://bugs.launchpad.net/bugs/1455582
You received this bug notification because you are a member of OpenStack Security, which is subscribed to the bug report.