yahoo-eng-team team mailing list archive

[OpenStack Infra <1872735@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/725886
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=37e9907a176dad6843819b1bec4946c3aecc4548
Submitter: Zuul
Branch:    master

commit 37e9907a176dad6843819b1bec4946c3aecc4548
Author: Colleen Murphy <colleen.murphy@xxxxxxxx>
Date:   Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials
    
    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.
    
    1. Disable altering credential owner attributes or metadata
    
    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.
    
    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.
    
    2. Respect token roles when creating EC2 credentials
    
    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.
    
    Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
    Closes-bug: #1872733
    Closes-bug: #1872755
    Closes-bug: #1872735


** Changed in: keystone
       Status: In Progress => 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/1872735

Title:
  [OSSA-2020-004] EC2 and/or credential endpoints are not protected from
  a scoped context (CVE-2020-12689)

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

Bug description:
  Being authorized within a limited scope context, i.e. trust / oauth / application credential with a limited role, e.g. "monitoring_viewer" or "viewer", it is still possible to create EC2 credentials. User can auth against Keystone using EC2 credentials and obtain all project roles
   of a trust/oauth/application_credential owner.

  I prepared a tool to auth against keyston using ec2 credentials:
  https://github.com/kayrus/ec2auth

  * auth against keystone using trust/oauth/application_credential credentials
  * issue ec2 credentials: "openstack ec2 credentials create"
  * authenticate against keystone using ec2 credentials: "ec2auth --access 7522162ced8f4e3eb9502168ef199584 --secret c558d9401a6943bbbb77a83ce910e5a5 --debug"

  You'll see that returned token contains all owner roles.

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