| 2016-03-25 21:52:49 |
Janie Richling |
bug |
|
|
added bug |
| 2016-03-25 21:54:27 |
Janie Richling |
bug |
|
|
added subscriber Michael Factor |
| 2016-04-19 20:13:52 |
Tim Burke |
swift: status |
New |
Confirmed |
|
| 2016-04-20 21:03:11 |
Jeremy Stanley |
description |
There is a potential security issue in the versioning feature of swift (found in the latest on master - 2.6/2.7.0). Exploiting the vulnerability would not damage the cluster, but can have some undesirable behavior.
Scenario 1:
A user can cause an existing object in another account to be copied - when that user is not authorized for that account.
- user1 has access to tenant1
- user2 does not have access to tenant1
- user1 creates a versioned container ("versioned_container")
- user1 creates a container for those versions to be stored ("versions")
- user1 PUTs an object version in "versioned_container" called myobject with content "a"
- user2 PUTs an object version in "versioned_container" called myobject with content "b"
- the "pre-authed" copy of content "a" to the "versions" container succeeds
- the last PUT fails with Forbidden. (content "b" is not saved)
- So, the end state is that user2 caused the latest myobject version to be copied to "versions",
which user2 should not have access to.
(Exploiting this, user2 can drive up the usage of User1 impacting consumption against the quota and billing costs)
- user2 PUTs an object version in "versioned_container" called myobject with content "c"
- same thing as the last PUT attempt, but the timestamp in the filename of myobject in the "versions" container.
(X-Timestamp is same in old obj listing - but when/if swift restores a version, the filename timestamp is used as X-Timestamp)
- No new data is created here. The old object still has content "a".
Scenario 2:
Another flow involving the same issue which results in user1 getting unexpected results.
In this scenario, when user1 attempts to revert to a prior version of an object, it will not be that version.
Note there is a work-around, but the user must be very aware of the issue to detect what had happened.
- user1 PUTs myobject with content "a"
- user1 PUTs myobject with content "b", this moves content "a" to the versions container
- user2 PUTs myobject this moves content "b" to the versions container
- user1 DELETEs myobject; this moves content "b" to the versioned_container but User1 expects the content to be "a"
(Work-around: DELETE twice - then the original "a" would be in place - Note it was not lost.)
So in summary, the bug is that a user can cause bytes to go into the container were old versions are stored when this user does not have access to the associated account. Note that the user still cannot write to the formal location of this versioned object, and the user cannot influence the contents of the objects. There is also no way to write more bytes than the size of ONE copy of an authorized object. Note that the original object will always be preserved - and this does not allow an authorized user to remove any versions.
Suggestion on how this can be fixed:
Change to perform some authorization before the copy to old versions is made inside of _put_versioned_obj instead of the pre-authed request that is currently made. There is a comment in the code saying the pre_auth request is made in case the user has write access to the container, but not READ. It says this was allowed before middleware was in place. In this particular scenario, the user doesn't even have write access. |
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.
There is a potential security issue in the versioning feature of swift (found in the latest on master - 2.6/2.7.0). Exploiting the vulnerability would not damage the cluster, but can have some undesirable behavior.
Scenario 1:
A user can cause an existing object in another account to be copied - when that user is not authorized for that account.
- user1 has access to tenant1
- user2 does not have access to tenant1
- user1 creates a versioned container ("versioned_container")
- user1 creates a container for those versions to be stored ("versions")
- user1 PUTs an object version in "versioned_container" called myobject with content "a"
- user2 PUTs an object version in "versioned_container" called myobject with content "b"
- the "pre-authed" copy of content "a" to the "versions" container succeeds
- the last PUT fails with Forbidden. (content "b" is not saved)
- So, the end state is that user2 caused the latest myobject version to be copied to "versions",
which user2 should not have access to.
(Exploiting this, user2 can drive up the usage of User1 impacting consumption against the quota and billing costs)
- user2 PUTs an object version in "versioned_container" called myobject with content "c"
- same thing as the last PUT attempt, but the timestamp in the filename of myobject in the "versions" container.
(X-Timestamp is same in old obj listing - but when/if swift restores a version, the filename timestamp is used as X-Timestamp)
- No new data is created here. The old object still has content "a".
Scenario 2:
Another flow involving the same issue which results in user1 getting unexpected results.
In this scenario, when user1 attempts to revert to a prior version of an object, it will not be that version.
Note there is a work-around, but the user must be very aware of the issue to detect what had happened.
- user1 PUTs myobject with content "a"
- user1 PUTs myobject with content "b", this moves content "a" to the versions container
- user2 PUTs myobject this moves content "b" to the versions container
- user1 DELETEs myobject; this moves content "b" to the versioned_container but User1 expects the content to be "a"
(Work-around: DELETE twice - then the original "a" would be in place - Note it was not lost.)
So in summary, the bug is that a user can cause bytes to go into the container were old versions are stored when this user does not have access to the associated account. Note that the user still cannot write to the formal location of this versioned object, and the user cannot influence the contents of the objects. There is also no way to write more bytes than the size of ONE copy of an authorized object. Note that the original object will always be preserved - and this does not allow an authorized user to remove any versions.
Suggestion on how this can be fixed:
Change to perform some authorization before the copy to old versions is made inside of _put_versioned_obj instead of the pre-authed request that is currently made. There is a comment in the code saying the pre_auth request is made in case the user has write access to the container, but not READ. It says this was allowed before middleware was in place. In this particular scenario, the user doesn't even have write access. |
|
| 2016-04-20 21:03:21 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2016-04-20 21:03:29 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2016-04-20 21:04:12 |
Jeremy Stanley |
bug |
|
|
added subscriber Swift Core security contacts |
| 2016-05-04 01:11:01 |
Matthew Oliver |
attachment added |
|
pre_authed_versions_rights_put_fix.patch https://bugs.launchpad.net/swift/+bug/1562175/+attachment/4654902/+files/pre_authed_versions_rights_put_fix.patch |
|
| 2016-05-04 01:24:20 |
Tim Burke |
attachment added |
|
bug-1562175.patch https://bugs.launchpad.net/swift/+bug/1562175/+attachment/4654906/+files/bug-1562175.patch |
|
| 2016-07-11 16:16:08 |
Jeremy Stanley |
bug |
|
|
added subscriber OSSG CoreSec |
| 2016-07-23 21:54:36 |
Janie Richling |
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.
There is a potential security issue in the versioning feature of swift (found in the latest on master - 2.6/2.7.0). Exploiting the vulnerability would not damage the cluster, but can have some undesirable behavior.
Scenario 1:
A user can cause an existing object in another account to be copied - when that user is not authorized for that account.
- user1 has access to tenant1
- user2 does not have access to tenant1
- user1 creates a versioned container ("versioned_container")
- user1 creates a container for those versions to be stored ("versions")
- user1 PUTs an object version in "versioned_container" called myobject with content "a"
- user2 PUTs an object version in "versioned_container" called myobject with content "b"
- the "pre-authed" copy of content "a" to the "versions" container succeeds
- the last PUT fails with Forbidden. (content "b" is not saved)
- So, the end state is that user2 caused the latest myobject version to be copied to "versions",
which user2 should not have access to.
(Exploiting this, user2 can drive up the usage of User1 impacting consumption against the quota and billing costs)
- user2 PUTs an object version in "versioned_container" called myobject with content "c"
- same thing as the last PUT attempt, but the timestamp in the filename of myobject in the "versions" container.
(X-Timestamp is same in old obj listing - but when/if swift restores a version, the filename timestamp is used as X-Timestamp)
- No new data is created here. The old object still has content "a".
Scenario 2:
Another flow involving the same issue which results in user1 getting unexpected results.
In this scenario, when user1 attempts to revert to a prior version of an object, it will not be that version.
Note there is a work-around, but the user must be very aware of the issue to detect what had happened.
- user1 PUTs myobject with content "a"
- user1 PUTs myobject with content "b", this moves content "a" to the versions container
- user2 PUTs myobject this moves content "b" to the versions container
- user1 DELETEs myobject; this moves content "b" to the versioned_container but User1 expects the content to be "a"
(Work-around: DELETE twice - then the original "a" would be in place - Note it was not lost.)
So in summary, the bug is that a user can cause bytes to go into the container were old versions are stored when this user does not have access to the associated account. Note that the user still cannot write to the formal location of this versioned object, and the user cannot influence the contents of the objects. There is also no way to write more bytes than the size of ONE copy of an authorized object. Note that the original object will always be preserved - and this does not allow an authorized user to remove any versions.
Suggestion on how this can be fixed:
Change to perform some authorization before the copy to old versions is made inside of _put_versioned_obj instead of the pre-authed request that is currently made. There is a comment in the code saying the pre_auth request is made in case the user has write access to the container, but not READ. It says this was allowed before middleware was in place. In this particular scenario, the user doesn't even have write access. |
There is an issue in the versioning feature of swift (found in the latest on master - 2.6/2.7.0). Exploiting the vulnerability would not damage the cluster, but can have some undesirable behavior.
Scenario 1:
A user can cause an existing object in another account to be copied - when that user is not authorized for that account.
- user1 has access to tenant1
- user2 does not have access to tenant1
- user1 creates a versioned container ("versioned_container")
- user1 creates a container for those versions to be stored ("versions")
- user1 PUTs an object version in "versioned_container" called myobject with content "a"
- user2 PUTs an object version in "versioned_container" called myobject with content "b"
- the "pre-authed" copy of content "a" to the "versions" container succeeds
- the last PUT fails with Forbidden. (content "b" is not saved)
- So, the end state is that user2 caused the latest myobject version to be copied to "versions",
which user2 should not have access to.
(Exploiting this, user2 can drive up the usage of User1 impacting consumption against the quota and billing costs)
- user2 PUTs an object version in "versioned_container" called myobject with content "c"
- same thing as the last PUT attempt, but the timestamp in the filename of myobject in the "versions" container.
(X-Timestamp is same in old obj listing - but when/if swift restores a version, the filename timestamp is used as X-Timestamp)
- No new data is created here. The old object still has content "a".
Scenario 2:
Another flow involving the same issue which results in user1 getting unexpected results.
In this scenario, when user1 attempts to revert to a prior version of an object, it will not be that version.
Note there is a work-around, but the user must be very aware of the issue to detect what had happened.
- user1 PUTs myobject with content "a"
- user1 PUTs myobject with content "b", this moves content "a" to the versions container
- user2 PUTs myobject this moves content "b" to the versions container
- user1 DELETEs myobject; this moves content "b" to the versioned_container but User1 expects the content to be "a"
(Work-around: DELETE twice - then the original "a" would be in place - Note it was not lost.)
So in summary, the bug is that a user can cause bytes to go into the container were old versions are stored when this user does not have access to the associated account. Note that the user still cannot write to the formal location of this versioned object, and the user cannot influence the contents of the objects. There is also no way to write more bytes than the size of ONE copy of an authorized object. Note that the original object will always be preserved - and this does not allow an authorized user to remove any versions.
Suggestion on how this can be fixed:
Change to perform some authorization before the copy to old versions is made inside of _put_versioned_obj instead of the pre-authed request that is currently made. There is a comment in the code saying the pre_auth request is made in case the user has write access to the container, but not READ. It says this was allowed before middleware was in place. In this particular scenario, the user doesn't even have write access. |
|
| 2016-07-23 21:59:45 |
Janie Richling |
information type |
Private Security |
Public |
|
| 2016-07-23 23:04:54 |
Jeremy Stanley |
information type |
Public |
Public Security |
|
| 2016-08-30 10:52:40 |
OpenStack Infra |
swift: status |
Confirmed |
Fix Released |
|
| 2016-08-30 20:31:03 |
OpenStack Infra |
tags |
|
in-feature-hummingbird |
|
| 2016-10-04 15:01:49 |
Jeremy Stanley |
bug task added |
|
ossn |
|
| 2016-11-03 17:19:34 |
Vincenzo Di Somma |
ossn: assignee |
|
Vincenzo Di Somma (vds) |
|
| 2016-11-10 09:41:07 |
Luke Hinds |
ossn: status |
New |
In Progress |
|
| 2016-11-16 09:36:56 |
Luke Hinds |
ossn: status |
In Progress |
Fix Committed |
|
| 2016-12-15 16:54:23 |
Luke Hinds |
ossn: status |
Fix Committed |
Fix Released |
|
| 2021-02-17 19:49:32 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
