| 2016-06-17 17:13:39 |
Erno Kuvaja |
bug |
|
|
added bug |
| 2016-06-17 17:56:58 |
Erno Kuvaja |
bug |
|
|
added subscriber Brian Rosmaita |
| 2016-06-17 18:14:10 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2016-06-17 18:15:00 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2016-06-17 18:15:14 |
Jeremy Stanley |
bug |
|
|
added subscriber Glance Core security contacts |
| 2016-06-17 18:16:02 |
Jeremy Stanley |
description |
Using glance-manage db purge command opens possibility to recycle image-IDs.
When the row is deleted from the database the ID is not known by glance anymore and thus it's not unique during the deployment lifecycle. This opens possibility to following scenario:
1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.
This behavior breaks Glance image immutability promise that has bee stated that the data related to image ID that has gone active will never change.
We have two solutions for this. Either we introduce table to track the deleted image-IDs and get glance to cross check that during the image create or we leave it as is but issue notice/documentation what are the implications if the purge is used transferring the responsibility to the cloud operators.
This was partially discussed in the virtual glance midcycle meetup so it might not be justified to leave this as private but I wanted to leave that decision to VMT. |
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.
Using glance-manage db purge command opens possibility to recycle image-IDs.
When the row is deleted from the database the ID is not known by glance anymore and thus it's not unique during the deployment lifecycle. This opens possibility to following scenario:
1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.
This behavior breaks Glance image immutability promise that has bee stated that the data related to image ID that has gone active will never change.
We have two solutions for this. Either we introduce table to track the deleted image-IDs and get glance to cross check that during the image create or we leave it as is but issue notice/documentation what are the implications if the purge is used transferring the responsibility to the cloud operators.
This was partially discussed in the virtual glance midcycle meetup so it might not be justified to leave this as private but I wanted to leave that decision to VMT. |
|
| 2016-06-17 20:20:53 |
Nikhil Komawar |
glance: status |
New |
Confirmed |
|
| 2016-06-17 20:20:57 |
Nikhil Komawar |
glance: importance |
Undecided |
High |
|
| 2016-06-20 16:01:34 |
Jeremy Stanley |
bug |
|
|
added subscriber OSSG CoreSec |
| 2016-06-28 15:28:57 |
Travis McPeak |
bug task added |
|
ossn |
|
| 2016-07-11 15:54:18 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Opinion |
|
| 2016-07-21 17:12:16 |
Travis McPeak |
ossn: assignee |
|
Travis McPeak (travis-mcpeak) |
|
| 2016-08-19 16:23:40 |
Travis McPeak |
ossn: status |
New |
Confirmed |
|
| 2016-08-19 16:23:58 |
Travis McPeak |
ossn: importance |
Undecided |
High |
|
| 2016-08-29 14:38:57 |
Nikhil Komawar |
glance: importance |
High |
Critical |
|
| 2016-08-31 19:50:25 |
Nikhil Komawar |
bug |
|
|
added subscriber Stuart McLaren |
| 2016-09-15 17:23:21 |
Luke Hinds |
ossn: status |
Confirmed |
Fix Released |
|
| 2016-09-15 17:40:21 |
Jeremy Stanley |
information type |
Private Security |
Public |
|
| 2016-09-15 17:40:34 |
Jeremy Stanley |
tags |
|
security |
|
| 2016-09-16 01:37:54 |
Tristan Cacqueray |
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.
Using glance-manage db purge command opens possibility to recycle image-IDs.
When the row is deleted from the database the ID is not known by glance anymore and thus it's not unique during the deployment lifecycle. This opens possibility to following scenario:
1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.
This behavior breaks Glance image immutability promise that has bee stated that the data related to image ID that has gone active will never change.
We have two solutions for this. Either we introduce table to track the deleted image-IDs and get glance to cross check that during the image create or we leave it as is but issue notice/documentation what are the implications if the purge is used transferring the responsibility to the cloud operators.
This was partially discussed in the virtual glance midcycle meetup so it might not be justified to leave this as private but I wanted to leave that decision to VMT. |
Using glance-manage db purge command opens possibility to recycle image-IDs.
When the row is deleted from the database the ID is not known by glance anymore and thus it's not unique during the deployment lifecycle. This opens possibility to following scenario:
1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.
This behavior breaks Glance image immutability promise that has bee stated that the data related to image ID that has gone active will never change.
We have two solutions for this. Either we introduce table to track the deleted image-IDs and get glance to cross check that during the image create or we leave it as is but issue notice/documentation what are the implications if the purge is used transferring the responsibility to the cloud operators.
This was partially discussed in the virtual glance midcycle meetup so it might not be justified to leave this as private but I wanted to leave that decision to VMT. |
|
| 2016-09-19 14:02:18 |
Darren |
bug |
|
|
added subscriber Darren |
| 2016-09-20 04:14:15 |
Dinesh Bhor |
bug |
|
|
added subscriber Dinesh Bhor |
| 2018-08-17 13:00:13 |
Brian Rosmaita |
glance: status |
Confirmed |
Fix Released |
|
