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 Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp