Open Stack

Based on the discussion above, this sounds like class C1 (not considered
a practical vulnerability https://security.openstack.org/vmt-
process.html#incident-report-taxonomy ) so I'm switching the security
advisory task to Won't Fix and triaging this in public as a hardening
opportunity. If new details emerge, this decision can be revisited.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

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