[OSSA 2016-008] v2.0 fernet tokens audit ids are inconsistent (CVE-2016-4911)

Bug #1577558 reported by Lance Bragstad
266
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Lance Bragstad
Mitaka
Fix Released
High
Unassigned
OpenStack Security Advisory
Fix Released
Undecided
Unassigned

Bug Description

If you set the token provider to token.provider = fernet, get an unscoped token from v2.0, then rescope that token to a project, you'll notice the audit ids don't match. I've recreated this issue in a test [0].

What should happen is that the unscoped token response will have a list of audit_ids containing a single audit_id. The project scoped token response from the unscoped token will also have a list of audit_ids in the token response but the original audit_id from the unscoped token will be in the list of the project scoped token.

Right now this behavior doesn't exist in with the fernet provider on v2.0.

[0] https://review.openstack.org/#/c/311816/1

CVE References

tags: added: fernet
tags: added: mitaka-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

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

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: New → In Progress
Changed in keystone:
assignee: Lance Bragstad (lbragstad) → Steve Martinelli (stevemar)
Changed in keystone:
assignee: Steve Martinelli (stevemar) → Lance Bragstad (lbragstad)
Revision history for this message
Matt Riedemann (mriedem) wrote : Re: v2.0 fernet tokens audit ids are inconsistent
Changed in keystone:
importance: Undecided → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/312582

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit 0d376025bae61bf5ee19d992c7f336b99ac69240
Author: Lance Bragstad <email address hidden>
Date: Mon May 2 19:16:11 2016 +0000

    Fix fernet audit ids for v2.0

    The fernet token provider was doing some weird things with audit ids that
    caused token rescoping to not work because audit ids were never pulled from the
    original token. This commit also enables some tests for v2.0 authentication
    with the Fernet as the token provider.

    Closes-Bug: 1577558
    Change-Id: Iffbaf505ef50a6c6d97c5340645acb2f6fda7e0e

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
Brant Knudson (blk-u) wrote : Re: v2.0 fernet tokens audit ids are inconsistent

This means that if you're using fernet then revocation doesn't work, because we revoke by audit ID.

information type: Public → Public Security
Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Changed in ossa:
status: New → Incomplete
Revision history for this message
Jeremy Stanley (fungi) wrote :

Does this mean token revocation is broken for all production deployments using fernet tokens? Only affects stable/mitaka, or was the implementation available in any earlier releases as well?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/mitaka)

Reviewed: https://review.openstack.org/312582
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ee1dc941042d1f71699971c5c30566af1b348572
Submitter: Jenkins
Branch: stable/mitaka

commit ee1dc941042d1f71699971c5c30566af1b348572
Author: Lance Bragstad <email address hidden>
Date: Mon May 2 19:16:11 2016 +0000

    Fix fernet audit ids for v2.0

    The fernet token provider was doing some weird things with audit ids that
    caused token rescoping to not work because audit ids were never pulled from the
    original token. This commit also enables some tests for v2.0 authentication
    with the Fernet as the token provider.

    Closes-Bug: 1577558
    Change-Id: Iffbaf505ef50a6c6d97c5340645acb2f6fda7e0e
    (cherry picked from commit 0d376025bae61bf5ee19d992c7f336b99ac69240)

tags: added: in-stable-mitaka
Changed in ossa:
status: Incomplete → Confirmed
Revision history for this message
Morgan Fainberg (mdrnstm) wrote : Re: v2.0 fernet tokens audit ids are inconsistent

Proposed impact description -

Title: Incorrect Audit IDs in Keystone Fernet Tokens
Reporter: Lance Bragstad (Rackspace)
Products: OpenStack Kesytone
Affects: Master (Newton), Mitaka

Description:
Lance Bragstad (Rackspace) reported a vulnerability in the Keystone Fernet Token Provider. When Keystone was configured to use Fernet tokens, the unique string (audit_id) was not properly maintained during a token rescope (requesting a token for a new project scope using the current token for authentication). This resulted in the inability to revoke entire chain of tokens. The revocation of the chain of tokens. Most revocations are not for the entire chain of tokens. Only Master (Newton) and Mitaka releases of Keystone configured to use Fernet as the Keystone token provider were affected.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

2nd Revision impact statement

Title: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass
Reporter: Lance Bragstad (Rackspace)
Products: OpenStack Kesytone
Affects: >=9.0.0

Description:
Lance Bragstad (Rackspace) reported a vulnerability in the Keystone Fernet Token Provider. By rescoping a token a user will receive a new token without correct audit_ids, these incorrect audit_ids will prevent the entire chain of tokens from being revoked properly. This vulnerability does not impact revoking a token by it's individual audit_id. Only deployments with Keystone configured to use Fernet tokens are impacted.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

Erm, I think I got the Affects >= incorrect.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

Beside the affect line that should be "==9.0.0", the impact description in comment #10 LGTM. Thanks Morgan!

Revision history for this message
Lance Bragstad (lbragstad) wrote :

+1 on the impact description. Thanks Morgan!

Changed in ossa:
status: Confirmed → In Progress
Revision history for this message
Ian Cordasco (icordasc) wrote :

CVE-2016-4911 has been assigned to this but Launchpad believes it to be invalid.

Revision history for this message
Steve Martinelli (stevemar) wrote :

impact looks fine to me!

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

@Ian,

I'll look into that tomorrow. That was the number assigned when it was requested. I'll confirm it's not doing something weird. Thanks for pointing it out.

Revision history for this message
Matthew Thode (prometheanfire) wrote :

Did this impact liberty?

Revision history for this message
Lance Bragstad (lbragstad) wrote :

I don't think this impacts liberty because in liberty the fernet provider was technically still it's *own* provider. When Fernet tokens were originally introduced, the provider inherited the BaseProvider class from keystone.token.providers.common.py but it overrode a lot of the methods provided because it needed to do specific things [0]. This resulted in differences in the token responses depending on if the token being validated was a fernet token or a uuid token. One of the top priorities for the Mitaka release was to consolidate the duplicated methods in the Fernet provider into the BaseProvider. This is where the bug comes from because the Fernet provider had to use a couple hooks in order to pull the attributes needed out of the v2 token request. The logic that pulled the attributes was wrong about audit_ids and it wasn't tested against v2.

I'll pull down the latest liberty branch and test this locally.

[0] https://github.com/openstack/keystone/blob/stable/liberty/keystone/token/providers/fernet/core.py#L41

Revision history for this message
Lance Bragstad (lbragstad) wrote :

This doesn't seem to be an issue with liberty. I pulled the latest liberty as of today:

commit 26240963712541d215d414fa71596cccc60dd7ce

I was able to get a token with an audit_id = "8HAaHKMnSxe-wrTTv2RgxA". I rescoped that token and the audit_ids returned in the response contained the original audit_id from the first token:

"audit_ids": [
                "i8OpkdQHSJOgMQVIJgkG9w",
                "8HAaHKMnSxe-wrTTv2RgxA"
            ],

This doesn't seem to apply to liberty (probably because of the reasoning listed in comment #18). The following pastes are the authentication responses from my manual test.

original token: http://paste.openstack.org/show/497523/
rescoped token: http://paste.openstack.org/show/497524/

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/keystone 9.0.1

This issue was fixed in the openstack/keystone 9.0.1 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to ossa (master)

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

summary: - v2.0 fernet tokens audit ids are inconsistent
+ [OSSA 2016-008] v2.0 fernet tokens audit ids are inconsistent
+ (CVE-2016-4911)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to ossa (master)

Reviewed: https://review.openstack.org/320209
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=c6db6d9d4ab7193fc4d48cd5eaca3c8a0c56a024
Submitter: Jenkins
Branch: master

commit c6db6d9d4ab7193fc4d48cd5eaca3c8a0c56a024
Author: Morgan Fainberg <email address hidden>
Date: Mon May 23 20:48:44 2016 -0700

    Adds OSSA 2016-008 (CVE-2016-4911)

    Change-Id: I35ae3174ce88363c1a2b0b3f8c5beb0a3054d928
    Related-Bug: #1577558

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/keystone 10.0.0.0b1

This issue was fixed in the openstack/keystone 10.0.0.0b1 development milestone.

Changed in ossa:
status: In Progress → Fix Released
Changed in keystone:
milestone: none → newton-1
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.