2015-12-03 18:08:37 |
Niall Bunting |
bug |
|
|
added bug |
2015-12-03 18:20:16 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
2015-12-03 18:20:43 |
Tristan Cacqueray |
description |
Overview:
This may be a bit cautious to submit as private security however its easy to go from private to public, but harder to do it the other way around.
In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering.
However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image.
What should happen: 403 What does happen: 200
How to reproduce:
1. Create an image.
echo test | glance image-create --name 3 --container-format bare --disk-format raw
2. Deactivate the image.
glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a
3. Check image is deactivated.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a
4. Using the v1 API delete the image.
curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913'
5. Image is now gone.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a |
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.
--
Overview:
This may be a bit cautious to submit as private security however its easy to go from private to public, but harder to do it the other way around.
In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering.
However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image.
What should happen: 403 What does happen: 200
How to reproduce:
1. Create an image.
echo test | glance image-create --name 3 --container-format bare --disk-format raw
2. Deactivate the image.
glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a
3. Check image is deactivated.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a
4. Using the v1 API delete the image.
curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913'
5. Image is now gone.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a |
|
2015-12-03 18:22:56 |
Tristan Cacqueray |
bug |
|
|
added subscriber Glance Core security contacts |
2015-12-04 11:48:43 |
Stuart McLaren |
glance: status |
New |
Confirmed |
|
2015-12-04 11:57:31 |
Niall Bunting |
glance: assignee |
|
Niall Bunting (niall-bunting) |
|
2015-12-04 17:29:20 |
Niall Bunting |
attachment added |
|
deactivated-image-delete.patch https://bugs.launchpad.net/glance/+bug/1522524/+attachment/4529687/+files/deactivated-image-delete.patch |
|
2015-12-07 14:21:25 |
Niall Bunting |
attachment added |
|
deactivated-image-delete.patch https://bugs.launchpad.net/glance/+bug/1522524/+attachment/4530956/+files/deactivated-image-delete.patch |
|
2015-12-07 19:44:25 |
Grant Murphy |
ossa: status |
New |
Confirmed |
|
2015-12-11 11:55:01 |
Stuart McLaren |
information type |
Private Security |
Public Security |
|
2015-12-11 11:56:06 |
Stuart McLaren |
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.
--
Overview:
This may be a bit cautious to submit as private security however its easy to go from private to public, but harder to do it the other way around.
In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering.
However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image.
What should happen: 403 What does happen: 200
How to reproduce:
1. Create an image.
echo test | glance image-create --name 3 --container-format bare --disk-format raw
2. Deactivate the image.
glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a
3. Check image is deactivated.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a
4. Using the v1 API delete the image.
curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913'
5. Image is now gone.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a |
Overview:
In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering.
However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image.
What should happen: 403 What does happen: 200
How to reproduce:
1. Create an image.
echo test | glance image-create --name 3 --container-format bare --disk-format raw
2. Deactivate the image.
glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a
3. Check image is deactivated.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a
4. Using the v1 API delete the image.
curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913'
5. Image is now gone.
glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a |
|
2015-12-11 11:56:30 |
Stuart McLaren |
bug |
|
|
added subscriber Brian Rosmaita |
2015-12-11 11:58:16 |
OpenStack Infra |
glance: status |
Confirmed |
In Progress |
|
2015-12-15 16:09:50 |
Tristan Cacqueray |
ossa: status |
Confirmed |
Won't Fix |
|
2016-03-31 15:25:27 |
Niall Bunting |
glance: importance |
Undecided |
Wishlist |
|