As I can see the problem comes from this span that is useless :

<span id="La_page_«_<a href=" w="" index.php?title="Mussola_pintada_test&amp;redirect=no&quot;" class="mw-redirect" title="Mussola pintada test">Mussola pintada test_»_a_été_renommée_en_«_<a href="/wiki/Mussola_pintada" title="" id="movepage-newlink">Mussola pintada</a>_»"&gt;</span>

Without this code the page is good.

There probably isn't a security issue here, but that misparsed HTML looks scary (similar to XSS issues I've seen), so let's make this private for now.

This looks like it might be a problem with the new HTML5 ID encoding? T152540

Note this wikitext in the affected overridden message https://fr.wikipedia.org/w/index.php?title=MediaWiki:Movepage-moved&action=edit:

<h2 class="aa-titre-bleu">La page « $1 » a été renommée en « $2 »</h2>

($1 and $2 are apparently HTML links there)

The ID of the <span> inside <h2> is generated based on these contents and not escaped.

In T176247#3628372, @matmarex wrote:

There probably isn't a security issue here, but that misparsed HTML looks scary (similar to XSS issues I've seen), so let's make this private for now.

While I wasn't able to find any way to exploit the specific instance of this issue presented here, in the past similar issues regarding marker replacement inside attributes have definitely been exploitable, so I agree this bug should be private until fixed just in case.

In T176247#3629728, @MaxSem wrote:

Confirmed, this is caused by HTML5 sections, currently in cache population mode in WMF production. What's happening is that although the attributes are getting properly escaped, in 'html5' fragment mode $ is getting inserted verbatim, so Message::rawParams() later replaces $1 and $2 with HTML in attributes.

A reactive solution would be to replace $ with an entity in Linker::makeHeadline(), however this just highlights the danger of combining user-supplied data with message parameter substitution, so a more proactive solution in general might be needed. What do our security people think?

This reminds me a lot of the parser strip marker issue (7e4a134f49). In that issue, we changed replacement markers to include quote characters, so that if any of them end up in attributes, the attribute escaping would prevent parameter substitution. I think a similar approach would be best here to handle the issue generically, so that we know the issue is fully fixed.

To that end, I suggest a patch like:

@Bawolff, this patch fixes this particular issue, however it completely breaks e.g. Special:Log.

Hmm, replacing $ with &#36; in the patch fixes logs, however I suspect it will still break in escaped() mode - probably worth trying \1 (binary one) as it'll get normalized garbled from input by MW and thus should be impossible for attacker to inject.

Hmm no - parser garbles it too :P

In T176247#3632968, @MaxSem wrote:

@Bawolff, this patch fixes this particular issue, however it completely breaks e.g. Special:Log.

Good catch. This sort of replacement doesn't work with ->escaped() messages, since the entire thing is escaped so it stops all replacements, which is not what we want. Luckily its not really needed for any of the formats other than ->parse() and ->parseAsBlock().

Try #2 where we don't do parameter mangaling for ->escaped():

There is starting to be user feedback on frwiki.
Maybe we can temporary modify the local Mediawiki:Movepage-moved page and replace the h2 tag by pure wikitext? Is it okay to publicly edit this page ? Should we hide this edit ?
Perhaps the best thing is that a Staff account does it directly.

Its fine to publically edit mediawiki:movepage-moved as a temporary work around until this bug is fixed.

Note that the == == syntax for heading won't work either.

@Framawiki I suggest you change the h2 tags to big.

This patch appears to not break anything, I'll deploy it tomorrow. @Bawolff, what should be the disclosure? Since it's not exploitable, is it safe to push to Gerrit and backport?

Thats a good question. Its kind of a borderline case - there could be some other place in mediawiki where it is exploitable. Id prefer to keep it redacted until the next security release just in case.

I think that the patch causing the issue (non-URL-encoded HTML5 IDs) was not in any stable release yet, though?

In T176247#3641661, @matmarex wrote:

I think that the patch causing the issue (non-URL-encoded HTML5 IDs) was not in any stable release yet, though?

I assume it would also apply to old wgExpermintalHtml5Ids which was something like mediawiki 1.16. But im not so worried about this specific example as the general issue. Presumably extensions might do things that are actually vulnerable (admittedly you have to have a pretty specific situation to exploit. The attacker needs to have a normal parameter that they can inject wikitext to and a rawParameter where they either have control of the value of the first attribute or can inject a " character.

Patch deployed.

AIUI this is the last task blocking 1.30? If this bug is only present in unreleased versions of MediaWiki can the patch be published?

In T176247#3700936, @Legoktm wrote:

AIUI this is the last task blocking 1.30? If this bug is only present in unreleased versions of MediaWiki can the patch be published?

I think so. Sooner we get this in the branch the better.

Are we going ahead with the patch as is then?

The problem is solved on frwiki as I can see. Can we change the view of this task ?

In T176247#3733185, @Framawiki wrote:

The problem is solved on frwiki as I can see. Can we change the view of this task ?

No, because the patch hasn't been made public yet. That will happen after it's released in the next set of security releases and the patches made public into the git repos. The task will be opened up after

Cherry pick applies cleanly 1.29, 1.30 and master

Looks like https://github.com/wikimedia/mediawiki/commit/b0784a8e964c4ad435b5e9bc88393a89dbabcf75 being missing from 1.28 causes a conflict...

I don't think we should worry about backporting that...

Can someone sanity check the 1.27/1.28 patches?

This is CVE-2017-8811

1.28 and 1.27 had a minor issue with a constant that wasn't yet introduced (I checked 1.29 too and it was fine). New versions:

Change 391421 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_30] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391421

Change 391421 merged by Reedy:
[mediawiki/core@REL1_30] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391421

Change 391413 merged by Ejegg:
[mediawiki/core@fundraising/REL1_27] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391413

Change 391451 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@master] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391451

Change 391451 merged by Reedy:
[mediawiki/core@master] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391451

Change 391720 had a related patch set uploaded (by Chad; owner: Brian Wolff):
[mediawiki/core@wmf/1.31.0-wmf.8] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391720

Change 391720 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.8] SECURITY: Ensure Message::rawParams can't lead to XSS

https://gerrit.wikimedia.org/r/391720