yahoo-eng-team team mailing list archive

[Colleen Murphy <colleen@xxxxxxxxxxx>]

https://review.openstack.org/#/c/501148 has merged so I will close this
as fix released.

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

-- 
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/1566416

Title:
  Keystone does not validate that s3tokens requests came from s3_token
  middleware

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Ordinarily, during a keystone-authenticated swift3 request,

   * the client talks to a swift proxy-server, sending a request with
     an Authorization header that includes a credential identifier and
     signature;
   * swift3 (in the proxy-server's pipeline) recognizes that this is
     a S3 request, normalizes the request information to be the same
     format as was used in the signature, and includes it in the WSGI
     environment;
   * s3_token picks up the normalized request, credential identifier,
     and user-provided signature and sends them all to keystone;
   * keystone's s3 extension uses the credential identifier to look up
     the credential's secret, signs the normalized request, and
     compares the user-provided signature to the expected one. If they
     match, a fresh project-scoped token is issued; otherwise a 401 is
     returned.
   * s3_token either bubbles up the 401 response or puts the token and
     tenant information into the WSGI environment so swift3 and
     auth_token may continue handling the request.

  Given knowledge of the HTTP method, path, and headers of a valid past
  request, an attacker can bypass swift and obtain a project-scoped
  token directly from keystone. This may be done well after the initial
  request (and resulting token) have expired. The new token may be used
  to access any service for which the original user is authorized.

  Proposed solution:

  Have the s3 extension in keystone verify that the request came from
  the s3_token middleware. This may be done via either a service token
  (similar to what's done in keystonemiddleware's auth_token middleware)
  or a rotating pre-shared key (similar to what's done in swift's
  tempurl middleware).

  Alternative solutions:

  Have the s3 extension only enabled in the v2.0 admin pipeline,
  remove it from the v3 pipeline, and expose the v2.0 admin endpoint
  only on internal networks. With the convergence of the admin and
  public pipelines in v3, this seems unlikely to provide a long-term
  solution. However, it may be a useful mitigation for deployments
  that cannot quickly upgrade.

  Have the s3 extension parse the normalized request, find the
  timestamp, and reject requests with a timestamp more than 5 minutes
  off from the server's time. This conflates keystone's responsibility
  (authentication) with that of swift3 (authorization) and leads to
  duplicated efforts.

  Additional mitigation:

  Require users to change their S3/EC2 credentials regularly.

  (Note that while this is similar to bug #1561199, the two bugs cover
  separate issues. 1561199 involves inter-middleware communication
  within a single WSGI pipeline. This bug involves the communication
  between separate services.)

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