scheduler hints are unbounded and never deleted

For reference, here is the nova API subteam meeting log where this came up:

http://eavesdrop.openstack.org/meetings/nova_api/2017/nova_api.2017-03-15-13.00.log.html

If I know that scheduler hints are stored in the request_specs.specs table and the size on that column is 65,535, then I could reasonably do something like:

hints = {}
for x in xrange(64000):
    hints[str(x)] = str(x)

And then use those hints for the os:scheduler_hints field in the server create request body.

To start, we can almost certainly switch this report to Public Security and skip the embargo since the potential risk is already mentioned in the meeting log (and even called out as a possible security vulnerability). There doesn't seem to be much novel in this report which an interested attacker couldn't easily work out from the public discussion and a quick skim through the source code.

As for whether we issue an advisory, I think this will mostly boil down to whether there's a safe way to "fix" it in supported stable branches, or if this will need to be paired with some configuration to actually tune and enable the mitigation.

The fixes would be:

1. Change the scheduler_hints json schema request validation to limit the length on key/value pairs. Changing the API like that is backward incompatible and generally requires a microversion, which we wouldn't backport to stable branches.

2. To limit the number of hints per server create request, we could introduce a new qouta limit configuration option. This would implicitly change the behavior of the API, so might be in the same boat as #1 for backports.

--

So given we can't really backport at least a microversion bump, then there is probably no reason to issue an advisory for this.

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

I've added an OSSN task so the security note editors can decide if this is one they want to cover with some sort of warning for stable branches.

So if a backport is not possible, what would the full mitigation steps be for ocata and previous?

additionalProperties=False

@lhinds, no you can't set additionalProperties=False in the jsonschema because that changes the API in a backward incompatible way without a microversion, so it could break deployments/users.

Thanks Matt, so would I be right in saying there is no mitigation / recommended actions? For an OSSN we need to outline the problem, and more importantly provide recommended actions to take?

From what I can see, this is an issue that can only be addressed with code changes?

Its looking like this cannot be resolved with an OSSN. I will give this another week, and unless shown otherwise will mark it as wont' fix only under OpenStack Security Notes.

Looks to me like like B1 + OSSA (public) is the most appropriate path?

OSSA are specific to issues fixed in supported stable branches. If they can only be fixed in master (and so future major releases), we don't issue advisories because there is no fix for operators to apply.

Older related ML thread:

http://lists.openstack.org/pipermail/openstack-dev/2015-June/067996.html