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.

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.

There are some more vulnerable parameters not covered by that patch:

• https://wikitech.wikimedia.org/wiki/Special:CreateForm?template_foo=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E
• https://wikitech.wikimedia.org/wiki/Special:CreateForm?template_foo=foo&label_foo=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E
• https://wikitech.wikimedia.org/wiki/Special:CreateForm?add_field=1&new_template=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E

These issues are caused by SF_TemplateInForm.php lines 230-234: https://github.com/wikimedia/mediawiki-extensions-SemanticForms/blob/d8471bcb8387/includes/SF_TemplateInForm.php#L230-L234

Simple patch for that attached.

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!

In T103391#1401606, @Yaron_Koren wrote:

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

Where has this been checked in?

In T103391#1401606, @Yaron_Koren wrote:

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?

In T103391#1401606, @Yaron_Koren wrote:

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

Isn't that typically a license requirement?

In T103391#1401606, @Yaron_Koren wrote:

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)

See also T53642

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!!

@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.

can we close this since the patch is merged?

CVE-2015-6731 was assigned for this.