user can update his password without knowing the old password

[Matthias Runge]

a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password.

[Thierry Carrez (ttx)]

See also https://bugzilla.redhat.com/show_bug.cgi?id=1016647

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/50962

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/50964

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/50966

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/51157

[Julie Pichon (jpichon)]

What would now be the recommended way for a user to update their own password, using Keystone? Could a update_own_password method similar to v2 be added to the client?

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/users.py#L69
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/users.py

[Dolph Mathews (dolph)]

I'm thinking of introducing at least two new API's targeted at consumption by end users in icehouse, for example:

  /v3/users/{user_id}/password
  /v3/users/{user_id}/default_project_id

I'll be adding functionality for these calls to the client after they land on the service side.

[Thierry Carrez (ttx)]

With the proposed fix I see two sides in this issue: an unfortunate default (update_user not being restricted to admin_required) and a v3 API gap (no way for users to update password in a secure manner).

This makes this OSSN territory: we need to warn users that they may not be as secure as they think with the Grizzly default and should consider changing it.

Havana should have the "right" default. Icehouse should add the missing API call, completing the strengthening.
Thoughts ?

[Matthias Runge (mrunge)]

the proposed "fix" for horizon is to disable password updates by users, when keystone is using v3. IMHO that's unfortunate.

The other "fix" would be, not to require admin privileges and to check, if the given password was right. That leaves the server side insecure.

I can't see, how adding a function to keystone v3 will break functionality. Release-wise, this will hurt the schedule, no question.
Still, I'd vote to slip the release and to implement a fix ASAP.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/51667

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/51678

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/50962
Committed: http://github.com/openstack/keystone/commit/8f9eb2808510b41303aece70584124cec4d936da
Submitter: Jenkins
Branch: master

commit 8f9eb2808510b41303aece70584124cec4d936da
Author: Dolph Mathews <email address hidden>
Date: Thu Oct 10 10:36:00 2013 -0500

    set user_update policy to admin_required

    This changes the default policy.json to prevent users from changing
    their own attributes such as password, name, or default_project_id.

    Closes-Bug: 1237989
    Change-Id: I7de5fff3d72a76b78113e289c57a9fac2096395f

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/51157
Committed: http://github.com/openstack/horizon/commit/417068b49277c9c6bd3dd6bcac055badaec21e25
Submitter: Jenkins
Branch: master

commit 417068b49277c9c6bd3dd6bcac055badaec21e25
Author: Matthias Runge <email address hidden>
Date: Fri Oct 11 11:17:59 2013 +0200

    Hide settings/change password on keystone v3

    When using keystone v3, it was possible to change the user
    password without knowing the old password.

    Change-Id: I2e3721f9c8a1de4b9a5f85b230432844d2c83507
    Closes-Bug: 1237989

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/51667
Committed: http://github.com/openstack/horizon/commit/d716bfcdbfe6d4c22df9e1ae5fdb7a54d5150f28
Submitter: Jenkins
Branch: milestone-proposed

commit d716bfcdbfe6d4c22df9e1ae5fdb7a54d5150f28
Author: Matthias Runge <email address hidden>
Date: Fri Oct 11 11:17:59 2013 +0200

    Hide settings/change password on keystone v3

    When using keystone v3, it was possible to change the user
    password without knowing the old password.

    Change-Id: I2e3721f9c8a1de4b9a5f85b230432844d2c83507
    Closes-Bug: 1237989

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/50966
Committed: http://github.com/openstack/keystone/commit/3866991918beb818aa26aeab287a247f4732f6e7
Submitter: Jenkins
Branch: milestone-proposed

commit 3866991918beb818aa26aeab287a247f4732f6e7
Author: Dolph Mathews <email address hidden>
Date: Thu Oct 10 10:36:00 2013 -0500

    set user_update policy to admin_required

    This changes the default policy.json to prevent users from changing
    their own attributes such as password, name, or default_project_id.

    Closes-Bug: 1237989
    Change-Id: I7de5fff3d72a76b78113e289c57a9fac2096395f

[Thierry Carrez (ttx)]

For the OSSN crew:
We need to warn Grizzly users that they may not be as secure as they think with the Grizzly default for "user_update" policy and should consider changing it to "admin_required".

[Thierry Carrez (ttx)]

This was assigned CVE-2013-4471

[Nathan Kinder (nkinder)]

Authenticated users are able to update passwords without providing their current password
---

### Summary ###
An authenticated user is able to change their password without providing their current password. This allows compromised authentication tokens to be used to permanently compromise a user account.

### Affected Services / Software ###
Horizon, Keystone, Identity, Grizzly

### Discussion ###
Horizon allows a user to change their own password, which uses the Identity API to perform the password change. A user is required to supply their current password to successfully perform a password change. This requirement prevents a malicious user from stealing a users authentication token and changing that user's password to permanently compromise their account. With this additional password check, a compromised authentication token only compromises the user account until the token is no longer valid due to expiration or revocation.

When using the Identity v3 API, a user is able to successfully change their password without supplying the correct current password. This leaves users vulnerable to permanently compromised accounts if their authentication token is compromised. The Identity v2 API is not vulnerable to this issue, as it has a separate API call for updating user passwords that properly validates the current password.

### Recommended Actions ###
In the OpenStack Grizzly release, a user is allowed to update the attributes in their own entry by default. It is recommended that you restrict user updates to only be allowed by admin users. This is done by setting the "update_user" policy to "admin_required" in Keystone's policy.json file. Here is an example snippet of a properly configured policy.json file:

---- begin example policy.json snippet ----
    "identity:get_user": [["rule:admin_required"]],
    "identity:list_users": [["rule:admin_required"]],
    "identity:create_user": [["rule:admin_required"]],
    "identity:update_user": [["rule:admin_required"]],
    "identity:delete_user": [["rule:admin_required"]],
---- end example policy.json snippet ----

This change has the side-effect of restricting a user from updating any of their own attributes, not just their password.

In the OpenStack Havana release, the default policy is to only allow admin users to update attributes in user entries. In addition, Horizon will not allow a user to change their own password if it is using the Identity v3 API, even if Keystone is configured to allow users to update their own entries. Despite this restriction in Horizon, it is recommended to leave the default "update_user" policy setting as is, as an attacker could target Keystone directly without using Horizon to initiate a password change.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4471

[Robert Clark (robert-clark)]

Great OSSN, I'd say it'd ready to publish pretty much.

In the third sentence of the discussion "a users" needs to read "a user's"

[Nathan Kinder (nkinder)]

Authenticated users are able to update passwords without providing their current password
---

### Summary ###
An authenticated user is able to change their password without providing their current password. This allows compromised authentication tokens to be used to permanently compromise a user account.

### Affected Services / Software ###
Horizon, Keystone, Identity, Grizzly

### Discussion ###
Horizon allows a user to change their own password, which uses the Identity API to perform the password change. A user is required to supply their current password to successfully perform a password change. This requirement prevents a malicious user from stealing a user's authentication token and changing that user's password to permanently compromise their account. With this additional password check, a compromised authentication token only compromises the user account until the token is no longer valid due to expiration or revocation.

When using the Identity v3 API, a user is able to successfully change their password without supplying the correct current password. This leaves users vulnerable to permanently compromised accounts if their authentication token is compromised. The Identity v2 API is not vulnerable to this issue, as it has a separate API call for updating user passwords that properly validates the current password.

### Recommended Actions ###
In the OpenStack Grizzly release, a user is allowed to update the attributes in their own entry by default. It is recommended that you restrict user updates to only be allowed by admin users. This is done by setting the "update_user" policy to "admin_required" in Keystone's policy.json file. Here is an example snippet of a properly configured policy.json file:

---- begin example policy.json snippet ----
    "identity:get_user": [["rule:admin_required"]],
    "identity:list_users": [["rule:admin_required"]],
    "identity:create_user": [["rule:admin_required"]],
    "identity:update_user": [["rule:admin_required"]],
    "identity:delete_user": [["rule:admin_required"]],
---- end example policy.json snippet ----

This change has the side-effect of restricting a user from updating any of their own attributes, not just their password.

In the OpenStack Havana release, the default policy is to only allow admin users to update attributes in user entries. In addition, Horizon will not allow a user to change their own password if it is using the Identity v3 API, even if Keystone is configured to allow users to update their own entries. Despite this restriction in Horizon, it is recommended to leave the default "update_user" policy setting as is, as an attacker could target Keystone directly without using Horizon to initiate a password change.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4471

[Nathan Kinder (nkinder)]

Published on OpenStack and OpenStack-Dev mailing lists on 22 Nov 2013.