Page MenuHomePhabricator

XSS in Special:ExpandTemplates when $wgRawHtml = true
Closed, ResolvedPublic

Description

Special:ExpandTemplates parses user input as wikitext and shows a preview, yet it fails to add an edit token to the form and check it. This is an XSS vulnerability when $wgRawHTML = true. It is easy to reproduce and exploit:

http://wikimediafoundation.org/w/index.php?title=Special:ExpandTemplates&wpInput=%3Chtml%3E%3Cscript%3Ealert%281%29%3C/script%3E%3C/html%3E


Version: unspecified
Severity: normal
URL: http://wikimediafoundation.org/w/index.php?title=Special:ExpandTemplates&wpInput=%3Chtml%3E%3Cscript%3Ealert%281%29%3C/script%3E%3C/html%3E

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:44 AM
bzimport added a project: Security-Core.
bzimport set Reference to bz71111.
bzimport changed Security from none to Software security bug.
Restricted Application changed the visibility from "Public (No Login Required)" to "acl*security (Project)". · View Herald TranscriptNov 22 2014, 3:44 AM
Restricted Application changed the edit policy from "All Users" to "acl*security (Project)". · View Herald Transcript

(In reply to Kevin Israel (PleaseStand) from comment #0)

This is an XSS vulnerability when $wgRawHTML = true.

Correction: when $wgRawHtml = true, as in the summary.

I wonder if action=submit (preview) is affected as well.

Created attachment 16597
WIP patch (master)

We might not want to reuse the existing error message from EditPage, though that's a minor issue.

The bigger issue is that anons always have the edit token "+\", and anyone who isn't logged into wikimediafoundation.org is an anon. That means my patch (at least so far) would not stop the XSS and everything possible with it (e.g. making CORS requests against other Wikimedia sites). Yikes!

attachment 0001-SECURITY-Add-edit-token-to-Special-ExpandTemplates.patch ignored as obsolete

Created attachment 16608
patch (master)

Issues should be mostly fixed now; please review.

Attached:

Kevin, apologies for the slow response on this!

The patch looks good, and prevents the issue in my testing. As a public patch, it seems like we might want to restrict the page to users with edit rights in general, which would remove the one special case you put in. But we'll avoid setting policy in security patches if we can help it.

Krinkle, I'm not seeing a way that preview can be abused in the same way, since EditPage checks permissions pretty early on. But ping me if you've thought of any specific ways to abuse this.

Kevin's patch is deployed, thanks!

20:19 csteipp: patched bugs 71111 and 71394 in wmf7 and wmf8

Markus, this can be added to the next release.

Restricted Application changed the visibility from "acl*security (Project)" to "Custom Policy". · View Herald TranscriptNov 24 2014, 9:27 PM
Restricted Application changed the edit policy from "acl*security (Project)" to "Custom Policy". · View Herald Transcript
Restricted Application changed the visibility from "Custom Policy" to "Custom Policy". · View Herald TranscriptNov 26 2014, 5:55 AM
Restricted Application changed the edit policy from "Custom Policy" to "Custom Policy". · View Herald Transcript
csteipp changed Security from Software security bug to None.Nov 26 2014, 6:09 AM

Backport to REL1_23. There's no special expand templates before that, so no further backports needed. If someone could confirm the backport, that would be very helpful.

Backport to REL1_23. There's no special expand templates before that, so no further backports needed.

Special:ExpandTemplates is available for earlier MW versions as an extension. The patch should be backported to the REL1_19 and REL1_22 branches of that extension.

Just found an error in the previous patch for REL1_23, as it used the config wrapper instead of the global. Fixed patch here:

I ran Special:ExpandTemplates after applying the patches on REL1_24 and REL1_23. Tested with {{FULLPAGENAME}}, just to make sure the page still works.

Just found an error in the previous patch for REL1_23, as it used the config wrapper instead of the global. Fixed patch here:

This fixes the issue in my test

The patch should be backported to the REL1_19 and REL1_22 branches of that extension.

Done in https://gerrit.wikimedia.org/r/#/c/176312/ and https://gerrit.wikimedia.org/r/#/c/176303/, pending review.

csteipp triaged this task as High priority.
csteipp added a project: Vuln-CSRF.
csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".
csteipp changed the edit policy from "Custom Policy" to "All Users".