Updating any neutron quota for non-existent project works

[Abhishek Sharma M]

When we try to update a neutron 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 neutron is made.

 PUT network/v2.0/quotas/<non-existent proj-id>

Looks like project validation check is missing in the neutron 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.

[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.

[Slawek Kaplonski (slaweq)]

Hi,

Similar issue was discussed some time ago in Neutron driver team. See for example RFE https://bugs.launchpad.net/neutron/+bug/1705467 or bug https://bugs.launchpad.net/mos/+bug/1782314 which is about something similar.
So this is basically known problem which we than decided to not fix as we would need to ask keystone about project ID during every API request and it could make API even slower than it is now.
But maybe we can think about some validation in keystone e.g. if project/tenant_id value in request body is different than one in context. That would probably slow down only some request made usually by admin users.

And as Jeremy already said, quota can be managed only by admin users, see https://github.com/openstack/neutron/blob/b86fa161edd1d1a9d20efbd52d922d5ba738b18d/neutron/extensions/quotasv2.py#L117 so there is no big risk in such vulnerability and I would make this bug public.

[Akihiro Motoki (amotoki)]

I agree with Slawek and Jeremy. This applies to not only neutron but also many OpenStack back-end services. The quotas API is designed for administrators and our services is not designed to protect themselves from malicious admins. As of now, I don't think we need to change what we discussed in the neutron drivers team now considering this bug report. +1 to make this public.

[Jeremy Stanley (fungi)]

Thanks for the feedback everyone, I've switched this to a regular public bug and set the security advisory task to won't fix, treating it as a class D report (hardening opportunity) per the OpenStack VMT's report taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy