yahoo-eng-team team mailing list archive

[OpenStack Infra <1688137@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/ossa/+/803640
Committed: https://opendev.org/openstack/ossa/commit/cf49e91bb4a6a663b960d65f87841f9ba589a8e4
Submitter: "Zuul (22348)"
Branch:    master

commit cf49e91bb4a6a663b960d65f87841f9ba589a8e4
Author: Jeremy Stanley <fungi@xxxxxxxxxxx>
Date:   Thu Aug 5 18:25:32 2021 +0000

    Add OSSA-2021-003 (CVE-2021-38155)
    
    Change-Id: Ic9c5d7a45be8a083931b2600adbc76c9e292d0ab
    Closes-Bug: #1688137


** Changed in: ossa
       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/1688137

Title:
  [OSSA-2021-003] Account name and UUID oracles in account locking
  (CVE-2021-38155)

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

Bug description:
  This relates to PCI DSS features added in the Newton release.
  The involved PCI DSS requirements are 8.1.6 and 8.1.7, as described below:

  8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.
  8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

  The options lockout_failure_attempts and lockout_duration implement
  those behaviors, respectively.

  If those options are enabled in the keystone configuration file, for
  example:

  [security_compliance]
  # Setting the account lockout threshold
  lockout_failure_attempts = 2
  lockout_duration = 10

  All users in the cloud get exposed and can be subject of an attack.

  The attacker could lock out an user account by:

  1) Try to auth on a user's behalf:

  POST /v3/auth/tokens

  { "auth": {
      "identity": {
        "methods": ["password"],
        "password": {
          "user": {
            "name": "sam",
            "domain": { "id": "default" },
            "password": "fake_password"
          }
        }
      }
    }
  }

  And after lockout_failure_attempts attempts, as the password is wrong
  (as the attacker do not know it), the server returns:

  {
    "error": {
      "code": 401,
      "title": "Unauthorized",
      "message": "The account is locked for user: 94ab353983174b04955fc9842779b085."
    }
  }

  And now the attacker even know the user's ID.

  OR

  2) Try to change a user's password on their behalf (would need to know
  the user's ID):

  POST /v3/users/<user_id>/password
  {
   "user": {
    "original_password": "fake_password",
    "password": "new_password"
   }
  }

  As the original password is wrong (as the attacker do not know it),
  after lockout_failure_attempts attempts that user account get locked
  out by lockout_duration.

  For both 1) and 2), before lockout_failure_attempts attempts, you get:

  {
    "error": {
      "code": 401,
      "title": "Unauthorized",
      "message": "The request you have made requires authentication."
    }
  }

  After lockout_failure_attempts attempts, you get:

  {
    "error": {
      "code": 401,
      "title": "Unauthorized",
      "message": "The account is locked for user: 94ab353983174b04955fc9842779b085."
    }
  }

  These approaches can be used by an attacker to lock out users
  indefinitely by locking out users again and again after
  lockout_duration has passed.

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