[OSSA 2014-016] User's provider templates show up in listing of resource types globally across tenants (CVE-2014-3801)

Reproduce with:

 heat stack-create -f http://dunsmor.com/pastebin/1398191902.txt test
 heat resource-type-list

Using the latest Heat master branch.

The provider template URL is inserted into the global resource registry here:
https://github.com/openstack/heat/blob/master/heat/engine/stack_resource.py#L146-L154
https://github.com/openstack/heat/blob/master/heat/engine/environment.py#L353

It seems like we would need some sort of local resource registry in Heat to fix this.

Addressed by https://review.openstack.org/#/c/89695

I think that definitely qualifies as info leak. Is there anything specific an attacker can do with that provider template URL once it leaked ?

Thierry, if the provider template author doesn't have sufficient security around the url that the template is retrieved from, an attacker could have access to that user's provider template which *could* include lots of information (ssh keys, password, "secret sauce" server configuration, etc) that the user would rather not share and is otherwise protected data once it reaches Heat.

Agree on the OSSA, classified as info leak.

Reviewed: https://review.openstack.org/89695
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=a02ff20509171346d2a1d2a9df7c81aada134c52
Submitter: Jenkins
Branch: master

commit a02ff20509171346d2a1d2a9df7c81aada134c52
Author: Angus Salkeld <email address hidden>
Date: Thu May 1 11:20:55 2014 +1000

    Don't dynamically create provider types in the global env

    Only support this in user environments.
    Note: this is only when you have the following in your template
    resources:
      thingy:
        type: http://example.com/foo.template

    Doing this will avoid tenant-specific provider template URLs being
    shown globally in the resource-type listing.

    Co-Authored-By: Angus Salkeld <email address hidden>
    Closes-Bug: #1311223
    Change-Id: Ifa18108afacbda390b19b46a8f41bc4f018e95d6

Here is impact description #1:
I used d053963d to track affected versions

Title: Heat template usage information leakage
Reporter: Jason Dunsmore (Rackspace)
Products: Heat
Versions: 2013.2 to 2013.2.3, and 2014.1

Description:
Jason Dunsmore from Rackspace reported a vulnerability in Heat. An authenticated user may see the URL of a provider template used in another tenant by listing heat resources types. The URL disappears from the listing after a certain point in the stack creation. All Heat setups are affected.

may see -> may temporarily see

add "This may result in disclosure of additional information if the template itself can be accessed." before "The URL disappears"

maybe replace "usage" by "URL" in title ?

Can someone confirm the impacted version please ?
Here is impact description #2:

Title: Heat template URL information leakage
Reporter: Jason Dunsmore (Rackspace)
Products: Heat
Versions: 2013.2 to 2013.2.3, and 2014.1

Description:
Jason Dunsmore from Rackspace reported a vulnerability in Heat. An authenticated user may temporarily see the URL of a provider template used in another tenant by listing heat resources types. This may result in disclosure of additional information if the template itself can be accessed. The URL disappears from the listing after a certain point in the stack creation. All Heat setups are affected.

Impact desc +1

Heat core-sec: please confirm impact description and affected versions ?

Sounds correct to me.

Looks good.

+1

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

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

Sorry, belated +1, looking at the stable backport patches now..

Reviewed: https://review.openstack.org/94625
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=03dd894de4ad905dc170e358fad27d9c8ed62a73
Submitter: Jenkins
Branch: stable/icehouse

commit 03dd894de4ad905dc170e358fad27d9c8ed62a73
Author: Angus Salkeld <email address hidden>
Date: Thu May 1 11:20:55 2014 +1000

    Don't dynamically create provider types in the global env

    Only support this in user environments.
    Note: this is only when you have the following in your template
    resources:
      thingy:
        type: http://example.com/foo.template

    Doing this will avoid tenant-specific provider template URLs being
    shown globally in the resource-type listing.

    Co-Authored-By: Angus Salkeld <email address hidden>
    Closes-Bug: #1311223
    Change-Id: Ifa18108afacbda390b19b46a8f41bc4f018e95d6
    (cherry picked from commit a02ff20509171346d2a1d2a9df7c81aada134c52)

Reviewed: https://review.openstack.org/94644
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=7e114a38712da8947ee7ad93eabda34f5e4aa65a
Submitter: Jenkins
Branch: stable/havana

commit 7e114a38712da8947ee7ad93eabda34f5e4aa65a
Author: Angus Salkeld <email address hidden>
Date: Thu May 1 11:20:55 2014 +1000

    Don't dynamically create provider types in the global env

    Only support this in user environments.
    Note: this is only when you have the following in your template
    resources:
      thingy:
        type: http://example.com/foo.template

    Doing this will avoid tenant-specific provider template URLs being
    shown globally in the resource-type listing.

    Co-Authored-By: Angus Salkeld <email address hidden>
    Closes-Bug: #1311223
    Change-Id: Ifa18108afacbda390b19b46a8f41bc4f018e95d6
    (cherry picked from commit a02ff20509171346d2a1d2a9df7c81aada134c52)

Hello,

It is my opinion that relying on the URL being "secret" does not seem to be a proper approach to security, as the URL (as I see it) is ultimately shared between a group of users; at this point, it is no longer so "secret". Then again, the URL might leak via other channels as well. This leads me to a thought that templates should be protected via other mechanisms as well.

I was unable to locate any mention of whether Heat supports e.g. basic HTTP authentication or any other access restriction mechanisms for accessing templates to properly secure the templates. Can someone please point me in a right direction here -- docs, discussions?

Thank you in advance,
D.

I agree that any template containing secrets should be protected by more than obscurity. But leaking (for a brief period of time) the source URL still constitutes a (minor) information leak that can be leveraged as part of a larger attack. That is the basis for the advisory that we sent out.

It might be worth raising the topic of template protection on the mailing-list if you want to make sure to catch the attention of Heat developers on that topic.

Dmitry - what you're raising is a completely separate issue. The solution to that is to get away from having Heat fetch data by URL (possible exception: connections to Swift or the future Glance template repo, authenticated with the user's keystone token). Already python-heatclient automatically fetches templates from their URLs and uploads them to Heat (rather than passing the URL), so in fact nobody should be publicly exposing their templates just so Heat can get at them. The ability to pass a URL will be removed in the next version of the Heat API.

HTTP Basic Auth is *not* a solution, because the username and password appear in the URL.

Thierry, Zane,

Thank you for clarification. Your responses are highly appreciated.

> in fact nobody should be publicly exposing their templates just so Heat can get at them.

Apparently, some people do. In your opinion, what could be the cause of this? Is there something that can be done to improve the situation before the advent of the next Heat API version?

> HTTP Basic Auth is *not* a solution, because the username and password appear in the URL.

Hmm, I fail to see how this is a requirement. RFC2617 [1] requires authentication credentials to be passed via a specific header. How it gets there is implementation details. Surely, one can pass credentials via the URL (if one's HTTP library supports this), but this is not the only way of doing things.

Thank you again,
D.

[1] http://tools.ietf.org/html/rfc2617

On 28/05/14 03:05, Dmitry Janushkevich wrote:
> Thierry, Zane,
>
> Thank you for clarification. Your responses are highly appreciated.
>
>> in fact nobody should be publicly exposing their templates just so
> Heat can get at them.
>
> Apparently, some people do. In your opinion, what could be the cause of
> this? Is there something that can be done to improve the situation
> before the advent of the next Heat API version?
>
Templates can be authored so that secrets are passed in as parameters,
or generated during stack creation. So some subset of templates could be
publicly exposed.

heatclient will always resolve URLs so removing this from the Heat API
shouldn't affect anyone.

It sounds like the solution you're looking for will be the ability to
launch templates stored in the glance artifact repository, which is
being worked on by glance developers during the Juno cycle.

We compare cheap flights, hotels & car hire of more providers ; Save with us !!
cheapesthotel-flightcompare.com