| 2016-02-12 17:42:12 |
Brian Rosmaita |
bug |
|
|
added bug |
| 2016-02-12 17:51:54 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2016-02-12 17:52:46 |
Tristan Cacqueray |
description |
This report applies to all versions of Glance.
The POST v2/images call creates an image (record) in 'queued' status. There is no limit enforced in glance on the number of images a single tenant may create, just on the total amount of storage a single user may consume [0]. Thus a user could either maliciously or by mistake clog up multiple database tables (images, image_properties, image_tags, image_members) with useless image records, thereby causing a denial of service.
This is a concern because the approved 2016.0 DefCore specification requires the 'images-v2-index' capability [1, 2]. The tempest test for this capability functions by creating several image records and then checking the GET v2/images response to make sure all these records are returned [3]. Thus any cloud that wishes to qualify under 2016.01 must expose POST v2/images to all end users, thereby exposing such clouds to this vulnerability, which could otherwise be mitigated by restricting POST v2/images to trusted users.
[0] https://github.com/openstack/glance/blob/132906146dd74a2eeae67706e19e4fa44559bb8b/etc/glance-api.conf#L89
[1] https://github.com/openstack/defcore/blob/master/2016.01.json#L48
[2] https://github.com/openstack/defcore/blob/master/2016.01.json#L1391-L1412
[3] https://github.com/openstack/tempest/blob/df88737b9cdaabb5633b4fefb723676e71cd1af0/tempest/api/image/v2/test_images.py#L184-L191 |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
This report applies to all versions of Glance.
The POST v2/images call creates an image (record) in 'queued' status. There is no limit enforced in glance on the number of images a single tenant may create, just on the total amount of storage a single user may consume [0]. Thus a user could either maliciously or by mistake clog up multiple database tables (images, image_properties, image_tags, image_members) with useless image records, thereby causing a denial of service.
This is a concern because the approved 2016.0 DefCore specification requires the 'images-v2-index' capability [1, 2]. The tempest test for this capability functions by creating several image records and then checking the GET v2/images response to make sure all these records are returned [3]. Thus any cloud that wishes to qualify under 2016.01 must expose POST v2/images to all end users, thereby exposing such clouds to this vulnerability, which could otherwise be mitigated by restricting POST v2/images to trusted users.
[0] https://github.com/openstack/glance/blob/132906146dd74a2eeae67706e19e4fa44559bb8b/etc/glance-api.conf#L89
[1] https://github.com/openstack/defcore/blob/master/2016.01.json#L48
[2] https://github.com/openstack/defcore/blob/master/2016.01.json#L1391-L1412
[3] https://github.com/openstack/tempest/blob/df88737b9cdaabb5633b4fefb723676e71cd1af0/tempest/api/image/v2/test_images.py#L184-L191 |
|
| 2016-02-12 17:52:56 |
Tristan Cacqueray |
bug |
|
|
added subscriber Glance Core security contacts |
| 2016-02-12 19:22:23 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2016-02-13 19:07:39 |
Nikhil Komawar |
glance: status |
New |
Confirmed |
|
| 2016-02-29 20:55:47 |
Tristan Cacqueray |
bug |
|
|
added subscriber OSSG CoreSec |
| 2016-05-16 16:31:13 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Opinion |
|
| 2016-09-01 17:51:35 |
Travis McPeak |
bug task added |
|
ossn |
|
| 2016-09-08 21:08:14 |
Luke Hinds |
ossn: assignee |
|
Luke Hinds (lhinds) |
|
| 2016-10-20 23:43:58 |
Jeremy Stanley |
cve linked |
|
2016-8611 |
|
| 2016-10-27 21:40:32 |
Luke Hinds |
ossn: status |
New |
Fix Released |
|
| 2016-10-27 21:41:52 |
Luke Hinds |
information type |
Private Security |
Public |
|
| 2016-10-28 19:04:49 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
This report applies to all versions of Glance.
The POST v2/images call creates an image (record) in 'queued' status. There is no limit enforced in glance on the number of images a single tenant may create, just on the total amount of storage a single user may consume [0]. Thus a user could either maliciously or by mistake clog up multiple database tables (images, image_properties, image_tags, image_members) with useless image records, thereby causing a denial of service.
This is a concern because the approved 2016.0 DefCore specification requires the 'images-v2-index' capability [1, 2]. The tempest test for this capability functions by creating several image records and then checking the GET v2/images response to make sure all these records are returned [3]. Thus any cloud that wishes to qualify under 2016.01 must expose POST v2/images to all end users, thereby exposing such clouds to this vulnerability, which could otherwise be mitigated by restricting POST v2/images to trusted users.
[0] https://github.com/openstack/glance/blob/132906146dd74a2eeae67706e19e4fa44559bb8b/etc/glance-api.conf#L89
[1] https://github.com/openstack/defcore/blob/master/2016.01.json#L48
[2] https://github.com/openstack/defcore/blob/master/2016.01.json#L1391-L1412
[3] https://github.com/openstack/tempest/blob/df88737b9cdaabb5633b4fefb723676e71cd1af0/tempest/api/image/v2/test_images.py#L184-L191 |
This report applies to all versions of Glance.
The POST v2/images call creates an image (record) in 'queued' status. There is no limit enforced in glance on the number of images a single tenant may create, just on the total amount of storage a single user may consume [0]. Thus a user could either maliciously or by mistake clog up multiple database tables (images, image_properties, image_tags, image_members) with useless image records, thereby causing a denial of service.
This is a concern because the approved 2016.0 DefCore specification requires the 'images-v2-index' capability [1, 2]. The tempest test for this capability functions by creating several image records and then checking the GET v2/images response to make sure all these records are returned [3]. Thus any cloud that wishes to qualify under 2016.01 must expose POST v2/images to all end users, thereby exposing such clouds to this vulnerability, which could otherwise be mitigated by restricting POST v2/images to trusted users.
[0] https://github.com/openstack/glance/blob/132906146dd74a2eeae67706e19e4fa44559bb8b/etc/glance-api.conf#L89
[1] https://github.com/openstack/defcore/blob/master/2016.01.json#L48
[2] https://github.com/openstack/defcore/blob/master/2016.01.json#L1391-L1412
[3] https://github.com/openstack/tempest/blob/df88737b9cdaabb5633b4fefb723676e71cd1af0/tempest/api/image/v2/test_images.py#L184-L191 |
|
| 2021-02-02 16:33:33 |
Erno Kuvaja |
glance: status |
Confirmed |
Opinion |
|
