I think we can call this resolved:

• A user can easily bypass any client-side rate limiting and/or fixes we make without server-side rate limits
  • Implementing rate limits are described in T399747: Limit the number of IPs that can be revealed per day, but push back as been received for this. Further discussion on that can be carried out at that task
• We have fixed users being able to bypass on-wiki logging without the associated right via 1abae1d48f75f8b0d53a5a1ff18c549b8a9da68c, which was a Vuln-BrokenAccessControl. This was only a problem in the master branch.
  • We also backported the fix to MW-1.44-release via f678a679a4cec0bb4602f4053ec63a715f4cfa24. However, as noted above this didn't technically fix any security issue with the tool (issues with rate-limits are less of a security issue IMO because any user abusing access would be seen via an inspection of the IP reveal log)

This is resolved with the live hack being committed as https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/927. Thanks again for the report.

Created patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1177991 which is ready for review.

Thanks for the comments! I'll create a backport of the patch I mentioned to REL1.44. It will likely need review because it merge conflicts as it stands quite heavily.

Moving to 'Needs Review' to see if others agree with my proposed direction on this task.

In T397891#11066700, @Dreamy_Jazz wrote:

@sbassett / @Reedy

Given that the fix for this is in the public master branch (fixed through addressing other issues), could we consider publicly backporting the fix to REL1_44 without mentioning it as a security issue? I think this is okay because this is only security issue if:

• Temporary accounts are enabled (marked as an unstable config)
• CheckUser is installed
• The user has the checkuser-temporary-account right (which means by default only users in the checkuser and temporary-account-viewer groups)

In T397891#11061586, @Dreamy_Jazz wrote:

We could update the front-end if we think there is a legitimate case that a user could have auto-reveal mode considered on in the front-end but off in the back-end.

In any case, addressing this would not be fixing a security issue so I would prefer to do this publicly without backporting.

Given that the fix for this is in the public master branch (fixed through addressing other issues), could we consider publicly backporting the fix to REL1_44 without mentioning it as a security issue? I think this is okay because this is only security issue if:

• Temporary accounts are enabled (marked as an unstable config)
• CheckUser is installed
• The user has the checkuser-temporary-account right (which means by default only users in the checkuser and temporary-account-viewer groups)

One additional point. Because this is a security task, we will need to create security backports of the fix in 1abae1d48f75f8b0d53a5a1ff18c549b8a9da68c. We will need to backport it to only REL1_44. In REL1_43 and earlier the feature did not exist (so no backport is needed).

In T397891#11061581, @Tchanders wrote:

Given that T399747: Limit the number of IPs that can be revealed per day seems to be controversial, we should address this task via the Permission checking approaches mentioned in T397891#10954244.

Whoever picks up this task should take some time to decide which approach is best (whether it's one mentioned in that comment or something else).

I already did this AFAICS in 1abae1d48f75f8b0d53a5a1ff18c549b8a9da68c

Given that T399747: Limit the number of IPs that can be revealed per day seems to be controversial, we should address this task via the Permission checking approaches mentioned in T397891#10954244.

The main issue here is that a user with the IP reveal right could reveal many IPs without having to click many times. They could achieve the same effect as auto-reveal by clicking a lot. This in itself is a problem, so we should introduce rate limiting, irrespective of this task. Once we have rate limiting, this won't be as much of a problem any more.

From a security perspective, we support moving forward with adopting CSP policies for these microsites.

Marking as invalid since we were not able to reproduce this issue on our side. Feel free to reopen @Wikinaut if you still see any issues.

@Wikinaut can you verify the reproduction steps that @Jly posted?

I wasn't able to reproduce this. I tested this on a local development of MediaWiki 1.41.0 (8ce0ec5) with an SMTP server. I've captured the raw email logs, and they are being sent correctly to the user. Can you validate the steps below to reproduce the bug, or please share the correct steps:

@Wikinaut We did not try to reproduce in the version that you reported it in, just in 1.44.0. I'll find out if we can reproduce in 1.41.0

@Syed_Azmat_Husain - You could propose a new, public task requesting this functionality. I would probably title it something like "Locally blocked Wikimedia users should not be allowed to reset their passwords on any SUL project" or something like that. Again, whether you agree with it or not, there are reasons for why this is currently allowed and an escalation path for abuse via global block requests. So I do not personally consider this an urgent security issue. There has also been some previous discussion about a related matter in T109909, for additional context.

Thanks for the response. Just to clarify, this isn’t about override logs. The concern is that if a user or IP is *locally blocked* from using "Forgot Password" on English Wikipedia, they can simply go to another project like Urdu Wikipedia and use the same feature. Since Wikimedia accounts are global, the password reset still goes through, bypassing the original block's intent. This seems to be a functional loophole. Should this not be handled?

@Syed_Azmat_Husain - So the way MediaWiki blocks currently work - with local and global IP blocks possible - is very much intentional and by design. I've verified with the global stewards that it does not look like Urdu Wikipiedia has ever overriden any global blocks, according to its logs: https://ur.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:%D9%86%D9%88%D8%B4%D8%AA%DB%81?type=gblblock&user=&page=&wpdate=&tagfilter=&wpfilters%5B%5D=newusers&wpFormIdentifier=logeventslist. If traffic from an IP address or range starts to become an issue on other projects, and a local block or a few local blocks are not enough to stop the abuser, then a global block can and should be requested: https://meta.wikimedia.org/wiki/Global_blocks.