Comment 7 for bug 1562175

Thanks Janie, if it becomes an upstream patch I'm sure we can fix your nit
;)

On Fri, May 6, 2016 at 2:55 PM, Janie Richling <email address hidden> wrote:

> Using Matt's patch, I tested unittests, functests, probetests, and tested
> the case manually and saw that the version was no longer created on disk
> from the unauthorized user.
> I used the same script that revealed the issue before to show that the
> issue has now been resolved.
> nit: s/becuase/because/ in test_versioned_writes.py changes.
>
> --
> You received this bug notification because you are a member of Swift
> Core security contacts, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1562175
>
> Title:
> Pre-auth COPY in versioned_writes can result in a successful COPY that
> wouldn't have been authorized
>
> Status in OpenStack Security Advisory:
> Incomplete
> Status in OpenStack Object Storage (swift):
> Confirmed
>
> Bug 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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ossa/+bug/1562175/+subscriptions
>