In T9061#183507, @Reception123 wrote:

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

In T9061#183509, @Reception123 wrote:

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.

Not seen since backups disabled

In T9061#183509, @Reception123 wrote:

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.

In T9061#183454, @Universal_Omega wrote:

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.

Status?

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.

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

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

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.

In T9061#183454, @Universal_Omega wrote:

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.

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.

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

test101 having the issues also seemed very strange to me seeing as how it currently didn't even work, as it is down right now.

In T9049#183324, @RhinosF1 wrote:

In T9049#183296, @MacFan4000 wrote:

There is a bit of a pattern with these outages, both times test101 was also affected, and both times it was at the same time of day. (roughly 8:00 PM EST/0:00 UTC)

I'm not sure how related test101's issues are.

This was an observation made by @Universal_Omega

In T9049#183296, @MacFan4000 wrote:

There is a bit of a pattern with these outages, both times test101 was also affected, and both times it was at the same time of day. (roughly 8:00 PM EST/0:00 UTC)

It's very strange to happen exact same time.

I've had a quick glance through traffic patterns and there's no spike in actual requests. It must be something being accessed but no hint as to what.

In T9049#183315, @RhinosF1 wrote:

This is a DOS

https://grafana.miraheze.org/d/dsHv5-4nz/mediawiki?orgId=1&from=1649366728843&to=1649489031546 shows a ten-fold jump in connections active at the same time

This is a DOS

In T9018#182556, @RhinosF1 wrote:

No

No

In T9018#182554, @RhinosF1 wrote:

Still waiting for GitHub to issue the CVE

Still waiting for GitHub to issue the CVE

In T9018#182551, @RhinosF1 wrote:

https://github.com/miraheze/CreateWiki/security/advisories/GHSA-9xvw-w66v-prvg

https://github.com/miraheze/CreateWiki/security/advisories/GHSA-9xvw-w66v-prvg

I'm proposing that since no one figured this out until now, a solution that wouldn't require extension changes (which I feel aren't necessary since there's been no occurrences of abuse) is to use wgRevokePermissions. As to not give anything away before being merged, I will merge the PR immediately after CI checks.

In T8990#182067, @Zppix wrote:

In T8990#181927, @Reception123 wrote:

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

When you create the task it gets assigned that for some reason.

In T8990#181927, @Reception123 wrote:

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

Spoke with @Paladox and no further action is needed on this task.

@RhinosF1 Do we still need this task open since the incident has passed?

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

Slightly different issue (I'd raise it elsewhere but I have a meeting I need to get to), but it appears that restricting view access to require "delete" permissions does not work, only restricting access to "createwiki" (I have not checked os).

I'm far less worried about that. It's never caused an issue and it's fairly easy to lock an account. We block 1000s of proxies and can easily block more to reduce the risk of people being able to just change IP.

In T8990#181906, @RhinosF1 wrote:

In T8990#181905, @Universal_Omega wrote:

In T8990#181904, @John wrote:

In T8990#181902, @RhinosF1 wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

I think we should have it check for global blocks only, not local meta blocks I guess, if it doesn't?

If you are globally blocked (from your IP), you can't create an account. If you don't have an account, you can't request a wiki.

In T8990#181905, @Universal_Omega wrote:

In T8990#181904, @John wrote:

In T8990#181902, @RhinosF1 wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

I think we should have it check for global blocks only, not local meta blocks I guess, if it doesn't?

In T8990#181904, @John wrote:

In T8990#181902, @RhinosF1 wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

In T8990#181902, @RhinosF1 wrote:

@John, @Universal_Omega: is this intended or?

It doesn't seem to have any check for blocks.

In T8990#181900, @Reception123 wrote:

@Zppix you mean comment on requests or also create new ones?

It seems interact in general.

@Zppix you mean comment on requests or also create new ones?

NCSC are aware

blocked at firewall level globally, let's keep an eye.

In T8949#181345, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/54

https://github.com/miraheze/RemovePII/pull/54

Has anyone actually reported this upstream? If not I will do so and then proceed to close the task per John's comments

Lowering priority on this, given that users cannot view the suppression log.

In T8928#180522, @Dmehus wrote:

In T8928#180521, @John wrote:

In T8928#180519, @Dmehus wrote:

In T8928#180516, @Agent_Isai wrote:

This is something not fixable by us so assigning upstream tag

That's fair. Thanks. No objection to changing the status to stalled on upstream fix, but I would oppose declining or closing as invalid.

It is actually convention to close upstream tasks that we have no influence over as invalid unless the implementation would require direct action by us in one form or another

That's fair. There's far more invalid tasks, than stalled ones. Any objections to using the stalled reason in this case, on a non-precedent setting basis?

In T8928#180521, @John wrote:

In T8928#180519, @Dmehus wrote:

In T8928#180516, @Agent_Isai wrote:

This is something not fixable by us so assigning upstream tag

That's fair. Thanks. No objection to changing the status to stalled on upstream fix, but I would oppose declining or closing as invalid.

It is actually convention to close upstream tasks that we have no influence over as invalid unless the implementation would require direct action by us in one form or another

In T8928#180519, @Dmehus wrote:

In T8928#180516, @Agent_Isai wrote:

This is something not fixable by us so assigning upstream tag

That's fair. Thanks. No objection to changing the status to stalled on upstream fix, but I would oppose declining or closing as invalid.

In T8928#180516, @Agent_Isai wrote:

This is something not fixable by us so assigning upstream tag

This is something not fixable by us so assigning upstream tag

In T8928#180510, @RhinosF1 wrote:

This isn't a security issue. Comments aren't meant to be restored. Personally, having a private log is probably better than permanent deletion.

Whether this is hacky or appropriate and what's a good UI/X is a debate for upstream.

This isn't a security issue. Comments aren't meant to be restored. Personally, having a private log is probably better than permanent deletion.

As far as I can tell, there is only 1 level of deletion for comments. I'd assume they are never meant to be restored which is why suppression is used.

Can you please place in a private paste exactly what was in the log

Exactly how?