I think disabling /api/tags/ won't be enough. The xss in subject line still exists.

In T312506#8060982, @Ladsgroup wrote:

I think disabling /api/tags/ won't be enough. The xss in subject line still exists.

Right, to be clear this would just fix the tags XSS. I didn't get around to looking at the subject line one last night.

diff --git a/modules/profile/templates/lists/apache.conf.erb b/modules/profile/templates/lists/apache.conf.erb
index c9ed2b0b32..5587699cde 100644
--- a/modules/profile/templates/lists/apache.conf.erb
+++ b/modules/profile/templates/lists/apache.conf.erb
@@ -30,6 +30,14 @@
     <% end %>
     <%= @ssl_settings.join("\n    ") %>
 
+    # Reject the creation of tags, which are an XSS vector when combined with a
+    # a users' name field and the tags url,
+    # https://polymorphic.lists.wmcloud.org/hyperkitty/api/tags/
+    # https://phabricator.wikimedia.org/T312506
+    RewriteEngine on
+    RewriteCond %{REQUEST_METHOD} POST
+    RewriteRule ^/hyperkitty/list/.*/tags$ - [F]
+
     Header set Content-Security-Policy "default-src 'self'; connect-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"
     Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico
     Alias /mailman3/static      /var/lib/mailman3/web/static

This rejects the creation of tags in my testing on https://polymorphic.lists.wmcloud.org/

Would something like:

RewriteCond %{REQUEST_METHOD} GET
RewriteRule ^/hyperkitty/api/list/.*/thread/.*/$ - [F]

work for the second issue with script code in email subjects? Or would that have some unintended affects? It seems to work on my initial testing.

On IRC @jhathaway asked about how to publish it. It needs to go through puppet, but for the tags one I can say we're just getting rid of spam instead of discussing the XSS. Like, look at all the tags on this random wikitech-l post:

On Wednesday I had gone through and literally all the hundreds of tags were nonsense spam except 2.

Note that I haven't had a chance to look through the email subject issue yet.

Upstream message:

I have tested the critical vulnerability on an installation with djangorestframework==3.13.1 and am unable to duplicate the issue. This may have been fixed in djangorestframework 3.11.2 or 3.9.1, see https://www.django-rest-framework.org/community/release-notes/.
In any case, my results for POCs 1 and 2 are attached. In neither case was an alert raised. Further, POC 3 depends on POC 1 or 2, so that is presumably not an issue with djangorestframework==3.13.1.
I have not yet tested any of the other issues

Looks like this was the fix, https://github.com/encode/django-rest-framework/commit/4bb9a3c48427867ef1e46f7dee945a4c25a4f9b8. This fix is included in the bullseye version of python3-djangorestframework. So we should upgrade the box to bullseye and remove mitigations.

In T312506#8089092, @jhathaway wrote:

Looks like this was the fix, https://github.com/encode/django-rest-framework/commit/4bb9a3c48427867ef1e46f7dee945a4c25a4f9b8. This fix is included in the bullseye version of python3-djangorestframework. So we should upgrade the box to bullseye and remove mitigations.

This will also affect other mailman 3 installations on Buster, so let's rather backport the fix to 3.9.0-1? there's also a second low-prio issue we can fix along: https://security-tracker.debian.org/tracker/CVE-2020-25626
This can be fixed via buster-security, which will then end up in our infra by updating from Debian.

We can/should still update to Bullseye, but that can be disentangled from the current security issue.

We should also get a CVE assigned to https://github.com/encode/django-rest-framework/commit/4bb9a3c48427867ef1e46f7dee945a4c25a4f9b8 (since there was none, it wasn't picked up by any distro or security triage process), I'll take care of that.

@MoritzMuehlenhoff I did a little more digging and it looks like you are correct, there are two inter-related XSS issues in 3.9.0:

1. urlize_quoted_links, XSS vector, https://github.com/encode/django-rest-framework/pull/6330, fix https://github.com/encode/django-rest-framework/commit/4bb9a3c48427867ef1e46f7dee945a4c25a4f9b8, fix appears in 3.9.2
2. urlize_quoted_links, still an XSS vector, replace with urlize from django, https://security-tracker.debian.org/tracker/CVE-2020-25626, fix: https://github.com/encode/django-rest-framework/commit/4121b01b912668c049b26194a9a107c27a332429, fix appears in 3.11.2

So I think we need to backport both patches together, the second patch never made it into the 3.9.X series.

In T312506#8091638, @jhathaway wrote:

So I think we need to backport both patches together, the second patch never made it into the 3.9.X series.

I've backported both patches to 3.9.0 and copied 3.9.0-1+deb10u1 to lists1001.wikimedia.org:/home/jmm. Do you have access to the test setup for the pen test, could you verify this update fixes the issue found by the auditors? Then I'd release these via security.debian.org as a followup step.

great, I do have access to the pen testing environment, so I will test today and report back.

@MoritzMuehlenhoff I have confirmed on https://polymorphic.lists.wmcloud.org/ that both issues are fixed:

1. tags: https://polymorphic.lists.wmcloud.org/hyperkitty/api/tags/
2. threads: https://polymorphic.lists.wmcloud.org/hyperkitty/api/list/test70@polymorphic.lists.wmcloud.org/thread/4PPRGV4HL73TJ7NB2RJTY7DCDE5YOEBB/

Excellent, thanks. A DSA should be out tomorrow, then we can update lists1001.

I've requested a CVE ID for https://github.com/encode/django-rest-framework/commit/4bb9a3c48427867ef1e46f7dee945a4c25a4f9b8, will update the task when I've heard back.

@MoritzMuehlenhoff @jhathaway - Looks like enough has been publicly-disclosed about this issue now to where we could make this task public? Or are we still waiting on anything in particular that would block on that?

The update in Debian has been released: https://lists.debian.org/debian-security-announce/2022/msg00154.html

The CVE assignment is still pending, haven't heard since then.

@sbassett Im fine with opening the task.

This has been assigned CVE-2018-25045