| 2015-03-11 06:44:05 |
clayg |
bug |
|
|
added bug |
| 2015-03-11 06:44:05 |
clayg |
attachment added |
|
script to setup conditions to demonstrate the issue on swift-all-in-one https://bugs.launchpad.net/bugs/1430645/+attachment/4340822/+files/delete-the-world.sh |
|
| 2015-03-11 06:46:59 |
clayg |
attachment added |
|
call authorize more https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4340823/+files/more-version-auth.patch |
|
| 2015-03-11 08:07:48 |
Christian Schwede |
swift: status |
New |
Confirmed |
|
| 2015-03-11 08:48:21 |
clayg |
attachment added |
|
similar to the quick fix - call authorize at some point before we start making COPY requests (with unittests!) https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4340854/+files/check-authorize.patch |
|
| 2015-03-11 10:05:41 |
Christian Schwede |
attachment added |
|
acltest.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4340900/+files/acltest.patch |
|
| 2015-03-11 12:40:51 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2015-03-11 12:40:59 |
Tristan Cacqueray |
ossa: status |
New |
Confirmed |
|
| 2015-03-11 12:41:33 |
Tristan Cacqueray |
description |
The handling of object versions wrt container ACL's has been an area of interest lately and some questionable authorization behaviors have come to light:
https://etherpad.openstack.org/p/object_version_and_ACL_use_cases
Unfortunately I just discovered another one that actually seems damaging. Ability to destroy data without write access.
Any authenticated used can overwrite the most recent versions of any versioned object who's name is known in a container with the X-Versions-Location metadata field set if they have listing access to the x-versions-location container - regardless of their write authorization to the container. Basically if you can list an x-versions-location container you can overwrite all the current data in the source container (if you know it's name) with old copies even if you don't have write (or read) access to the source container.
Basically we're creating a preauthorized COPY from from the x-versions-location container (assuming the user has listing access to the x-versions-location container, and an old version exists) without checking to see if authenticated user has write access to the destination.
Script to reproduce the problem is attached.
Possible patch to follow. |
--
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 as to the bug as attachments.
--
The handling of object versions wrt container ACL's has been an area of interest lately and some questionable authorization behaviors have come to light:
https://etherpad.openstack.org/p/object_version_and_ACL_use_cases
Unfortunately I just discovered another one that actually seems damaging. Ability to destroy data without write access.
Any authenticated used can overwrite the most recent versions of any versioned object who's name is known in a container with the X-Versions-Location metadata field set if they have listing access to the x-versions-location container - regardless of their write authorization to the container. Basically if you can list an x-versions-location container you can overwrite all the current data in the source container (if you know it's name) with old copies even if you don't have write (or read) access to the source container.
Basically we're creating a preauthorized COPY from from the x-versions-location container (assuming the user has listing access to the x-versions-location container, and an old version exists) without checking to see if authenticated user has write access to the destination.
Script to reproduce the problem is attached.
Possible patch to follow. |
|
| 2015-03-11 15:43:01 |
clayg |
bug |
|
|
added subscriber Thiago da Silva |
| 2015-03-12 08:44:37 |
Christian Schwede |
attachment added |
|
acltest.patch https://bugs.launchpad.net/ossa/+bug/1430645/+attachment/4342406/+files/acltest.patch |
|
| 2015-03-16 15:23:16 |
Thierry Carrez |
ossa: importance |
Undecided |
Medium |
|
| 2015-03-17 23:43:17 |
John Dickinson |
attachment added |
|
fixver.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4348555/+files/fixver.patch |
|
| 2015-03-20 11:25:59 |
Alistair Coles |
attachment added |
|
acoles-version-attack.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4350646/+files/acoles-version-attack.patch |
|
| 2015-03-20 11:34:52 |
Alistair Coles |
attachment removed |
acoles-version-attack.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4350646/+files/acoles-version-attack.patch |
|
|
| 2015-03-20 11:35:35 |
Alistair Coles |
attachment added |
|
acoles-version-attack.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4350647/+files/acoles-version-attack.patch |
|
| 2015-03-30 14:17:17 |
Thierry Carrez |
ossa: status |
Confirmed |
Triaged |
|
| 2015-03-31 09:04:03 |
Alistair Coles |
bug |
|
|
added subscriber Donagh McCabe |
| 2015-03-31 09:23:52 |
Alistair Coles |
attachment added |
|
0001-Prevent-unauthorized-delete-in-versioned-container.patch https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4361760/+files/0001-Prevent-unauthorized-delete-in-versioned-container.patch |
|
| 2015-03-31 12:31:02 |
Alistair Coles |
bug |
|
|
added subscriber Lorcan Browne |
| 2015-03-31 12:32:00 |
Alistair Coles |
bug |
|
|
added subscriber Gerry Drudy |
| 2015-04-03 17:17:43 |
Alistair Coles |
attachment added |
|
patch for stable/juno https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4365224/+files/0001-Prevent-unauthorized-delete-in-versioned-container.patch |
|
| 2015-04-03 18:02:29 |
Alistair Coles |
attachment added |
|
patch for stable/icehouse https://bugs.launchpad.net/swift/+bug/1430645/+attachment/4365234/+files/acoles-version-attack-icehouse.patch |
|
| 2015-04-08 15:28:43 |
Tristan Cacqueray |
summary |
unauthorized delete from container with x-version-location |
unauthorized delete from container with x-version-location (CVE-2015-1856) |
|
| 2015-04-08 15:28:48 |
Tristan Cacqueray |
cve linked |
|
2015-1856 |
|
| 2015-04-08 20:43:41 |
Tristan Cacqueray |
ossa: status |
Triaged |
Fix Committed |
|
| 2015-04-14 14:59:46 |
Tristan Cacqueray |
information type |
Private Security |
Public Security |
|
| 2015-04-14 16:38:06 |
OpenStack Infra |
tags |
|
in-stable-icehouse |
|
| 2015-04-14 16:41:58 |
OpenStack Infra |
swift: status |
Confirmed |
Fix Committed |
|
| 2015-04-14 17:22:22 |
OpenStack Infra |
tags |
in-stable-icehouse |
in-stable-icehouse in-stable-juno |
|
| 2015-04-14 18:47:55 |
Tristan Cacqueray |
summary |
unauthorized delete from container with x-version-location (CVE-2015-1856) |
[OSSA 2015-006] unauthorized delete from container with x-version-location (CVE-2015-1856) |
|
| 2015-04-14 19:47:42 |
Tristan Cacqueray |
ossa: status |
Fix Committed |
Fix Released |
|
| 2015-04-14 21:16:17 |
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 as to the bug as attachments.
--
The handling of object versions wrt container ACL's has been an area of interest lately and some questionable authorization behaviors have come to light:
https://etherpad.openstack.org/p/object_version_and_ACL_use_cases
Unfortunately I just discovered another one that actually seems damaging. Ability to destroy data without write access.
Any authenticated used can overwrite the most recent versions of any versioned object who's name is known in a container with the X-Versions-Location metadata field set if they have listing access to the x-versions-location container - regardless of their write authorization to the container. Basically if you can list an x-versions-location container you can overwrite all the current data in the source container (if you know it's name) with old copies even if you don't have write (or read) access to the source container.
Basically we're creating a preauthorized COPY from from the x-versions-location container (assuming the user has listing access to the x-versions-location container, and an old version exists) without checking to see if authenticated user has write access to the destination.
Script to reproduce the problem is attached.
Possible patch to follow. |
The handling of object versions wrt container ACL's has been an area of interest lately and some questionable authorization behaviors have come to light:
https://etherpad.openstack.org/p/object_version_and_ACL_use_cases
Unfortunately I just discovered another one that actually seems damaging. Ability to destroy data without write access.
Any authenticated used can overwrite the most recent versions of any versioned object who's name is known in a container with the X-Versions-Location metadata field set if they have listing access to the x-versions-location container - regardless of their write authorization to the container. Basically if you can list an x-versions-location container you can overwrite all the current data in the source container (if you know it's name) with old copies even if you don't have write (or read) access to the source container.
Basically we're creating a preauthorized COPY from from the x-versions-location container (assuming the user has listing access to the x-versions-location container, and an old version exists) without checking to see if authenticated user has write access to the destination.
Script to reproduce the problem is attached.
Possible patch to follow. |
|
| 2015-04-15 07:39:43 |
Thierry Carrez |
swift: status |
Fix Committed |
Fix Released |
|
| 2015-04-15 07:39:43 |
Thierry Carrez |
swift: milestone |
|
2.3.0-rc1 |
|
| 2015-04-30 10:07:50 |
Thierry Carrez |
swift: milestone |
2.3.0-rc1 |
2.3.0 |
|
