Last modified: 2014-06-04 17:02:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67501, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65501 - Javascript inject by anonymous users on private wikis with $wgRawHtml enabled
Javascript inject by anonymous users on private wikis with $wgRawHtml enabled
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-19 18:03 UTC by Chris Steipp
Modified: 2014-06-04 17:02 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Escape username wikitext (1.66 KB, patch)
2014-05-19 19:16 UTC, Chris Steipp
Details

Description Chris Steipp 2014-05-19 18:03:31 UTC
Omer Iqbal noticed that invalid usernames on Special:PasswordReset were parsed as wikitext.

Although this can't be abused on a typical wiki, in the very special case that a wiki has wgRawHtml enabled, and rely on limiting who can edit to prevent attackers from adding javascript, the username on Special:PasswordReset can be supplied by anyone and will be parsed with wgRawHtml enabled.

Since Special:PasswordReset is whitelisted by default on private wikis, this could potentially lead to an xss crossing a privilege boundary.

The attack is additionally mitigated by default XFO rules preventing that special page from being used in an iframe, so the threat from this is very low.

Omer also reported the "html injection" directly to mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1012563
Comment 1 Chris Steipp 2014-05-19 19:16:05 UTC
Created attachment 15443 [details]
Escape username wikitext

When onSubmit returns an array, it's added to the output with, wfMessage( $msg, $params )->parse(), so that errors can contain wikitext.

This puts the username through wfEscapeWikiText. Having the function return a Status object instead of array would do the same thing, but a more complex patch that I would rather not do as a security fix.
Comment 2 Brad Jorsch 2014-05-19 19:38:33 UTC
Code-review:+1

*Probably* the second portion of the patch isn't necessary since $firstUser is a user object either from the database (which I hope wouldn't have any vulnerable names in it!) or User::newFromName with 'valid' validation mode (which I hope wouldn't allow through any vulnerable names!). But I doubt there's any harm in escaping it either, so better to be safe.
Comment 3 Chris Steipp 2014-05-19 20:49:42 UTC
Cluster was patched today:
20:05 csteipp: fix deployed for bug 65501


Jeff, adding you since donatewiki has wgRawHtml enabled.

Markus, this was introduced in commit 399f9557, so 1.19-1.23 should probably get patched whenever you do the next release.
Comment 4 Markus Glaser 2014-05-26 21:35:30 UTC
Patch applies nicely to REL1_19, REL1_21, REL1_22 and master. So it will be included in the next round on 28th May 2014. Tomorrow, I'll send out a pre-release announcement.
Comment 5 Markus Glaser 2014-05-26 21:39:43 UTC
also, REL1_23 works well with the patch.
Comment 6 Greg Grossmeier 2014-05-29 17:28:20 UTC
Gerrit bot probably can't comment here, but the patch for core was uploaded https://gerrit.wikimedia.org/r/#/c/136131/
Comment 7 Greg Grossmeier 2014-05-29 21:42:38 UTC
Marking as fixed as it's been released by Markus today. Waiting on Jeff to confirm donatewiki has been patched before moving this out of the Security component.
Comment 8 Jeff Green 2014-06-02 13:15:55 UTC
awight deployed this patch over the weekend.
Comment 9 Henri Salo 2014-06-04 06:16:33 UTC
CVE request: http://www.openwall.com/lists/oss-security/2014/06/03/7
Comment 10 Chris Steipp 2014-06-04 17:02:42 UTC
Assigned CVE-2014-3966

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links