Page MenuHomePhabricator

Reflected XSS vulnerabilities in Semantic Forms
Closed, ResolvedPublic

Description

While looking over the code for the most recent version of Semantic Forms I noticed some issues with lack of escaping and some quick tests verified that there were XSS issues in the extension on Special:CreateForm and Special:FormEdit. I haven't looked over all of the extension yet, so there are possibly more. As far as I know, this extension is only enabled on wikitech, but many third parties using Semantic MediaWiki have it installed.

URLs with examples of the vulnerable parameters (tested in Firefox, can be confirmed while logged in or logged out):

Event Timeline

Maniphest changed the visibility from "Public (No Login Required)" to "Custom Policy".Jun 22 2015, 5:54 PM
Maniphest changed the edit policy from "All Users" to "Custom Policy".
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 22 2015, 5:54 PM
Grunny created this task.Jun 22 2015, 5:54 PM
Grunny updated the task description. (Show Details)
Grunny added a project: Security.
Grunny changed Security from None to Software security bug.
Grunny edited subscribers, added: Grunny; removed: Aklapper.
csteipp triaged this task as Unbreak Now! priority.Jun 22 2015, 6:34 PM
csteipp added a subscriber: Yaron_Koren.

Need to get a fix on wikitechwiki asap.

@Yaron_Koren, since wikitechwiki is running 3.2 (Feb 2015), I think these are new issues. I don't recall any getting patched since this spring, so upgrading to 3.3 I don't think is likely to help. But let me know if you can verify otherwise?

@dpatrick and I can start on a patch today.

csteipp added a subscriber: Andrew.Jun 22 2015, 6:38 PM

Looks like one of the issues is SF_PageSection.php, lines 63-68.

And SF_FormEdit.php line 55

Naive patch for the xss, against the 1.26wmf10 branch (although it looks like neither files have changed as of the current master). I don't have an SMW instance to test on, @Yaron_Koren, can you test that this doesn't break any expected functionality? If it does, we can figure out an escaping strategy that works.

csteipp moved this task from Backlog to Waiting on the Security-Team board.

Hi guys - thanks a lot for these patches! And sorry for the remaining XSS vulnerabilities; I really thought they were all fixed by now. I'll check in these changes soon, unless any of you want to do it yourselves (feel free).

Please avoid making the patches public until they're deployed to wikitech.

Special:FormEdit is also vulnerable when you pass wpSave=Save%20page&wpSummary="><script>alert(1);</script> to any defined form/page. I escaped label there too, since I couldn't find where else it was escaped.

Okay, I just checked in all of your proposed changes. The only place where I checked in a different change from your versions was for the 3rd patch, for /includes/SF_FormUtils.php - instead of escaping those specific variables, I replaced the hardcoded HTML that used them with a call to Html::input() - which is more in line with the other changes anyway. Hopefully this fixes all the known XSS issues.

csteipp and Grunny - I didn't acknowledge you in these changes, because I try not to publicize the fact that previous versions of Semantic Forms have had security leaks, and if I had noted that the patches came from you it might lead people to more easily figure out what's going on. But I know it was your code, and I thank you!

Krenair added a comment.EditedJun 26 2015, 1:22 PM

Okay, I just checked in all of your proposed changes.

Where has this been checked in?

The only place where I checked in a different change from your versions was for the 3rd patch, for /includes/SF_FormUtils.php - instead of escaping those specific variables, I replaced the hardcoded HTML that used them with a call to Html::input() - which is more in line with the other changes anyway. Hopefully this fixes all the known XSS issues.

Can you provide the new patch?

csteipp and Grunny - I didn't acknowledge you in these changes

Isn't that typically a license requirement?

I try not to publicize the fact that previous versions of Semantic Forms have had security leaks

So... Are you providing proper security updates to your users or not? You do realise that normally when security issues are resolved we expect the task to be made public, right?

It looks like the patches were pushed to Gerrit and merged: https://gerrit.wikimedia.org/r/220839

It hasn't been deployed to wikitech yet, but now the patches are public....

And self-merged. Wow.

Took the patch from Gerrit, added a Bug: line and [SECURITY] tag to the commit message, uploaded to tin:/srv/patches/extensions/SemanticForms/T103391.patch, applied it to our wmf11 submodule and sync'd it silently. (in a slightly weird order, but that's the end result)

Krenair - I only understood about half of what you wrote (if that), but thanks for your help.

Hopefully all the XSS issues are now resolved...

@Krenair, thanks handling that. Really appreciate it.

@Yaron_Koren, sorry for the confusion in the process. I should probably add a link to https://www.mediawiki.org/wiki/Reporting_security_bugs#What_happens_when_I_report_a_bug on all our security bugs.

Ooh... I didn't realize that security-related "tasks" are made public after they're resolved. Oh well.

Okay, I just checked in all of your proposed changes. The only place where I checked in a different change from your versions was for the 3rd patch, for /includes/SF_FormUtils.php - instead of escaping those specific variables, I replaced the hardcoded HTML that used them with a call to Html::input() - which is more in line with the other changes anyway. Hopefully this fixes all the known XSS issues.

@Yaron_Koren, I was looking at the changes you made to the SF_FormUtils.php patch, and while $value is escaped correctly, $label isn't escaped in your patch. Can you confirm that's either escaped somewhere else, or isn't user controlled? I wasn't able to figure out how to influence that parameter, but I'm worried that's just because I don't know the extension very well. Let me know.

@csteipp - right, that's true. I just checked in a change to replace that hardcoded HTML as well, which should solve that problem.

Oh yeah, and @Krenair - I SELF-MERGED IT!1!!

Krenair added a comment.EditedJun 29 2015, 2:29 PM

@csteipp: I could figure out how to influence it - go to Special:CreateClass and fill it out with silly values to get a Form: page, then edit the {{{standard input|summary}}} line to have an additional label= parameter, hit preview and look at the 'Form preview'. Content seems to be parsed though, from includes/SF_FormPrinter.php line 1543.

mmodell added a subscriber: mmodell.Jul 7 2015, 7:05 PM

can we close this since the patch is merged?

csteipp closed this task as Resolved.Jul 7 2015, 11:47 PM
csteipp claimed this task.
csteipp added a parent task: Restricted Task.Aug 7 2015, 6:37 PM
csteipp added a subscriber: ProgramCeltic.
csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".Aug 10 2015, 9:58 PM
csteipp changed the edit policy from "Custom Policy" to "All Users".
csteipp changed Security from Software security bug to None.

CVE-2015-6731 was assigned for this.

csteipp moved this task from Waiting to Done on the Security-Team board.Oct 13 2015, 11:55 PM
Restricted Application added subscribers: Jay8g, TerraCodes. · View Herald TranscriptJun 7 2017, 6:49 PM