Thanks for the info.

Yes, i know there's some other stuff to complete. But I wanted to understand what happens. I'd prefer that (once the other things have happened) we let the affected parties know, then release a couple of weeks after that so they can have time to patch.

I'm working on the other parts now.


> On Mar 12, 2015, at 11:28 AM, Tristan Cacqueray <email address hidden> wrote:
> 
> John, for bugs under embargo, we do notify stakeholders before
> disclosure, it's part of the vulnerability management process. Though
> there is no mailing list, it's a simple recipient list maintained by the
> VMT.
> 
> However for this bug we still need:
> * patch (for master and impacted stable branchs) to be reviewed and approved
> * impact description to be approved
> * CVE (to be requested with the approved impact description)
> 
> Then we can move on to choosing a proper disclosure date and send the
> advance notification.
> 
> --
> You received this bug notification because you are subscribed to
> OpenStack Object Storage (swift).
> https://bugs.launchpad.net/bugs/1430645
> 
> Title:
>  unauthorized delete from container with x-version-location
> 
> Status in OpenStack Security Advisories:
>  Confirmed
> 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 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.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ossa/+bug/1430645/+subscriptions