Page MenuHomePhabricator

XSS in Extension:RSS when $wgRSSAllowLinkTag = true (CVE-2022-29969)
Closed, ResolvedPublicSecurity

Description

CVE-2022-29969
This is a WMF deployed extension, however $wgRSSAllowLinkTag is false on cluster, so it is not vulnerable in the configuration used by WMF.

RSS extension implementation of strip markers suffers from a similar problem as MW core's used to before T110143 was fixed. When $wgRSSAllowLinkTag is set to true, you can use this to escape from an attribute.

As an example:

  • Set $wgRSSAllowLinkTag = true;

Create an rss feed as follows:

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
        >

<channel>
        <title>Test</title>
<item>
                <title>First item</title>
                <link>https://example.com</link>
                    
                                        <description><![CDATA[<a title="tabindex=1 autofocus onmouseover=alert(1) onfocus=blur() onblur=alert(document.domain)//"> Should autotrigger on chrome, and trigger on hover on firefox</a> ]]></description>
</item>
</channel>
</rss>
  • Be sure the above RSS feed is added to $wgRSSUrlWhitelist
  • Create a template named Template:RSS containing only
<div title="{{{description}}}"></div>
  • Use the following tag on a page <rss templatename=RSS>http://address.of.rss.feed.from.above</rss>

This should make an XSS that autotriggers on chrome, and triggers on hoover in firefox.

Best solution, is to probably copy what MW core does for strip markers with them including "'

Event Timeline

Its related to the custom strip marker scheme, i'm not sure if that's what is being referred to in the other task. The code path involved here is the one using the Sanitizer, not the one with a custom escaping function.

The actual escapeTemplateParameter isn't really a security boundry most of the time except when used with insertStripItem, since the results get parsed later in most cases.

Proposed patch

Extension doesn't seem to have a maintainer to CC on this task. I assume I should not just throw on gerrit since its WMF deployed, even if this code path is not enabled on cluster.

Extension doesn't seem to have a maintainer to CC on this task. I assume I should not just throw on gerrit since its WMF deployed, even if this code path is not enabled on cluster.

Since ext:RSS isn't bundled, it would go out with the next supplemental release, which is tracked at T305209. I've added it there for now. Since this isn't currently vulnerable within Wikimedia production (and likely wouldn't ever be) I'd consider it low risk pushing it through gerrit. I think the only concern would be if other mediawiki operators were left uninformed or vulnerable for some time period, but IME we've tended not to care about that as much in the past and have just tried to merge security bug fixes quickly, make tasks public and send out the supplemental release each quarter, as best efforts.

Change 787807 merged by jenkins-bot:

[mediawiki/extensions/RSS@master] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Bawolff claimed this task.
Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".
Bawolff changed the edit policy from "Custom Policy" to "All Users".

Change 787779 had a related patch set uploaded (by Legoktm; author: Brian Wolff):

[mediawiki/extensions/RSS@REL1_38] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787780 had a related patch set uploaded (by Legoktm; author: Brian Wolff):

[mediawiki/extensions/RSS@REL1_37] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787781 had a related patch set uploaded (by Legoktm; author: Brian Wolff):

[mediawiki/extensions/RSS@REL1_36] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787782 had a related patch set uploaded (by Legoktm; author: Brian Wolff):

[mediawiki/extensions/RSS@REL1_35] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787783 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):

[mediawiki/extensions/RSS@REL1_34] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787779 merged by jenkins-bot:

[mediawiki/extensions/RSS@REL1_38] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787780 merged by jenkins-bot:

[mediawiki/extensions/RSS@REL1_37] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787781 merged by jenkins-bot:

[mediawiki/extensions/RSS@REL1_36] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787783 merged by Brian Wolff:

[mediawiki/extensions/RSS@REL1_34] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

Change 787782 merged by jenkins-bot:

[mediawiki/extensions/RSS@REL1_35] SECURITY: Prevent XSS from "stripItem" replacement strings in attribute

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

sbassett renamed this task from XSS in Extension:RSS when $wgRSSAllowLinkTag = true; to XSS in Extension:RSS when $wgRSSAllowLinkTag = true (CVE-2022-29969).Aug 16 2022, 1:36 PM
sbassett triaged this task as Low priority.
sbassett changed Risk Rating from N/A to Low.