[OSSA 2014-022] V2 Trusts allow trustee to emulate trustor in other projects (CVE-2014-3520)

[Jamie Lennox]

When you consume a trust in a v2 token you must provide the project id as part of your auth. This is a bug and should be reported after this.

If the trustee requests a trust scoped token to a project different to the one the trust is created for AND the trustor has the required roles in the other project then the token will be provided with those roles on the other project.

Attaching a script to show the problem.

[Grant Murphy (gmurphy)]

Thank you for the report.

The OSSA task is incomplete pending additional details from security reviewers.

[Jamie Lennox (jamielennox)]

The if (trust_ref['project_id'] and tenant_id != trust_ref['project_id']): statement is because there is a test that explicitly checks that a trust may be created without specifying a project name.

I don't see why that would be a good idea.

[Adam Young (ayoung)]

+1 on the patch

[Tristan Cacqueray (tristan-cacqueray)]

So, this is an un-expected privilege escalation through an out of scope user supplied project id.
This should warrant an OSSA...

It appears to have been introduced at least in Havana, but it may be in Grizzly as well.

@Jamie Lennox: do you think this can be backported without a massive refactoring ?

[Tristan Cacqueray (tristan-cacqueray)]

Here would be the impact description #1:

Title: Keystone V2 trusts privilege escalation through user supplied project id
Reporter: Jamie Lennox (Red Hat)
Products: Keystone
Versions: up to 2013.2.3, and 2014.1 to 2014.1.1

Description:
Jamie Lennox from Red Hat reported a vulnerability in Keystone trusts. By using an out of scope project id, a trustee may gain unauthorized access to another project if the trustor has the required roles to the other project. All Keystone deployments configured to enable trusts and V2 API are affected.

[Grant Murphy (gmurphy)]

+1 Impact description looks good.

Although I find this sentence a little wordy :

 > a trustee may gain unauthorized access to another project if the trustor has the required roles to the other project.

But it still makes sense to me. Up to you if you tweak it.

[Jamie Lennox (jamielennox)]

Havana is not hard and attached. Grizzly seems to be a fairly major difference though some form of trusts is available there. Do we need to look at Grizzly?

[Grant Murphy (gmurphy)]

As per https://wiki.openstack.org/wiki/Releases Grizzly is no longer security supported. For the purposes of the OSSA we don't need a patch for it.

[Brant Knudson (blk-u)]

Is there a separate patch for stable/icehouse? 0001-Ensure-that-in-v2-auth-tenant_id-matches-trust.patch from comment 4 didn't apply.

I tried on master and it worked for me. A client can get a different error back if there's multiple problems with the request but that shouldn't be a problem.

[Tristan Cacqueray (tristan-cacqueray)]

@Grant thanks!

Here is the impact description #2:

Title: Keystone V2 trusts privilege escalation through user supplied project id
Reporter: Jamie Lennox (Red Hat)
Products: Keystone
Versions: up to 2013.2.3, and 2014.1 to 2014.1.1

Description:
Jamie Lennox from Red Hat reported a vulnerability in Keystone trusts. By using an out of scope project id, a trustee may gain unauthorized access if the trustor has the required roles in the requested project id. All Keystone deployments configured to enable trusts and V2 API are affected.

[Thierry Carrez (ttx)]

+1 for impact desc

[Tristan Cacqueray (tristan-cacqueray)]

Brant is correct, the first patch in comment #4 does not apply on stable/icehouse, Could you please attach that last patch ?

[Jamie Lennox (jamielennox)]

hmm, it applied without issue for me, might have been the git rerere thing had it saved so i didn't notice. Anyway, attached.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks!

@keystone-coresec All three patches are almost the same, yet can someone have a look at that last icehouse backport please ?

Then we can proceed to stakeholder advance notification, Is this disclosure date ok for you ?
2014-07-01, 1500UTC

[Jeremy Stanley (fungi)]

I'm okay with Tuesday, but with nobody chiming in it looks like it might get bumped to Wednesday the 2nd at this point?

[Dolph Mathews (dolph)]

*reviewing now*

[Dolph Mathews (dolph)]

+1 for master patch in comment #4
+1 for stable/icehouse patch in comment #15
+1 for stable/havana patch in comment #9
+1 for description in comment #12

[Jamie Lennox (jamielennox)]

1500 UTC is the middle of the night for me, i'm happy for someone else to submit them to gerrit to get the patch out at that time.

[Dolph Mathews (dolph)]

I'll be available to submit patches to gerrit.

[Tristan Cacqueray (tristan-cacqueray)]

@Jamie Lennox, well it's not mandatory at all :) We prefer having someone from keystone-coresec to push patch in case of un-expected failures, but hopefully it's just a mater of applying patch and hitting git-review.

Thanks Dolph for taking care of that. The disclosure date have been set to:
2014-07-02, 1500UTC

[Brant Knudson (blk-u)]

0001-Ensure-that-in-v2-auth-tenant_id-matches-trust.patch -- comment 4 (master)
 - tests: passed
 - manual inspection: +1

icehouse -- comment 15 (icehouse)
 - tests: passed
 - manual inspection: +1

havana.patch -- comment 9 (havana)
 - tests:
 - manual inspection: +1

impact statement -- comment 12
 - the text "required roles in the requested project id" should have "id" removed.
 - the text "trusts and V2 API" should be "trusts and the Identity V2 API"
   (in case someone things there's a trust v2 api or something)

[Brant Knudson (blk-u)]

Looking at the commit message, it doesn't make sense:

Previously if a trustee requests a trust scoped token for a project that
is different to the one in the trust, however the trustor has the
appropriate roles then a token would be issued.

I think "however" is meant to be "if"

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/104217

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/104218

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/104218
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=96d9bcf230a74d6122a2b14e00ef10915c8f76e3
Submitter: Jenkins
Branch: stable/havana

commit 96d9bcf230a74d6122a2b14e00ef10915c8f76e3
Author: Jamie Lennox <email address hidden>
Date: Thu Jun 19 14:41:22 2014 +1000

    Ensure that in v2 auth tenant_id matches trust

    Previously if a trustee requests a trust scoped token for a project that
    is different to the one in the trust, however the trustor has the
    appropriate roles then a token would be issued.

    Ensure that the trust that was given matches the project that was
    specified in the scope.

    (cherry picked from commit 1556faec2f65dba60584f0a9657d5b717a6ede3a)

    Closes-Bug: #1331912
    Change-Id: I00ad783bcb93cea9e5622965f81b91c80f4570cc

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/104217
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=44555e83bad04210cf6ddc24999e753178357043
Submitter: Jenkins
Branch: stable/icehouse

commit 44555e83bad04210cf6ddc24999e753178357043
Author: Jamie Lennox <email address hidden>
Date: Thu Jun 19 14:41:22 2014 +1000

    Ensure that in v2 auth tenant_id matches trust

    Previously if a trustee requests a trust scoped token for a project that
    is different to the one in the trust, however the trustor has the
    appropriate roles then a token would be issued.

    Ensure that the trust that was given matches the project that was
    specified in the scope.

    (cherry picked from commit 1556faec2f65dba60584f0a9657d5b717a6ede3a)

    Change-Id: I00ad783bcb93cea9e5622965f81b91c80f4570cc
    Closes-Bug: #1331912

[OpenStack Infra (hudson-openstack)]

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

commit 79ad85a8ed9b7a3403367e2b6affe30ee69d21c5
Author: Jamie Lennox <email address hidden>
Date: Thu Jun 19 14:41:22 2014 +1000

    Ensure that in v2 auth tenant_id matches trust

    Previously if a trustee requests a trust scoped token for a project that
    is different to the one in the trust, however the trustor has the
    appropriate roles then a token would be issued.

    Ensure that the trust that was given matches the project that was
    specified in the scope.

    Change-Id: I00ad783bcb93cea9e5622965f81b91c80f4570cc
    Closes-Bug: #1331912