| 2015-08-28 07:30:42 |
Christian Schwede |
bug |
|
|
added bug |
| 2015-08-28 07:30:42 |
Christian Schwede |
attachment added |
|
staticweb.patch https://bugs.launchpad.net/bugs/1489749/+attachment/4453666/+files/staticweb.patch |
|
| 2015-08-28 07:43:16 |
Christian Schwede |
description |
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. |
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 than #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, even if a token is sent. 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. |
|
| 2015-08-28 08:12:20 |
Christian Schwede |
attachment added |
|
puppet-swift.patch https://bugs.launchpad.net/swift/+bug/1489749/+attachment/4453718/+files/puppet-swift.patch |
|
| 2015-08-28 11:21:08 |
Jeremy Stanley |
bug |
|
|
added subscriber Swift Core security contacts |
| 2015-08-28 11:21:48 |
Jeremy Stanley |
description |
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 than #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, even if a token is sent. 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. |
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.
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 than #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, even if a token is sent. 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. |
|
| 2015-08-28 11:22:12 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2015-08-28 11:23:08 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2015-08-29 20:49:22 |
Christian Schwede |
attachment added |
|
staticweb.patch https://bugs.launchpad.net/swift/+bug/1489749/+attachment/4454295/+files/staticweb.patch |
|
| 2015-08-31 15:08:40 |
Tristan Cacqueray |
bug |
|
|
added subscriber Emilien Macchi |
| 2015-08-31 15:54:36 |
Emilien Macchi |
attachment added |
|
puppet-swift patch https://bugs.launchpad.net/ossa/+bug/1489749/+attachment/4455138/+files/puppet-swift.patch |
|
| 2015-08-31 16:04:43 |
Emilien Macchi |
bug |
|
|
added subscriber Mathieu Gagné |
| 2015-08-31 16:05:45 |
Emilien Macchi |
attachment added |
|
puppet-swift patch https://bugs.launchpad.net/ossa/+bug/1489749/+attachment/4455145/+files/puppet-swift.patch |
|
| 2015-08-31 16:16:29 |
Emilien Macchi |
bug task added |
|
puppet-swift |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
nominated for series |
|
puppet-swift/trunk |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
bug task added |
|
puppet-swift/trunk |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
nominated for series |
|
puppet-swift/icehouse |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
bug task added |
|
puppet-swift/icehouse |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
nominated for series |
|
puppet-swift/liberty |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
bug task added |
|
puppet-swift/liberty |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
nominated for series |
|
puppet-swift/juno |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
bug task added |
|
puppet-swift/juno |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
nominated for series |
|
puppet-swift/kilo |
|
| 2015-08-31 16:49:05 |
Emilien Macchi |
bug task added |
|
puppet-swift/kilo |
|
| 2015-08-31 18:13:31 |
Emilien Macchi |
attachment added |
|
puppet-swift.patch https://bugs.launchpad.net/puppet-swift/+bug/1489749/+attachment/4455231/+files/puppet-swift.patch |
|
| 2015-08-31 18:17:29 |
Emilien Macchi |
attachment added |
|
puppet-swift-kilo.patch https://bugs.launchpad.net/puppet-swift/+bug/1489749/+attachment/4455232/+files/puppet-swift-kilo.patch |
|
| 2015-08-31 18:18:02 |
Emilien Macchi |
attachment added |
|
puppet-swift-juno.patch https://bugs.launchpad.net/puppet-swift/+bug/1489749/+attachment/4455233/+files/puppet-swift-juno.patch |
|
| 2015-08-31 18:20:36 |
Emilien Macchi |
bug task deleted |
puppet-swift/icehouse |
|
|
| 2015-08-31 18:20:41 |
Emilien Macchi |
bug task deleted |
puppet-swift/liberty |
|
|
| 2015-08-31 18:20:52 |
Emilien Macchi |
puppet-swift: assignee |
|
Emilien Macchi (emilienm) |
|
| 2015-08-31 20:32:54 |
Christian Schwede |
attachment added |
|
staticweb-poc.sh https://bugs.launchpad.net/swift/+bug/1489749/+attachment/4455391/+files/staticweb-poc.sh |
|
| 2015-09-02 19:30:49 |
Tristan Cacqueray |
cve linked |
|
2015-5249 |
|
| 2015-09-02 19:31:28 |
Tristan Cacqueray |
summary |
staticweb middleware ignores acl and breaks clients |
staticweb middleware ignores acl and breaks clients (CVE-2015-5249) |
|
| 2015-09-07 08:01:29 |
Christian Schwede |
bug |
|
|
added subscriber Garth Mollett |
| 2015-09-08 09:48:54 |
Christian Schwede |
attachment added |
|
staticweb.patch https://bugs.launchpad.net/swift/+bug/1489749/+attachment/4459107/+files/staticweb.patch |
|
| 2015-09-08 16:04:39 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Won't Fix |
|
| 2015-09-10 01:52:25 |
Tristan Cacqueray |
summary |
staticweb middleware ignores acl and breaks clients (CVE-2015-5249) |
staticweb middleware ignores acl and breaks clients |
|
| 2015-09-10 01:52:41 |
Tristan Cacqueray |
cve unlinked |
2015-5249 |
|
|
| 2015-09-10 01:54:55 |
Tristan Cacqueray |
cve linked |
|
2015-5249 |
|
| 2015-09-14 15:42:55 |
Emilien Macchi |
puppet-swift: status |
New |
Invalid |
|
| 2015-09-22 20:33:26 |
Tristan Cacqueray |
information type |
Private Security |
Public |
|
| 2015-10-14 19:28:23 |
Tristan Cacqueray |
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.
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 than #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, even if a token is sent. 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. |
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 than #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, even if a token is sent. 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. |
|
| 2015-10-22 10:38:24 |
OpenStack Infra |
swift: status |
In Progress |
Fix Committed |
|
| 2015-11-11 21:09:45 |
OpenStack Infra |
tags |
|
in-feature-crypto |
|
| 2016-01-08 04:55:28 |
OpenStack Infra |
tags |
in-feature-crypto |
in-feature-crypto in-feature-hummingbird |
|
| 2017-07-11 18:30:23 |
Thiago da Silva |
swift: status |
Fix Committed |
Fix Released |
|
