Open Stack

This seems to be OSSN territory. Subscribed OpenStack security team for
input.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1455582

Title:
  Hypervisor compromise my result in malicious trust creation

Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions