Open Stack

Given comment #4 and the public nature of the issue, I'm going to go
ahead and triage this report as Class B1 (A vulnerability that can only
be fixed in master, security note for stable branches, e.g., default
config value is insecure): https://security.openstack.org/vmt-
process.html#incident-report-taxonomy

** Also affects: ossa
   Importance: Undecided
       Status: New

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

** Information type changed from Private Security to Public

** Also affects: ossn
   Importance: Undecided
       Status: New

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

Title:
  scheduler hints are unbounded and never deleted

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  I'm initially reporting this as a potential security issue but it
  might not be, I'm just looking for feedback from the VMT.

  The scheduler_hints in the compute API are stored in the
  request_specs.spec column in the nova_api database:

  https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171

  There is no limit on the size of the keys or values, or number of
  hints, in the API:

  https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18

  There are some pre-defined hints, but additionalProperties=True in the
  json schema means that one can provide any hints they want.

  So I could boot a server with a scheduler_hints dict that has a
  million keys which are a million characters long. At best that just
  results in a 500 because the column size limit in the database rejects
  the json blob size. According to the mysql 5.7 docs:

  https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html

  "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name]

  A TEXT column with a maximum length of 65,535 (216 − 1) characters.
  The effective maximum length is less if the value contains multibyte
  characters. Each TEXT value is stored using a 2-byte length prefix
  that indicates the number of bytes in the value."

  At worst, I'm able to work backward from a million until I found out
  the limit at which I can fill the request_specs.spec column and then
  just hammer the compute API, filling up the nova_api database.

  So there are two issues:

  1. No key/value size limit in the API json schema for scheduler hints.

  2. No quota limit on the number of hints one can provide (unlike quota
  limits on user-provided metadata key/value pairs which are limited to
  255 for the key/value and 128 for the quota).

  Add to this the fact that we never delete request_specs entries from
  the nova_api database automatically (that's being worked on here:
  https://review.openstack.org/#/c/391060/ ).

  This might not be a security issue, it might just be poor API design
  and we can tighten things up to avoid a 500 error with quota limits
  and json schema validation on the key/value size on each hint, and
  also delete request specs when we delete an instance.

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