Reviewed:  https://review.openstack.org/217255
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=f81435d340140a0b54ac555870423894ee9b2131
Submitter: Jenkins
Branch:    stable/kilo

commit f81435d340140a0b54ac555870423894ee9b2131
Author: Samuel Merritt <email address hidden>
Date:   Tue Aug 11 09:10:13 2015 -0500

    Better scoping for tempurls, especially container tempurls
    
    It used to be that a GET of a tempurl referencing a large object would
    let you download that large object regardless of where its segments
    lived. However, this led to some violated user expectations around
    container tempurls.
    
    (Note on shorthand: all tempurls reference objects. However, "account
    tempurl" and "container tempurl" are shorthand meaning tempurls
    generated using a key on the account or container, respectively.)
    
    Let's say an application is given tempurl keys to a particular
    container, and it does all its work therein using those keys. The user
    expects that, if the application is compromised, then the attacker
    only gains access to the "compromised-container". However, with the old
    behavior, the attacker could read data from *any* container like so:
    
    1) Choose a "victim-container" to download
    
    2) Create PUT and GET tempurl for any object name within the
       "compromised-container". The object doesn't need to exist;
       we'll create it.
    
    3) Using the PUT tempurl, upload a DLO manifest with
       "X-Object-Manifest: /victim-container/"
    
    4) Using the GET tempurl, download the object created in step 3. The
       result will be the concatenation of all objects in the
       "victim-container".
    
    Step 3 need not be for all objects in the "victim-container"; for
    example, a value "X-Object-Manifest: /victim-container/abc" would only
    be the concatenation of all objects whose names begin with "abc". By
    probing for object names in this way, individual objects may be found
    and extracted.
    
    A similar bug would exist for manifests referencing other accounts
    except that neither the X-Object-Manifest (DLO) nor the JSON manifest
    document (SLO) have a way of specifying a different account.
    
    This change makes it so that a container tempurl only grants access to
    objects within its container, *including* large-object segments. This
    breaks backward compatibility for container tempurls that may have
    pointed to cross container *LO's, but (a) there are security
    implications, and (b) container tempurls are a relatively new feature.
    
    This works by having the tempurl middleware install an authorization
    callback ('swift.authorize' in the WSGI environment) that limits the
    scope of any requests to the account or container from which the key
    came.
    
    This requires swift.authorize to persist for both the manifest request
    and all segment requests; this is done by having the proxy server
    restore it to the WSGI environment prior to returning from __call__.
    
    [CVE-2015-5223]
    
    Co-Authored-By: Clay Gerrard <email address hidden>
    Co-Authored-By: Alistair Coles <email address hidden>
    Co-Authored-By: Christian Schwede <email address hidden>
    Co-Authored-By: Matthew Oliver <email address hidden>
    
    Closes-Bug: 1449212
    
    Change-Id: I11078af178cb9acdd9039388282fcd0db165ba7a