This can lead to security issues because most widget authors do not expect their widget to be executed in an html attribute context.
For example, consider the following wikitext :
<div title="{{#widget:UStreamLive|width=onmouseover=alert(1);//}}">executed at http://www.mediawikiwidgets.org/Special:ExpandTemplates . It executes arbitrary js whenever your mouse goes over the widget.
p.s. If this used MW's builtin StripMarker support, this would be taken care of automatically.
I do not have a clue what to do about this and since Yaron does not seem to have a clue either I guess we are stuck here.
@Kghbln: Do https://www.mediawiki.org/wiki/Strip_marker and https://phabricator.wikimedia.org/T110143 provide some pointers?
So interestingly, https://minecraft.gamepedia.com/Template:Sprite seems to intentionally (or maybe accidentally) use this behaviour to bypass MediaWiki's CSS sanitization.
The template makes a span that has a background-image css property. Normally, url() in css would be stripped. It looks like because widgets are replaced after CSS sanitization, it bypasses MediaWiki's builtin CSS sanitization. (Which on a scale of badness, isn't too bad. At worst it allows some privacy leaks, possibly allows an attacker to associate usernames and ip addresses.). But its interesting.
Hi. Sorry i didn't give much context.
Easiest fix, change WidgetRenderer::$markerPrefix to be something like "START_WIDGET\"'" (edit: to clarify, that fixes the situation, since if thr marker prefix has ' and " in it they will get escaped anywhere that those characters aren't allowed like attributes. Thus preventing the replacement if its potentially dangerous) However, that would likely break some use cases (basically any time someone uses the result of a widget inside an attribute).
I'm not sure of a way to fix this off the top of my head, well still working inside attributes (If that is important). It would probably require something much more complicated
My attempt at fixing this:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/856035
IT should maintain backwards compatibility with putting a widget in an attribute (E.g. you can still do <div style="{{#widget:foo}}"> to bypass MW CSS filters).
With @Bawolff's patch merged, can we resolve and make this task public now? I don't believe this implicates Wikimedia production in any way.
@Bawolff Any chance to get this backported at least to MW 1.39 since this one is no longer an extension with tags? Will be cool if possible.
Change 856581 had a related patch set uploaded (by SBassett; author: Brian Wolff):
[mediawiki/extensions/Widgets@REL1_39] SECURITY: Make Widget replacements more reliable
Change 856581 merged by jenkins-bot:
[mediawiki/extensions/Widgets@REL1_39] SECURITY: Make Widget replacements more reliable
REL1_35 and REL1_38 are still supported. Wouldn't it make sense to backport to these branches, too?
We (Security-Team) typically make an effort to land backports on master and supported release branches as best we can, for codebases that are included within our regular or supplemental security releases. However, there are some codebases where more complex merge conflicts arise (to the point of the code being so different that various features and files do not even exist within a certain version, in some cases) which we tend to leave to the actual code maintainers (which the Security-Team is not and cannot be) to decide to backport or not.
Change 880910 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):
[mediawiki/extensions/Widgets@REL1_38] SECURITY: Make Widget replacements more reliable
Change 880910 merged by jenkins-bot:
[mediawiki/extensions/Widgets@REL1_38] SECURITY: Make Widget replacements more reliable
Change 880987 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):
[mediawiki/extensions/Widgets@REL1_35] SECURITY: Make Widget replacements more reliable
Change 880987 merged by jenkins-bot:
[mediawiki/extensions/Widgets@REL1_35] SECURITY: Make Widget replacements more reliable
@sbassett Thanks for your feedback and for providing details to me. Sure, I grok fully! No problem at all. In the end, I was just asking since it appears to me that Widgets is more of a community-supported extension with all implications attached to it. Still, you and your team cannot be expected to do it. No worries.
@Bawolff Apparently it was not too hard to do the backports. Thanks a bunch for doing them!
I noticed that the CVE ( https://www.cvedetails.com/cve/CVE-2023-22911/ ) has the product marked as "mediawiki". Normally I would assume this would imply mediawiki-core or at least an extension distributed with MediaWiki. It also has language like "An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1" which is pretty misleading.
So there are a handful of WMF and volunteer folks who request CVEs for Wikimedia code these days, and there isn't a great standard around doing so, unfortunately. Whenever I request a CVE, I try to explicitly mention the exact piece of code (an extension or whatever) that was affected. However, that often doesn't matter, as Mitre will sometimes proactively change our various descriptions, etc as they review our CVE submissions. I am guessing that is very likely the case for this specific example, given the language used in the CVE. Unfortunately, I'm not sure there is much that can be done aside from submitting a CVE update request and/or complaining to Mitre about this issue. The first option might prove somewhat useful, the latter likely will not at all.