Page MenuHomePhabricator

Public wiki replicas contain abuse filter logs for filters that are private or protected
Closed, ResolvedPublicSecurity

Description

The public wiki replicas allow users to see abuse_filter_log rows which are hidden on Special:AbuseLog because they are associated with private or protected filters.

DetailsScreenshot
View of https://en.wikipedia.org/wiki/Special:AbuseLog/38819561 for a logged out user
image.png (537×2 px, 91 KB)
Quarry query that accesses this data on the public wiki replicas (https://quarry.wmcloud.org/history/86560/933247/905627)
image.png (938×2 px, 78 KB)
Steps to replicate the issue
  1. Create a testing filter and mark it as either private or protected
  2. Trigger that filter and note down the ID for the filter log hit
  3. Access the public wiki replica DBs, such as using https://quarry.wmcloud.org/
  4. Query the abuse_filter_log table for the log ID noted down in step 2

What happens?:
The filter log entry that is hidden on-wiki appears on the public wiki replicas

What should have happened instead?:
The filter log should have been hidden, as the associated filter is hidden from public view

Details

Risk Rating
Medium
Author Affiliation
WMF Technology Dept

Event Timeline

Proposed patch:

As discussed on WMF Slack, there is some agreement that simply removing the abuse_filter_log view is the best short-term option given that it's been hardly used on Quarry and toolforge and those usages were > 1 year ago. Plus it also means we can solve T375737 at the same time.

Proposed patch:

As discussed on WMF Slack, there is some agreement that simply removing the abuse_filter_log view is the best short-term option given that it's been hardly used on Quarry and toolforge and those usages were > 1 year ago. Plus it also means we can solve T375737 at the same time.

I'm in favor of this. Patch LGTM.

sbassett subscribed.

+1 to the patch as well. I believe this just needs coordination with an SRE (possibly during their clinic) for a puppet deploy, correct?

I believe this just needs coordination with an SRE (possibly during their clinic) for a puppet deploy, correct?

I've coordinated with SRE on Slack. The idea is that they will upload the patch to gerrit and then deploy immediately after (minimising the time the patch is out in the public eye).

Here is the patch in Gerrit: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1077360
I will merge and deploy, then run the sre.wikireplicas.update-views cookbook straight away.

@DatGuy asked on the #wikimedia-tech IRC channel about why the abuse_filter_log table is no longer present on the wiki replicas. They use the table in their bot https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/DatBot_3

@DatGuy asked on the #wikimedia-tech IRC channel about why the abuse_filter_log table is no longer present on the wiki replicas. They use the table in their bot https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/DatBot_3

AFAIK, DatGuy has been able to get around this issue for now by using the API.

@DatGuy asked on the #wikimedia-tech IRC channel about why the abuse_filter_log table is no longer present on the wiki replicas. They use the table in their bot https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/DatBot_3

AFAIK, DatGuy has been able to get around this issue for now by using the API.

That's probably ok for now, though theoretically that should be locked down as well, if it isn't currently. I think there is also probably a lingering question of making abuse_filter_log publicly available at all.

I will merge and deploy, then run the sre.wikireplicas.update-views cookbook straight away.

@BTullis did you manage to run the cookbook on all replica hosts, or is the change still not applied to the "analytics" replicas, because of the issue with active sessions holding locks on the db?

Related: T300427#10211582

I will merge and deploy, then run the sre.wikireplicas.update-views cookbook straight away.

@BTullis did you manage to run the cookbook on all replica hosts, or is the change still not applied to the "analytics" replicas, because of the issue with active sessions holding locks on the db?

Related: T300427#10211582

@BTullis bumping this question, so we could try to close out this task soon.

I have a tool that use that table, now the tool is broken: https://ptwikis.toolforge.org/Filters

They created a topic in enwiki Village Pump because of that, many users use the tool to analyze filters actions.

For some reason, dewiki still have the table and you can see what the tool does.

sbassett assigned this task to Dreamy_Jazz.

@sbassett can we make this task public? There is some discussion related to this task at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Edit_filter_graph_links_broken.

Sure, since it's mitigated in production now, though likely not the permanent solution. I think we'd probably need Privacy Engineering or a similar resource to evaluate how we can allow the table in replicas going forward, but I know they're extremely backlogged at the moment.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Oct 29 2024, 3:26 PM
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.

Are we sure that the replicas have been fully updated? My last understanding of this is that not all the wiki replica DBs were properly updated.

fnegri claimed this task.

@Dreamy_Jazz Ben is out this week, I will assign to myself and double check that the analytics replicas are up to date.

If it's just the analytics replicas that were (potentially) remaining, I'd classify those as low-risk.

fnegri lowered the priority of this task from High to Medium.Oct 29 2024, 3:37 PM

@Dreamy_Jazz Ben is out this week, I will assign to myself and double check that the analytics replicas are up to date.

Thanks!

If it's just the analytics replicas that were (potentially) remaining, I'd classify those as low-risk.

Sure, just wanted to avoid resolving the task without being sure that everything was done for this.

Are we sure that the replicas have been fully updated? My last understanding of this is that not all the wiki replica DBs were properly updated.

That's a good point. Given that the tool is still able to access data for dewiki (https://ptwikis.toolforge.org/Filters:dewiki), that implies that the table is still accessible for some number of wiki replicas.

fnegri raised the priority of this task from Medium to High.Oct 30 2024, 3:57 PM
fnegri added a parent task: Restricted Task.Oct 30 2024, 4:00 PM
fnegri moved this task from In progress to Done on the cloud-services-team (FY2024/2025-Q1-Q2) board.

I did manually run maintain-views --all-databases --clean --replace-all on all clouddb hosts. As expected, it failed a few times in analytics hosts because of running queries causing locks (fixing this is tracked in T300427: Automate maintain-views replica depooling). For now, I resolved it by manually depooling the affected host, and manually killing the running queries that were causing the locks.

All views should now be up to date with the definitions in the maintain-views.yaml file, across all clouddb* hosts.