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
>