Open Stack

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

commit 1636b3b0530f2e8422997fff810188e4676de511
Author: Steven Hardy <shardy at redhat.com>
Date:   Wed Jan 13 10:34:18 2016 +0000

    Handle invalid stack names which are non-string
    
    If we get passed a non-string stack name, e.g a map or list, we
    fail with a DB error associated with looking up the existing stack.
    
    So instead force all stack lookups to use string identifiers, and
    make the name validation for new stacks robust to fail gracefully
    when there is an invalid (non string) argument passed.
    
    Change-Id: I052dc4a715773895d070e1e9f26183c6a1cf3d7f
    Closes-Bug: #1533065


** Changed in: heat
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1533065

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" > /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1533065/+subscriptions