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

Bug #1256049 reported by Steven Hardy
270
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
Unassigned
Grizzly
Fix Released
High
Steven Hardy
Havana
Fix Released
High
Unassigned
OpenStack Security Advisory
Fix Released
High
Jeremy Stanley

Bug Description

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.

CVE References

Revision history for this message
Steven Hardy (shardy) wrote :
Changed in heat:
assignee: nobody → Steven Hardy (shardy)
importance: Undecided → High
status: New → Triaged
milestone: none → icehouse-1
Revision history for this message
Jeremy Stanley (fungi) wrote :

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

Changed in ossa:
status: New → Incomplete
Revision history for this message
Steve Baker (steve-stevebaker) wrote :

+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.

Revision history for this message
Steven Hardy (shardy) wrote :

@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.

Revision history for this message
Thierry Carrez (ttx) wrote :

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 :)

Changed in ossa:
importance: Undecided → High
status: Incomplete → Confirmed
Revision history for this message
Steven Hardy (shardy) wrote :

Updated fix for master fixing two flake8 issues

Revision history for this message
Steven Hardy (shardy) wrote :

Backported fix for Havana

Revision history for this message
Steven Hardy (shardy) wrote :

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

Revision history for this message
Steven Hardy (shardy) wrote :
Revision history for this message
Steven Hardy (shardy) wrote :
Changed in heat:
status: Triaged → In Progress
Revision history for this message
Zane Bitter (zaneb) wrote :

+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.

Revision history for this message
Steven Hardy (shardy) wrote :

@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 ;)

Revision history for this message
Zane Bitter (zaneb) wrote :

Yeah, exactly.

Revision history for this message
Kurt Seifried (kseifried) wrote :

Does this issue need a CVE?

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

+2 on the master/havana/grizzly v3 patches

Jeremy Stanley (fungi)
Changed in ossa:
assignee: nobody → Jeremy Stanley (fungi)
Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Changed in ossa:
status: Confirmed → Triaged
Revision history for this message
Steven Hardy (shardy) wrote :

Impact description looks good to me, +2

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

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

Changed in heat:
milestone: icehouse-1 → icehouse-2
Revision history for this message
Steven Hardy (shardy) wrote :

> 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 :(

Revision history for this message
Thierry Carrez (ttx) wrote :

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

Otherwise +2

Changed in heat:
milestone: icehouse-2 → icehouse-1
summary: - CFN policy rules not all enforced
+ Heat CFN policy rules not all enforced
Revision history for this message
Thierry Carrez (ttx) wrote : Re: Heat CFN policy rules not all enforced

Same reason as bug 1256983, same punition

Changed in heat:
milestone: icehouse-1 → icehouse-2
Jeremy Stanley (fungi)
summary: - Heat CFN policy rules not all enforced
+ Heat CFN policy rules not all enforced (CVE-2013-6426)
Changed in ossa:
status: Triaged → In Progress
Jeremy Stanley (fungi)
Changed in ossa:
status: In Progress → Fix Committed
Revision history for this message
Jeremy Stanley (fungi) wrote : Re: Heat CFN policy rules not all enforced (CVE-2013-6426)

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.

Jeremy Stanley (fungi)
information type: Private Security → Public Security
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

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

Changed in heat:
assignee: Steven Hardy (shardy) → Jeremy Stanley (fungi)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (stable/havana)

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

Jeremy Stanley (fungi)
Changed in heat:
assignee: Jeremy Stanley (fungi) → nobody
Jeremy Stanley (fungi)
summary: - Heat CFN policy rules not all enforced (CVE-2013-6426)
+ [OSSA 2013-034] Heat CFN policy rules not all enforced (CVE-2013-6426)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

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

Changed in heat:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (stable/havana)

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

Jeremy Stanley (fungi)
Changed in ossa:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: icehouse-2 → 2014.1
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers