Updating any cinder quota for non-existent project works

[Abhishek Sharma M]

When we try to update a cinder quota for a non-existent project, we get a 200ok response. The non-existent project doesn't get created, but am entry for this project in the quotas table of cinder is made.

 PUT /volume/v3/<proj-id>/os-quota-sets/<non-existent proj-id>

Looks like project validation check is missing in the cinder quota update flow.

Due to this flaw, multiple PUT calls on fake project ids might result in filling of quota tables very fast & can be considered a type of DOS attack.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Sean McGinnis (sean-mcginnis)]

This has been an issue from early on, and has not been seen as a security risk. There are other ways to make calls and fill the database if trying to use that vector as a DoS attack. Is there an actual case where the quota table has been particularly exploited?

This is a duplicate bug report of a non-security one. Since that one is not marked as a security bug, I will not mark it as a duplicate until we've agreed that this does not add any additional exploitable information.

[Jeremy Stanley (fungi)]

Thanks for the report. Generally we've considered bugs allowing abusive/malicious authenticated users to generate lots of database records as security hardening opportunities, but not practical vulnerabilities unless the impact is significantly (as in orders of magnitude) greater than the impact the same user could inflict through other allowed API calls. That aside, are unprivileged users generally allowed to set quotas? If not, then there are already plenty of ways for a malicious service administrator to cause far worse denials of service; these services aren't generally designed to protect themselves against their administrators.

[Brian Rosmaita (brian-rosmaita)]

In addition to what Sean said, by default, the command that enables this vector is admin-only. So it's possible it could be done by a disgruntled employee, or a runaway admin script, but there's way worse stuff that either of those could do. So while it may be worth looking into, I don't think it is actually a security issue.

[Jeremy Stanley (fungi)]

Thanks for the input everyone, from the OpenStack VMT's perspective we'll treat this as a class D report (security hardening opportunity) and not need an advisory. I've ended the embargo and switched the bug to public.

https://security.openstack.org/vmt-process.html#incident-report-taxonomy