Page MenuHomePhabricator

Suppressed username included in the Wiki Replicas
Closed, ResolvedPublicSecurity

Description

T259212#6386182 gives the enwiki user id for a user that is globally locked and suppressed. The corresponding username is visible in the Wiki Replicas.

MariaDB [enwiki_p]> select user_id, user_name from user where user_id = 39840215;
+----------+-----------------------------------------+
| user_id  | user_name                               |
+----------+-----------------------------------------+
| 39840215 | <redacted to not leak when made public> |
+----------+-----------------------------------------+
1 row in set (0.01 sec)

Special:BlockList and Special:Block do not show a local block when the username is entered but links to the global lock. I then see There is no global account for "<redacted to not leak when made public>" on the linked Special:CentralAuth page on metawiki.

The username is properly hidden on Special:ListUsers and when querrying using the API: https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=users&ususerids=39840215.

Details

Author Affiliation
Wikimedia Communities

Event Timeline

JJMC89 renamed this task from Suppressed username inclided in the Wiki Replicas to Suppressed username included in the Wiki Replicas.Aug 14 2020, 7:08 PM

I can confirm as steward that the username reported is locked and suppressed via CentralAuth, and appears blocked on individual projects as well as part of the lock+suppress option.

However when checking the enwiki block settings for that account as applied via CentralAuth there's a divergence:

  • enwiki: visiting Special:BlockList, there's no block despite CentralAuth reporting an indef. one.
  • metawiki: visiting Special:BlockList for that account reveals a block, checking the Special:Block page it has the correct settings.
  • loginwiki: same as enwiki.

So I am not sure what's going on here. Is CentralAuth failing to properly propagate suppression/hideuser blocks for globally suppressed accounts?

So I'm not sure the blocks

Indeed seems to be a case of blocks not propagating properly?

Querying the blocks for enwiki, metawiki and loginwiki for the account via API, it returns the following:

enwiki
{
    "batchcomplete": "",
    "query": {
        "blocks": []
    }
}
metawiki
{
    "batchcomplete": "",
    "query": {
        "blocks": [
            {
                "id": 266733,
                "user": "[REDACTED]",
                "by": "Meta>MusikAnimal",
                "timestamp": "2020-07-29T04:10:51Z",
                "expiry": "infinity",
                "reason": "Globally suppressed by MusikAnimal for following reason: Long-term abuse",
                "nocreate": "",
                "autoblock": "",
                "noemail": "",
                "hidden": ""
            }
        ]
    }
}
loginwiki
{
    "batchcomplete": "",
    "query": {
        "blocks": []
    }
}
MarcoAurelio added a subscriber: Tchanders.

Boldly tagging CentralAuth as it looks the extension is having troubles inserting the correct blocks in the wikis?

Ping to @Tchanders who fixed the related bug mentioned on top of this Task, and @ST47 - Re T259212#6386122; no, there's no block despite the UI telling us there's one. See the API reporting above.

I am finding the same issue on eswiki re UID 5932462 there:

  • Locked and suppressed via CentralAuth.
  • CentralAuth says there's a local block.
  • API and BlockList says there's none:
eswiki
{
    "batchcomplete": "",
    "query": {
        "blocks": []
    }
}

This ticket is a more general problem. The username of user ID 39831648, which IS both locally and globally hidden, is ALSO present in the toolforge replica.

MariaDB [enwiki_p]> select user_id, user_name from user where user_id = 39831648;
+----------+----------------------------------------------------------------------------+
| user_id  | user_name                                                                  |
+----------+----------------------------------------------------------------------------+
| 39831648 | <privacy sensitive information redacted> |
+----------+----------------------------------------------------------------------------+
1 row in set (0.00 sec)

I would guess that the toolforge replicas are not presently redacting the usernames of any hidden users.

I would also guess that Quarry is revealing this information, but obviously don't try it because Quarry queries are logged publicly.

This specific ticket relates to hidden usernames appearing in replicas. I would suggest that we continue the discussion of whether blocks are correctly being inserted in T259212, in order to keep this ticket clear for the wiki replicas team.

If the username is suppressed IIRC the name gets removed from the replicas. The problem seems that those hideuser blocks done from Meta ain't being correctly inserted, and therefore they'll keep appearing on the replicas until properly blocked locally (which it worked fine until recently).

Rxy closed this task as a duplicate of Restricted Task.Aug 17 2020, 8:41 AM

The core issue seems to be T260485.

T260485 does seem to be the cause of what @MarcoAurelio found in T260455#6386962.

But this task's duplicate {T205460} has been open since 2018, whereas the actor ID problem seems to have begun in 2019, according to T260485#6389423.

I would guess that the toolforge replicas are not presently redacting the usernames of any hidden users.

I would also guess that Quarry is revealing this information, but obviously don't try it because Quarry queries are logged publicly.

This specific ticket relates to hidden usernames appearing in replicas.

I agree this seems to be a separate problem that predates the actor ID problem.

There's been a proposed patch at T169097#3416962 to tighten up various data issues with maintain-views.yaml, which I believe is the source of record for most dumps, definitely for toolforge/cloud applications. Due to various transitions and priority changes within the Security-Team, I'm not certain when a full re-review might happen, so I proposed a simplification at T169097#6391100.

tstarling added a subscriber: tstarling.

Please confirm that this is fixed. If so, mark resolved and remove the custom policy.

I reopened this task on the basis that it describes leakage of usernames into the toolforge replica due to T260485, whereas T205460 is a catch-all failure mode. I would like someone to confirm that the T260485 aspect is resolved.

The three test cases in this task are fixed.

I reopened this task on the basis that it describes leakage of usernames into the toolforge replica due to T260485, whereas T205460 is a catch-all failure mode. I would like someone to confirm that the T260485 aspect is resolved.

The test cases mentioned in this task are fixed - I don't see user ID 39840215 in Toolforge replica, but I still see that user in production database. Given no PII is discussed here, I'm going to publish this task.

Urbanecm changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 13 2020, 1:08 PM
Urbanecm changed the edit policy from "Custom Policy" to "All Users".