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

Bug #1256049 reported by Steven Hardy on 2013-11-28
270
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Security Advisory
High
Jeremy Stanley
heat
High
Unassigned
Grizzly
High
Steven Hardy
Havana
High
Unassigned

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

Steven Hardy (shardy) wrote :
Changed in heat:
assignee: nobody → Steven Hardy (shardy)
importance: Undecided → High
status: New → Triaged
milestone: none → icehouse-1
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
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.

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.

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
Steven Hardy (shardy) wrote :

Updated fix for master fixing two flake8 issues

Steven Hardy (shardy) wrote :

Backported fix for Havana

Steven Hardy (shardy) wrote :

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

Steven Hardy (shardy) wrote :
Steven Hardy (shardy) wrote :
Changed in heat:
status: Triaged → In Progress
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.

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

Zane Bitter (zaneb) wrote :

Yeah, exactly.

Kurt Seifried (kseifried) wrote :

Does this issue need a CVE?

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.

Steve Baker (steve-stevebaker) wrote :

+2 on the master/havana/grizzly v3 patches

Jeremy Stanley (fungi) on 2013-12-03
Changed in ossa:
assignee: nobody → Jeremy Stanley (fungi)
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
Steven Hardy (shardy) wrote :

Impact description looks good to me, +2

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

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

Same reason as bug 1256983, same punition

Changed in heat:
milestone: icehouse-1 → icehouse-2
Jeremy Stanley (fungi) on 2013-12-05
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) on 2013-12-06
Changed in ossa:
status: In Progress → Fix Committed

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) on 2013-12-11
information type: Private Security → Public Security

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

Changed in heat:
assignee: Steven Hardy (shardy) → Jeremy Stanley (fungi)
Jeremy Stanley (fungi) on 2013-12-11
Changed in heat:
assignee: Jeremy Stanley (fungi) → nobody
Jeremy Stanley (fungi) on 2013-12-11
summary: - Heat CFN policy rules not all enforced (CVE-2013-6426)
+ [OSSA 2013-034] Heat CFN policy rules not all enforced (CVE-2013-6426)

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

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) on 2013-12-14
Changed in ossa:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-01-22
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-04-17
Changed in heat:
milestone: icehouse-2 → 2014.1
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers