forked from openstack/swift
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 protected]> Co-Authored-By: Alistair Coles <[email protected]> Co-Authored-By: Christian Schwede <[email protected]> Co-Authored-By: Matthew Oliver <[email protected]> Change-Id: Ie6d52f7a07e87f6fec21ed8b0ec1d84be8b2b11c Closes-Bug: 1449212
- Loading branch information
Showing
4 changed files
with
333 additions
and
68 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.