Comment 0 for bug 1489749

Revision history for this message
Christian Schwede (cschwede) wrote :

Two issues were found in the staticweb middleware. They might be just "normal" bugs, but I prefer to start with a private security bug first; however the impact looks rather low to me atm.

1.staticweb middleware does not check acls
The documentation says that a read-acl setting of ".r:*" must be set, however this is never checked in staticweb. At least in combination with tempauth this allows container listings without any ACL set. Note that the staticweb middleware must still be enabled on a container, and this can only done by an account owner (because it requires a POST to the container).

2. Might break clients if used before any auth module in the proxy pipeline
Actually this looks simple at first, but might be a little bit worse then #1. If an operator puts the staticweb middleware before the authentication middleware, it responds with a HTML listing for GET and HEAD requests if this is enabled on a container. In case of python-swiftclient this might lead to a situation where a user thinks there is an empty, private container but actually the container is public readable. Note: the documentation already says to put staticweb after an auth middleware in the pipeline.

For example, using master on swift and python-swiftclient on a SAIO (put staticweb before tempauth in the proxy pipeline to verify this):

# Create a new container and upload an object
vagrant@saio:~/swift$ swift upload container testobj
testobj

# Expected output
vagrant@saio:~/swift$ swift stat -v container
             URL: http://saio:8080/v1/AUTH_test/container
      Auth Token: AUTH_tk3f556ba123fe4ac5a17da69b5b99cc22
         Account: AUTH_test
       Container: container
         Objects: 1
           Bytes: 0
        Read ACL:
       Write ACL:
         Sync To:
        Sync Key:
   Accept-Ranges: bytes
X-Storage-Policy: default
     X-Timestamp: 1440746384.43528
      X-Trans-Id: txa77acfe8bd00465fadd26-0055e00b95
    Content-Type: text/plain; charset=utf-8

# Now enable listings
vagrant@saio:~/swift$ swift post -m "web-listings: true" container

vagrant@saio:~/swift$ curl http://saio:8080/v1/AUTH_test/container/
[...snipped...the html listing shown now, as expected including "testobj"]

# Now in case of python-swiftclient: 0 objects, no ACLs, no enabled web listing
vagrant@saio:~/swift$ swift stat -v container
         URL: http://saio:8080/v1/AUTH_test/container
  Auth Token: AUTH_tk3f556ba123fe4ac5a17da69b5b99cc22
     Account: AUTH_test
   Container: container
     Objects: 0
       Bytes: 0
    Read ACL:
   Write ACL:
     Sync To:
    Sync Key:
Content-Type: text/html; charset=UTF-8
  X-Trans-Id: tx233a6fd34a184c9e8d455-0055e00bb7

Note that this is still true if there is a public read acl set. Thus it is possible to list and download objects, but in case of python-swiftclient a private empty container is reported. Other clients might be affected as well (due to the HTML response).

A patch to fix both issues has been attached. Overall existing testing could be further improved; for example you can completely remove the read acl and all tests still pass on master.