Old extension that probably hasn't been reviewed in a long time.
https://www.mediawiki.org/wiki/Extension:DoubleWiki
https://wikiapiary.com/wiki/Extension:DoubleWiki
https://wikiapiary.com/w/index.php?title=Special:SearchByProperty&property=Has+extension&value=Extension%3ADoubleWiki
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Resolved | sbassett | T131199 Security review of Ex:DoubleWiki |
I'm not entirely done yet. So far though, its basically vulnerable to the same thing as language converter is - that is, if you can put tags inside attributes and have the angled brackets be unescaped, then you can trick it into doing XSS.
For example, if you have the uncommon configuration $wgExperimentalHtmlIds = true;
(Sorry, this isn't entirely minimized)
And have the right side of the match be
==foo== <span id="dw-foo" title="title of span"/> Sad paragraph ==bar== <span id="dw-foo2" title="title of bar span"/> Some random text. Some more text. ==<p>baz</p><script>alert(4)</script>== <span id="dw-foo2" title="next"/> This random text is different.
And the left side be:
<div id="mw-content-text">foo</div> [[de:Foo]] ==foo== <span id="dw-foo" title="title of span"/> Happy paragraph ==bar== <span id="dw-foo2" title="title of bar span"/> Some random text. Some more text. <span id="dw-foo2" title="next"/> Less text. Fee fa fo fum!
You get an XSS. Similar things might be possible anywhere else < and > are not escaped to entities in attributes (We've removed most of the examples I know about)
Ok. So the situation is actually worse than i initially thought:
- attribute insertion using allignment pre's (including putting an onload on an img tag)
To be clear, I mean wikitext like:
[[de:Foo]] <div id="align-de" style="display:none;"><pre> TRIGGER=" onload=alert(217) d=<p> </pre></div> [[File:0001c.jpg|20px|alt=TRIGGER]]
- cache pollution of per user parser content. Possibly with no interaction from target user as doublewiki works from edit preview (thus via a different origin xhr). Can leak rollback tokens
To clarify, by this, I mean an attacker tricks the victim web browser into loading (via ajax or whatever) something like http://localhost/w/git/index.php?title=fdadfa&action=edit&preloadtitle={{special:listusers/bawolff}}[[de:foo]]§ion=new&preview=yes&match=de Which then gets into the shared cache, which the attacker can retrieve at a later date. The version in the cache is per-user, and can have sensitive data on it (in that example, it will have suppressed usernames if the vicitim is allowed to see that info.)
This will prevent the issues I noticed, mostly by ensuring that DoubleWiki is not used on pages which have edge cases in the html. Extension is still kind of scary, but I believe is "safe" with these changes.
Note: re-test exploitable XSS, pre-conditions may not be true. Assign soon for review/testing.
A few follow-up notes:
'wmgUseDoubleWiki' => [ 'default' => false, 'wikisource' => true, 'sourceswiki' => true, 'frwiktionary' => true, 'frwikiversity' => true, 'fawiki' => true, 'testwiki' => true, ]
Update:
As a note, in theory mw should be better at escaping < and > in attributes now a days as remexhtml is a lot less tolerant of that (possibly in security relavent ways) than tidy was
Update re: RemexHtml: looks like it became the standard in 1.31. Which checks out as $wgTidyConfig is indeed set to [ 'driver' => 'RemexHtml' ]; and $wgUseTidy is set to false in DefaultSettings.php for even early release candidates of 1.31, as well as later versions. The same is true for REL1_31. I'd like to play around with this a bit more just to confirm that things look fine and that I'm not seeing any other security issues with DoubleWiki. Though chatting with @Reedy, DoubleWiki isn't in widespread use (greatest impact for us are the wikisources) and given when RemexHtml became the default, backporting shouldn't even be necessary (unless other issues were found) now given the current version lifecycle.
Update: I built out and tested against MediaWiki and ex:DoubleWiki REL1_31, REL1_32, REL1_33 and master, all of which are now using RemexHtml and for which $wgExperimentalHtmlIds was either disabled or no longer exists. The SecurityCheckPlugin found nothing for master but did return SecurityCheck-DoubleEscaped issues for the htmlspecialchars( $left_url ) and htmlspecialchars( $right_url ) calls within matchColumns() for REL1_31, REL1_32, REL1_33. However I believe these to be false positives given how they are quasi-self-assigning and the SecurityCheck-DoubleEscaped issue is not found in master, where they are no longer quasi-self-assigned.
I could not get the XSS examples from T131199#2337832 or T131199#2342458 to render as it appears that RemexHtml is indeed much more strict in what it allows within html attributes. I'm not certain I fully understand the cache pollution issue at T131199#2347325, so I'll have to investigate that a bit further. But for now, I think DoubleWiki seems fairly safe with respect to the XSS issues previously found.
@Bawolff - I was never able to reproduce the XSS issues within newer versions of MediaWiki as noted within T131199#5423140. I'm also not certain how risky the cache pollution issue is. Thinking about just resolving and making this task public.