Non-Admin Access to Revocation Events

[Adrian Turjak]

With the default Keystone policy any authed user can list all revocation events for the cluster:
https://github.com/openstack/keystone/blob/master/etc/policy.json#L179

This can be done by directly calling the API as such:
curl -g -i -X GET http://localhost/identity/v3/OS-REVOKE/events -H "Accept: application/json" -H "X-Auth-Token: <non_admin_token_goes_here>"

and this will provide you with a normal revocation event list (see attachment).

This will allow a user to over time collect a list of user_ids and project_ids. The project_ids aren't particularly useful, but the user_ids can be used to lock people of of their accounts. Or if rate limiting is not setup (a bad idea), or somehow bypassed, would allow someone to brute force access to those ids.

Knowing the ids is no worse than knowing the usernames, but as a non-admin you shouldn't have access to such a list anyway.

It is also worth noting that OpenStack policy files are rife with these blank policy rules, not just Keystone. Some are safe and intended to be accessible by any authed user, others are checked at the code layer, but there may be other rules that are unsafe to expose to any authed user and as such should actually default to "rule:admin_required" or something other than blank.

[Morgan Fainberg (mdrnstm)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Morgan Fainberg (mdrnstm)]

Now that I've added the security templates. Putting on my Keystone hat, the intent of the revocation events is that they are meant to be public. When they were designed it was not possible (via keystone code directly) to lock people out of their accounts via attempted logins (no PCI-DSS support like we have today).

In reality, if we are ok with online-only validation (UUID and Fernet) and ok with tokens being cached/valid for the cached duration (without verification of the revocation event-list by the external consumer), then we can make this change / make the revocation event listing API deprecated with the intent that it is not meant to be used any longer. It was much more important when we had PKI tokens to have a public revocation event bundle that did not include the token IDs (the old Revocation list was a list of token IDs and therefore had to be a priv operation).

If we are intending the revocation event list to be consumable in any form (not strictly asking keystone for the validation due to cache), I don't want to make it a priv. operation again.

I would like to see another keystone-coresec weigh in on this regarding severity before I try and offer a classification (since I am part of the VMT).

[Morgan Fainberg (mdrnstm)]

Please note this bug has been publicly discussed in the #openstack-keystone channel prior to submission to Launchpad.

[Morgan Fainberg (mdrnstm)]

As an additional point, it may not be backportable (a policy.json fix) as that either will not hit deployments and/or will change behavior directly (which may be in use).

[Jeremy Stanley (fungi)]

It's mentioned quite prominently starting at http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2016-12-13.log.html#t2016-12-13T01:34:31 so at a minimum we should end the embargo by switching this to Public Security.

[Adrian Turjak (adriant-y)]

My apologies for that. Wasn't exactly sure what I was looking at. This seemed like it may have been just standard keystone operation so was trying to work it out, and irc seemed like a good place to ask.

Will in future if I find something odd that looks even vaguely like a security problem leave it out of public channels until I'm sure it isn't.

[Steve Martinelli (stevemar)]

Adrian, no worries.

fungi, I'm OK with lifting the embargo.

[Steve Martinelli (stevemar)]

I think defaulting the policy to `rule:admin_required` is decent place to start. But as Morgan said, I'm not sure how useful it is to list revocation events now. Would love to hear from ayoung.

[Adam Young (ayoung)]

Remove the API. It is not longer needed. `rule:admin_required` is also sufficient

[Jeremy Stanley (fungi)]

I've switched this report to Public Security now, ending the embargo; it was already discussed elsewhere in public per comments #4/#6.

[Steve Martinelli (stevemar)]

Sounds like we should at least make the API `rule:admin_required` in the default policy file.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/416841
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=d4a890a6c8bd6927e229f4b665a982a51c130073
Submitter: Jenkins
Branch: master

commit d4a890a6c8bd6927e229f4b665a982a51c130073
Author: Steve Martinelli <email address hidden>
Date: Thu Jan 5 00:41:34 2017 -0500

    listing revoke events should be admin only

    Currently any user can list revocation events, this data contains
    IDs for users and projects. It should not be made available to
    any user that is able to authenticate, it should be an admin
    only API call.

    Change-Id: I4290163c67c84ef0e1a2f6ee967ddf2acb2c3212
    Closes-Bug: 1649446

[Jeremy Stanley (fungi)]

Consensus seems to be that this was intentional behavior, but worth changing (as evidenced by a subsequent fix to master). Given that and the lack of stable branch backports, I'm going to treat this as a security hardening opportunity. If there is fierce disagreement favoring backports and an official advisory, we can revisit the classification at that time.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 11.0.0.0b3 development milestone.

[Frode Nordahl (fnordahl)]

Fix proposed on branch: master
Review: https://review.openstack.org/#/c/428759/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/428759
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=67034c4db8613e8cead5e5839edbecf040b4fb91
Submitter: Jenkins
Branch: master

commit 67034c4db8613e8cead5e5839edbecf040b4fb91
Author: Frode Nordahl <email address hidden>
Date: Tue Jan 10 08:50:28 2017 +0100

    Update policy.json for Ocata

    Refresh v2 and v3 portion of policy.json from upstream keystone
    repository @ commit
    d4a890a6c8bd6927e229f4b665a982a51c130073

    Add functional tests to verify effect of policy

    Update functional tests to use keystone_configure_api_version
    from charm-helpers

    Update functional tests to correctly validate cinder services
    when openstack release >= ocata

    Enable functional test for ocata, set appropriate cinder
    configuration.

    Change-Id: Idf07ff3a7c9d7e7eb30792719541319ab3426a41
    Closes-Bug: 1651989
    Closes-Bug: 1649446