Open Stack

This is probably closest to C1 in our incident report taxonomy. Not
practical, no advisory but possible security note.
https://security.openstack.org/vmt-process.html#incident-report-taxonomy

** Information type changed from Public Security to Public

** Tags added: security

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

Title:
  Hypervisor compromise may result in malicious trust creation

Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

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