TL;DR: arbitrary JS execution on query.wikidata.org (not CORS-whitelisted)
The Wikidata Query Service UI has a convenient feature (implemented in [I6c8a7ebac1](https://gerrit.wikimedia.org/r/300055), T137784) where mathematical expressions in results are displayed directly, [for example](https://query.wikidata.org/embed.html#SELECT%20%3FitemLabel%20%3Fformula%20WHERE%20{%0A%20%20VALUES%20%3Fitem%20{%20wd%3AQ11518%20wd%3AQ35875%20}%0A%20%20%3Fitem%20wdt%3AP2534%20%3Fformula.%0A%20%20SERVICE%20wikibase%3Alabel%20{%20bd%3AserviceParam%20wikibase%3Alanguage%20%22[AUTO_LANGUAGE]%2Cen%22.%20}%0A}):
{F30389151}
Unfortunately, it does this by directly pasting the contents of MathML literals into the HTML:
```lang=js
case DATATYPE_MATHML:
$html.append( $( data.value ) );
break;
```
I //think// this is fine for MathML from the Wikibase RDF output, which is generated by Extension:Math and hopefully trustworthy at the markup level regardless of what the underlying TeX value on Wikidata is. However, nothing stops a query author from tagging any other string as MathML:
```lang=sparql
SELECT * WHERE {
BIND("<script>alert('XSS')</script>"^^<http://www.w3.org/1998/Math/MathML> AS ?xss)
}
```
This means that if an attacker can trick a victim to open a link [like this one](https://query.wikidata.org/embed.html#SELECT%20*%20WHERE%20{%0A%20%20BIND%28%22%3Cscript%3Ealert('XSS')%3C%2Fscript%3E%22^^%3Chttp%3A%2F%2Fwww.w3.org%2F1998%2FMath%2FMathML%3E%20AS%20%3Fxss%29%0A}), they can run arbitrary JavaScript on query.wikidata.org in the user’s browser. (Clicking a link to query results is a pretty common operation for Wikidata users.)
Fortunately, query.wikidata.org is //not// on the CORS whitelist (`$wgCrossSiteAJAXdomains`) for production wikis (I had proposed this in T218568, but it was declined), so I don’t think this is enough to let the attacker steal the victim’s Wikimedia accounts.
---
Steps to fix (from T233213#5584298):
- [x] Turn P9315 into a patch against `wikidata/query/gui-deploy`
- [x] On the deployment server (is that deployment.eqiad.wmnet or a different one, btw?), apply that patch in the `gui` submodule of the `wikidata/query/deploy` checkout (`/srv/deployment/wdqs/wdqs`?)
- [x] Commit that patch to the gui submodule, and then commit the submodule update in the main deploy repository? Not sure if this is necessary
- [x] Deploy the current tree (`scap deploy`?)
- [x] Verify that the vulnerability is fixed
So tomorrow EU time (2pm GMT) we will...
Get the on gerrit code in shape:
[x] Merge the patch on gerrit into the main repo
- https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui/+/549457/ hash: d9f964b88c01748e278ca8c4b8929a8ef0ef0267
[x] Merge the patch that will be generated in `wikidata/query/gui-deploy`
- https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui-deploy/+/549461/ hash: 7445472ab0ec61890b42e4d524416fbc6a18aa8a
[x] Update `gui` submodule in `wikidata/query/deploy` repository, bringing it in line with the deployment server’s version
- https://gerrit.wikimedia.org/r/#/c/wikidata/query/deploy/+/549463/ hash: 094d9cda98f3fb706cf9c25aefa3eb33f9f6999a
[x] Confirm that https://archiva.wikimedia.org/repository/snapshots/org/wikidata/query/rdf has been regenerated
- https://archiva.wikimedia.org/repository/snapshots/org/wikidata/query/rdf/service/0.3.6-SNAPSHOT/
[x] Build versions of our docker images with the new code
- https://travis-ci.org/wmde/wikibase-docker/builds/608823462
Announce and update final things:
[] Update our test things on labs (and wikibase-registry) that also run this code
[] Create a CVE including details of the fixed versions
[] Announce to wikitech-l/wikidata-l/wikidata-tech/wikibase/telegram
[] Directly contact the people that we know run this GUI in the wild
[] Discuss any further changes to math rendering in {T214980} (public)