CVE-2022-29547: ⚓ T9061 CreateRedirect has weak (no?) permissions checks

Event Timeline

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.Mon, Apr 11, 02:47

Comment Actions

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.

Comment Actions

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.

Comment Actions

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.

Comment Actions

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.

Comment Actions

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

Comment Actions

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

Comment Actions

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.

Comment Actions

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.

Comment Actions

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.

Comment Actions

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

Comment Actions

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.

Comment Actions

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)

Comment Actions

@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.Wed, Apr 13, 15:49

Comment Actions

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.

Comment Actions

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.

Comment Actions

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

Comment Actions

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?

Comment Actions

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?

Comment Actions

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.

Comment Actions

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

Comment Actions

@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

Comment Actions

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.

Comment Actions

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?

Comment Actions

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.

Comment Actions

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.

Comment Actions

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