[OSSA 2013-034] Heat CFN policy rules not all enforced (CVE-2013-6426)

[Steven Hardy]

I've discovered a problem with the way the Heat cloudformation-compatible API enforces the policy defined in policy.json.

We provide a default policy which looks like:

    "deny_stack_user": "not role:heat_stack_user",
    "cloudformation:ListStacks": "rule:deny_stack_user",
    "cloudformation:CreateStack": "rule:deny_stack_user",
    "cloudformation:DescribeStacks": "rule:deny_stack_user",
    "cloudformation:DeleteStack": "rule:deny_stack_user",
    "cloudformation:UpdateStack": "rule:deny_stack_user",
    "cloudformation:DescribeStackEvents": "rule:deny_stack_user",
    "cloudformation:ValidateTemplate": "rule:deny_stack_user",
    "cloudformation:GetTemplate": "rule:deny_stack_user",
    "cloudformation:EstimateTemplateCost": "rule:deny_stack_user",
    "cloudformation:DescribeStackResource": "",
    "cloudformation:DescribeStackResources": "rule:deny_stack_user",
    "cloudformation:ListStackResources": "rule:deny_stack_user",

The intention is that in-instance users are denied access to all API actions except DescribeStackResource, which is used by in-instance agents (e.g cfn-hup and os-collect-config I think) to poll for updated resource metadata.

The bug I've discovered means that the CreateStack and UpdateStack actions are not correctly enforcing the policy, so in theory the in-instance users might be able to create or update a stack, which they should not be allowed to do.

This affects templates using the following resources:

AWS::IAM::User, which is used when using AWS::IAM::AccessKey
AWS::CloudFormation::WaitConditionHandle,
OS::Heat::HARestarter
AWS::AutoScaling::ScalingPolicy

I have a patch with a fix and associated tests demonstrating the issue.

Note that we currently don't have any policy enforcement on the native ReST API, which I'm also looking at fixing, but this seems particularly worrisome because we aren't enforcing the policy we advertise, whereas we don't provide any rules related to the native API yet (and in instance agents don't yet expect to connect to it) so hopefully it's clear that functionality is not yet implemented.

[Jeremy Stanley (fungi)]

Does this affect Havana as well? If so we'll want a stable/havana bugtask and backport of the patch.

[Steve Baker (steve-stevebaker)]

+2 for this patch.

A couple of points to help evaluate the security implications of this:
* in-instance users are created by the use who originally created the stack
* an in-instance user can only call CreateStack and UpdateStack if the ec2 keypair for that user is known
* practically speaking, this can probably only be exploited if a stack-launched nova server is compromised, or if the heat->server communication containing the ec2 keypair is intercepted.

[Steven Hardy (shardy)]

@Jeremy Stanley: Yes, this will affect Havana and Grizzly stable branches, I'll add them as targets above.

@Steve Baker: Yep, good points, my approach has been treating instances as implicitly untrusted (since there's no way to know if they are compromised or not). If you feel this is not serious enough to warrant srt process, we can just use the normal workflow, but I wanted to discuss in a private bug before assuming that would be appropriate.

I'll provide patches for Havana and Grizzly later today.

[Thierry Carrez (ttx)]

I confirm the need for an OSSA on this. Note that the OSSA would only cover Havana since Grizzly is not security-supported (pre-integration). That doesn't prevent the fix from being produced and applied to stable/grizzly though :)

[Steven Hardy (shardy)]

Updated fix for master fixing two flake8 issues

[Steven Hardy (shardy)]

Backported fix for Havana

[Steven Hardy (shardy)]

Third and hopefully final draft of fixes for master, havana and grizzly branches.

[Zane Bitter (zaneb)]

+2 looks good to me.

It seems like there ought to be a tidier way to do the unit tests, but let's litigate that (or not) after the fix is in.

[Steven Hardy (shardy)]

@Zane: by tidier, do you mean that there's lots of repetition? If so then I agree, it can probably be reworked to use testscenarios which would reduce the repeated stuff a lot. I'll add it to my todo list ;)

[Zane Bitter (zaneb)]

Yeah, exactly.

[Kurt Seifried (kseifried)]

Does this issue need a CVE?

[Jeremy Stanley (fungi)]

Kurt: Probably. We're still looking for further consensus (one more vote) from Heat core security reviewers on the proposed fixes and need to draft an impact description summarizing this issue, but will then submit a formal request for a CVE once we have those in place.

[Steve Baker (steve-stevebaker)]

+2 on the master/havana/grizzly v3 patches

[Jeremy Stanley (fungi)]

Proposed impact description...
-----

Title: CFN policy rules not all enforced
Reporter: Steven Hardy (Red Hat)
Products: Heat
Affects: All supported releases

Description:
Steven Hardy from Red Hat reported a vulnerability in Heat's default API policy enforcement. By calling the CreateStack or UpdateStack methods, an in-instance user may be able to create or update a stack in violation of the default policy. Only setups using Heat's cloudformation-compatible API are affected.

[Steven Hardy (shardy)]

Impact description looks good to me, +2

[Steve Baker (steve-stevebaker)]

Retargeting to i-2 for now so that i-1 can be branched

[Steven Hardy (shardy)]

> Retargeting to i-2 for now so that i-1 can be branched

What can we do to progress this?

Releasing milestone builds with known serious vulnerabilities makes no sense to me :(

[Thierry Carrez (ttx)]

I would mention Heat in the title: "Heat CFN policy rules not all enforced"

Otherwise +2

[Thierry Carrez (ttx)]

Same reason as bug 1256983, same punition

[Jeremy Stanley (fungi)]

Scheduled advisory publication date is Wednesday, December 11, 2013 at 1500UTC (so as to fall before the 2013.2.1 point release). Patches will be pushed to review.openstack.org for last-minute approval shortly prior to that time.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit cfd967db3ab9806b2c8c551c5b174bd669d44a71
Author: Steven Hardy <email address hidden>
Date: Thu Nov 28 16:55:50 2013 +0000

    Fix missing policy enforcement in CFN API

    Currently the CreateStack and UpdateStack actions aren't correctly
    enforcing the policy, so add calls to _enforce which fixes that,
    and rework the test to illustrate the issue.

    Change-Id: Ia5c2e65512ab9d1c163171f8617c081ab96745e5
    Closes-Bug: #1256049

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/61454
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=944c8b13b1bc9f8ad06bb8424946e1ffe5656df0
Submitter: Jenkins
Branch: stable/havana

commit 944c8b13b1bc9f8ad06bb8424946e1ffe5656df0
Author: Steven Hardy <email address hidden>
Date: Thu Nov 28 16:55:50 2013 +0000

    Fix missing policy enforcement in CFN API

    Currently the CreateStack and UpdateStack actions aren't correctly
    enforcing the policy, so add calls to _enforce which fixes that,
    and rework the test to illustrate the issue.

    Change-Id: Ia5c2e65512ab9d1c163171f8617c081ab96745e5
    Closes-Bug: #1256049