Description
Reproduce:
- Try to create an page named "Google.123.html" (https://test.wikipedia.org/w/index.php?title=Google.456.html&action=edit) - it's not possible because the rule in https://meta.wikimedia.org/wiki/Title_blacklist
- Now, we redirect https://test.wikipedia.org/w/index.php?title=Test001&redirect=no to "m:Google.123.html"
- Edit Test001 using API with "redirect=1"
- Now we created a local page "Google.123.html" that can be edited by anyone
Probably it can be used to circumvent <noedit> restriction.
Related Objects
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Reedy | T233494 Release MediaWiki 1.31.6/1.32.6/1.33.2/1.34.0 | |||
| Resolved | Reedy | T233495 Tracking bug for MediaWiki 1.31.6/1.32.6/1.33.2/1.34.0 security release | |||
| Resolved | Anomie | T239466 Possible to circumvent title-blacklist (CVE-2019-19709) |
- Mentioned In
- T233495: Tracking bug for MediaWiki 1.31.6/1.32.6/1.33.2/1.34.0 security release
T240393: Tracking bug for MediaWiki 1.31.7/1.33.3/1.34.1
T239428: API edit on page with non-resolvable redirect and redirect=1 creates page with invalid title - Mentioned Here
- T233495: Tracking bug for MediaWiki 1.31.6/1.32.6/1.33.2/1.34.0 security release
T240393: Tracking bug for MediaWiki 1.31.7/1.33.3/1.34.1
T239428: API edit on page with non-resolvable redirect and redirect=1 creates page with invalid title
Event Timeline
It seems likely that fixing T239428: API edit on page with non-resolvable redirect and redirect=1 creates page with invalid title will also fix this.
Yes, that's indeed the case. TitleBlacklist thinks the page being created is "w:Google.123.html", which doesn't match the specific rule in question. Rules beginning with , like most on the current blacklist, do not seem able to be bypassed in this manner since the will match the spurious interwiki prefix.
See https://gerrit.wikimedia.org/r/c/mediawiki/core/+/554084, which incidentally fixes this while fixing T239428.
@sbassett: I'm backporting the fix for this to Wikimedia sites now. I'll leave it to your team to backport the fix to 1.34 and earlier, if you feel that would be desirable.
@Anomie - sounds good, I can try to pick 554084 to each supported release branch and see how it goes. I might solicit some help if those are more complicated than what gerrit can handle. I'm going to make this task public now since the code is on master, wmf.5 and wmf.8 and has been deployed. This probably warrants a CVE as well.
Update: Picked to supported release branches and the bot updates are on the other bug (T239428). There was a minor conflict in for each of these, so I kept the old conditional instead of the newer ternary operator statement for now. Patches tested fine, they just need a +2, which I'll do if nobody else does.
This was kind of a strange one in that it was technically a security issue that was incidentally fixed by a well-timed, separate public task/patch. @Reedy is tracking it for the next release in T233495, but it wasn't "held" due to the aforementioned process oddities. I'll still request a CVE and update this bug once I have it.
Do we know what MediaWiki version this was introduced in?
At a quick glance, I don't see any indication that the bug has ever not existed since the parameter was added in MW 1.17. But I haven't actually tested.
