quota project_id not validated

[Divya K Konoor]

The primary problem here is that the quota update and show REST apis do not do any input validation for the project_id that gets passed in due to which the following can be done:

1. quota can be updated against any junk value, which subsequently gets updated into the quotas able. For eg.

PUT /v2.1/tenant-id/os-quota-sets/auctionweaver.pl

{
    "quota_set": {
"ram": 5000
        }
}

Response :

{
    "quota_set": {
        "injected_file_content_bytes": 10240,
        "metadata_items": 128,
        "server_group_members": 100,
        "server_groups": 25,
        "ram": 5000,
        "floating_ips": 10,
        "key_pairs": 100,
        "instances": 100,
        "security_group_rules": 20,
        "injected_files": 5,
        "cores": 550,
        "fixed_ips": -1,
        "injected_file_path_bytes": 255,
        "security_groups": 10
    }
}

The DB table for quotas has the below data which is incorrect. This shows that there is no input validation done .

MariaDB [nova]> select * from quotas;
+----+---------------------+---------------------+------------+----------------------------------+----------------------+------------+---------+
| id | created_at | updated_at | deleted_at | project_id | resource | hard_limit | deleted |
+----+---------------------+---------------------+------------+----------------------------------+----------------------+------------+---------+
| 1 | 2017-04-19 07:46:12 | 2017-04-19 11:13:32 | NULL | auctionweaver.pl | ram | 5000 | 0 |
+----+---------------------+---------------------+------------+----------------------------------+----------------------+------------+---------+

2. I could easily replace "auctionweaver.pl" in the above example with a valid projectid for which I don't have any role assignment and it will work fine.

3. Point 2 is true not just in the case of an admin. It works for all roles without prejudice.

4. There's absolutely no input validation that's done for the project_id passed in. After updating junk values into the table, I can retrieve those values as well:

I was able to list the nova quotas using the below invalid URL.Please note the "id" attribute in the response.

GET /v2.1/tenant-id/os-quota-sets/sfkhdskfjhd

{
    "quota_set": {
        "injected_file_content_bytes": 10240,
        "metadata_items": 128,
        "server_group_members": 100,
        "server_groups": 25,
        "ram": 4096,
        "floating_ips": 10,
        "key_pairs": 100,
        "id": "sfkhdskfjhd",
        "instances": 100,
        "security_group_rules": 20,
        "injected_files": 5,
        "cores": 100,
        "fixed_ips": -1,
        "injected_file_path_bytes": 255,
        "security_groups": 10
    }
}

5. It should be technically possible for someone to try out sql injections using this api. Some user with non-admin privileges for a particular project might be able to view or update quota values for the other projects using the above mechanism.

6. This behavior is the same for cinder apis as well.

[Matt Riedemann (mriedem)]

This is a super old public bug at this point, lots of duplicates:

https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/validate-project-with-keystone.html

And the quota API has been fixed in Pike:

https://review.openstack.org/#/c/435010/

I don't think this is considered a security bug as it's so widely known already, see the bugs associated with the blueprint in launchpad:

https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone

[Jeremy Stanley (fungi)]

Given this is a long-standing public issue, I'll triage this as won't fix for the advisory and we can mark it in public as a proper duplicate report. Once this report is public, we can of course continue to discuss whether it warrants an advisory and backports to stable branches and if there's a compelling argument for them then we can reverse the ossa bug task state at that point.

[Divya K Konoor (dikonoor)]

Jeremy /Matt,

I think this should be back ported to stable branches. https://review.openstack.org/#/c/435010/ is merged now.