yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Summary changed:

- Validation of PKI tokens bypasses revocation check
+ [OSSA 2013-009] Validation of PKI tokens bypasses revocation check

** Also affects: ossa
   Importance: Undecided
       Status: New

** Changed in: ossa
       Status: New => Fix Released

** Changed in: ossa
     Assignee: (unassigned) => Thierry Carrez (ttx)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1129713

Title:
  [OSSA 2013-009] Validation of PKI tokens bypasses revocation check

Status in OpenStack Identity (Keystone):
  Invalid
Status in Keystone folsom series:
  Fix Released
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  for PKI tokens, we are bypassing token.get_token() call and therefore
  skipping the “valid=True” check.

  In Grizzly, this code is in keystone/token/controllers.py
  In Folsom, this code is in keystone/service.py

  The if block bypasses the backend  check.  It is in the backend where
  tokens are checked for revocation.

  def _get_token_ref(self, context, token_id, belongs_to=None):
          """Returns a token if a valid one exists.

  Optionally, limited to a token owned by a specific tenant.

  """
          # TODO(termie): this stuff should probably be moved to middleware
          self.assert_admin(context)

          if cms.is_ans1_token(token_id):
              data = json.loads(cms.cms_verify(cms.token_to_cms(token_id),
                                               CONF.signing.certfile,
                                               CONF.signing.ca_certs))
              data['access']['token']['user'] = data['access']['user']
              data['access']['token']['metadata'] = data['access']['metadata']
              if belongs_to:
                  assert data['access']['token']['tenant']['id'] == belongs_to
              token_ref = data['access']['token']
          else:
              token_ref = self.token_api.get_token(context=context,
                                                   token_id=token_id)
          return token_ref

  The exposure is limited to people that are passing the whole PKI token
  back for validation via the web service.

  This PKI tokens were supposed to be validated primarily via Crypto,
  but there is an option to validate them against the live server as
  well.  It is only this last code path that is affected.   It is
  unlikely to be triggered in Folsom, as people have to make a
  deliberate decision to  use PKI tokens, and  are unlikely to be
  validating them against the Keystone server.

  Remote services can choose to pass a Hash of the PKI token to the
  validate Web API, which web services are likely to do, as the Hash is
  short enough to fit in a cookie.  The Hash is then it looked up using
  the backend get_token()  behavior and works correctly.

   It does not effect the keystone calls that first require validating
  the token.  For example if a user runs tenant_list against their own
  account, using a PKI token, they do

   token_ref = self.token_api.get_token(context=context,
                                        token_id=context['token_id'])

  This was discovered by Guang Yee.

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