Page MenuHomeMiraheze

CreateRedirect has weak (no?) permissions checks
Closed, ResolvedPublic

Description

Wiki(s) affected: wikiweewiki (for now; to be added as discovered and confirmed)

Issue: This global block, despite being not only a block of anonymous users but logged in users as well, has no effect on the LTA's ability to edit on the wiki today. For greater clarity, this LTA is the same LTA that discovered a bug with the CreateWiki extension and was able to overwrite certain data in certain wiki request columns until the bug was patched (T9018)

I had a Wikimedia Steward (AmandaNP) and @Agent_Isai check the Special:ListGroupRights and Special:Version special pages with me to see if I missed anything glaringly obvious. ipblock-exempt is not assigned to * nor was that IP address locally whitelisted, so doesn't appear to be the case. This Miraheze LTA is also globally blocked on the Wikimedia network of wikis as crosswiki abuse.

In addition, I also double-checked via the CheckUser extension on that wiki to see if the XFF header information was different than the blocked IP. It was not.

It would not surprise me and @Agent_Isai in the least if the LTA has discovered a new bug with the GlobalBlocking extension, but I wanted to check with the MediaWiki SRE team to confirm there are no configuration issues with Miraheze's configuration:

  1. Is $wgApplyGlobalBlocks set to true, correctly, on all Miraheze wikis except for metawiki?
  2. Is $wgGlobalBlockingBlockXFF set to true or false? If the latter, as a Steward, I would certainly endorse setting this to true
  3. Does every wiki have a globalblocking SQL table or have we specified a different SQL table via $wgGlobalBlockingDatabase and have all database users been given the following permissions, SELECT, UPDATE, INSERT, DELETE, at minimum?
  4. Are there any other identifiable configuration errors?

If no issues with the above points, are there any other known or unknown extension conflicts that could be giving us grief and causing an issue? My initial thought focused on this extension. No particular reason, other than I'd not seen it and noticed that Bukkit (no need to add him to this task, please) had granted the bypasstoscheck user right to the founder group but mainly because of the extension's interactions with Special:CreateAccount.

A thorough and rigorous extension conflict check should be done, if possible.

Finally, if still nothing, can you provide additional details useful for raising a GlobalBlocking bug report to Wikimedia?

Thanks so much! :)

Event Timeline

Dmehus triaged this task as High priority.Apr 11 2022, 02:42
Dmehus created this task.

Adding @Raidarr this way since I can't added him via the "Change subscribers" field

Agent_Isai changed the visibility from "Public (No Login Required)" to "Custom Policy".Apr 11 2022, 02:46
Agent_Isai changed the edit policy from "All Users" to "Custom Policy".
Dmehus renamed this task from Investigate why global block for 148.74.235.89 not effective on `wikiweewiki` to Investigate why global block for 148.74.235.89 not effective on wikiweewiki.Apr 11 2022, 02:47
Dmehus updated the task description. (Show Details)
Dmehus moved this task from Backlog to Short Term on the MediaWiki (SRE) board.
Dmehus moved this task from Backlog to Actions Needed (Review) on the Extensions board.
Dmehus moved this task from Backlog to In Progress on the Configuration board.

I thought this could've happened if the globalblock-whitelist right was given, but according to Special:ListGroupRights, * does not have that. So that doesn't seem to be the case, and I'm personally not certain how this was done, unless I'm missing something here.

Universal_Omega removed a project: Configuration.

Also why would bypasstoscheck have absolutely anything to do with GlobalBlocking? I don't see how, and it seems extremely unlikely it would, since that is for sign up pages, and this issue is an anonymous user.

I thought this could've happened if the globalblock-whitelist right was given, but according to Special:ListGroupRights, * does not have that. So that doesn't seem to be the case, and I'm personally not certain how this was done, unless I'm missing something here.

Yeah, that was my first thought also, or if the global block was disabled locally

Also why would bypasstoscheck have absolutely anything to do with GlobalBlocking? I don't see how, and it seems extremely unlikely it would, since that is for sign up pages, and this issue is an anonymous user.

Not specifically that user right, per se, but my thought was since NewSignupPage extension is enabled on that wiki and interacts with one's ability to create accounts, it's possible it's a conflict with that extension, but it could be some other extension conflict also.

If this turns out to be an actual issue, something to check is if ApiEditPage actually checks for global blocks. Which means this may potentially be a core vulnerability, if it is one.

This may or may not be of interest to @Owen, but adding him nonetheless in his Trust and Safety and Board capacities, so he can at least view the task, for a question I've asked him in our #trust-safety channel on Discord

@Dmehus

  1. It is yes, this can be seen via LS.php
  2. Is set to true by default and unmodified for MH
  3. Yes, 'mhglobal' is the global blocking DB
  4. Those are the only two settings we have different than the defaults.

The issue will have to be tested on a test wiki by applying a global block to an IP and identifying potential extensions and them being disabled/enabled until we can conclude which one is causing it.

I thought this could've happened if the globalblock-whitelist right was given, but according to Special:ListGroupRights, * does not have that. So that doesn't seem to be the case, and I'm personally not certain how this was done, unless I'm missing something here.

That's already been tried before and mitigated against.

The issue will have to be tested on a test wiki by applying a global block to an IP and identifying potential extensions and them being disabled/enabled until we can conclude which one is causing it.

Why not check eval.php first https://github.com/wikimedia/mediawiki-extensions-GlobalBlocking/blob/master/includes/GlobalBlocking.php#L78 and the User::UserCan methods might give some insight

The issue will have to be tested on a test wiki by applying a global block to an IP and identifying potential extensions and them being disabled/enabled until we can conclude which one is causing it.

Yeah... I wouldn't prefer to do extension testing on Public Test Wiki, though. This is one of those times when it'd be really still be helpful to have an SRE testing wiki within the existing CentralAuth-linked production wikis.

@Dmehus

  1. It is yes, this can be seen via LS.php
  2. Is set to true by default and unmodified for MH
  3. Yes, 'mhglobal' is the global blocking DB
  4. Those are the only two settings we have different than the defaults.

Thanks. That's what I thought.

The issue will have to be tested on a test wiki by applying a global block to an IP and identifying potential extensions and them being disabled/enabled until we can conclude which one is causing it.

Yeah... I wouldn't prefer to do extension testing on Public Test Wiki, though. This is one of those times when it'd be really still be helpful to have an SRE testing wiki within the existing CentralAuth-linked production wikis.

We can run all permission checks and see what's effecting them via eval.php. There's no need to test it on a wiki at all.

rhinos@mwtask111:~$ sudo -u www-data php /srv/mediawiki/w/maintenance/eval.php --wiki=wikiweewiki
> $title = \TitleFactory::makeTitle('', 'Main_Page', '', '')

Deprecated: Non-static method TitleFactory::makeTitle() should not be called statically in /srv/mediawiki/w/maintenance/eval.php(84) : eval()'d code on line 1

>  $user = \MediaWiki\MediaWikiServices::getInstance()->getUserFactory()->newAnonymous( '148.74.235.89' )

> var_dump(\MediaWiki\MediaWikiServices::getInstance()->getPermissionManager()->userCan('move', $user, $title));
bool(false)

> var_dump($title->isMainPage())
bool(true)

nothing to do with GlobalBlock at all

@Samwilson: It looks like create redirect is at fault. I can move the Main_Page without being able to edit it and the user used that. It looks like you are one of 2 project members. Can you look into this?

RhinosF1 renamed this task from Investigate why global block for 148.74.235.89 not effective on wikiweewiki to CreateRedirect has weak (no?) permissions checks.Apr 13 2022, 15:49
RhinosF1 added a subscriber: Samwilson.

I'm not a member, just watching that project.

I was interested in it because I wanted an easy way to create redirects, so suggested creating a toolbar button in that extension. The author wasn't keen, so in the end I've gone and made Extension:RedirectManager. That extension does (I think!) handle permissions correctly.

Given the risk with the currently layout and how much nicer @Samwilson's looks, if it passed security review, I'd consider replacing CreateRedirect with it.

I mentioned the CreateRedirect error on its talk page (sorry, I didn't realise this was a hidden security task! I shouldn't've advertised it publicly), and it looks like the issue has been fixed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CreateRedirect/+/780567

No problem.

@Dmehus: any issues to making public?

@Universal_Omega: I'd appreciate a security review / opinion on the below as this doesn't fill me with great confidence.

Given the risk with the currently layout and how much nicer @Samwilson's looks, if it passed security review, I'd consider replacing CreateRedirect with it.

RhinosF1 lowered the priority of this task from High to Low.Apr 14 2022, 11:14
RhinosF1 edited projects, added Extensions; removed MediaWiki.

Note: T1140#25572 is original review

My view is that if RedirectManager is very similar to CreateRedirect and does not present the issues that CR does we should replace it.

Pinging @Agent_Isai for his views regarding the community aspects. I'd probably assume a notice with enough time for the community to comment should be sufficient?

My view is that if RedirectManager is very similar to CreateRedirect and does not present the issues that CR does we should replace it.

Indeed, they do appear to be similar but a key difference between both is that CreateRedirect offers a standalone special page while RedirectManager offers it as an plugin to WikiEditor.

I'd probably assume a notice with enough time for the community to comment should be sufficient?

Definitely. A notice can be posted on the CN though I don't know if it'd be possible potentially to get a list of wikis that used this feature to perhaps reach out to them too?

As possible I strongly encourage interfacing with the local wikis. I suspect a lot of traffic that would benefit from an announcement, simply does not pass through Meta or its CN.

Universal_Omega claimed this task.

Extension patched upstream, and updated for us, I will do another full review of the extension, and then hopefully re-enable it.

Is this task ok to be made public?

Universal_Omega changed the visibility from "Custom Policy" to "Public (No Login Required)".Apr 14 2022, 21:31
Universal_Omega changed the edit policy from "Custom Policy" to "All Users".

No problem.

@Dmehus: any issues to making public?

No objections if @John and @Owen have no issues making it public

No problem.

@Dmehus: any issues to making public?

No objections if @John and @Owen have no issues making it public

It already is now.

@Samwilson: It looks like create redirect is at fault. I can move the Main_Page without being able to edit it and the user used that. It looks like you are one of 2 project members. Can you look into this?

@RhinosF1 Thanks for looking into this! Not surprised it was an issue with another extension

No problem.

@Dmehus: any issues to making public?

No objections if @John and @Owen have no issues making it public

It already is now.

Yeah, I mean, I don't know what the protocol is on making Trust & Safety tagged tasks public, but yeah, I guess if SRE is fine with it, that's fine.

I mentioned the CreateRedirect error on its talk page (sorry, I didn't realise this was a hidden security task! I shouldn't've advertised it publicly), and it looks like the issue has been fixed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CreateRedirect/+/780567

@Samwilson No problem! Nothing was especially security sensitive really, and it's apparently been fixed, so that's great. Thanks for looking into this and for communicating with the developer for us. :)

I was directed to this task over IRC. It appears to already be closed, and have little relevance to me at all. What is going on here?

I was directed to this task over IRC. It appears to already be closed, and have little relevance to me at all. What is going on here?

You must've been directed to the wrong task, I'd assume? T9071 is probably what they meant to direct you to, I'm assuming, based off conversation I have observed. But that task is currently private.

I was directed to this task over IRC. It appears to already be closed, and have little relevance to me at all. What is going on here?

You must've been directed to the wrong task, I'd assume? T9071 is probably what they meant to direct you to, I'm assuming, based off conversation I have observed. But that task is currently private.

No, I thought Naleksuh might be interested in the task, so sent him this link.

I was directed to this task over IRC. It appears to already be closed, and have little relevance to me at all. What is going on here?

You must've been directed to the wrong task, I'd assume? T9071 is probably what they meant to direct you to, I'm assuming, based off conversation I have observed. But that task is currently private.

No, I thought Naleksuh might be interested in the task, so sent him this link.

Ok