Page MenuHomePhabricator

Special:UserRights exposes the existence of hidden users (CVE-2020-25813)
Closed, ResolvedPublicSecurity

Description

What is the problem?

If $user is hidden/suppressed by a block, a regular/anon. user can still go to Special:UserRights/$user and see $user's group memberships.

Instead, should it behave as if $user did not exist?

$user will not show up in the prefix search on Special:UserRights. So, I guess you would have to know their exact username already, unless you were very lucky.

Steps to reproduce problem
  1. Login as a user with oversight rights
  2. Go to Special:Block/$user, make an indefinite sitewide block and select "Hide username from edits and lists"
  3. Logout and go to Special:UserRights/$user

Expected behavior: Page should say something like: There is no user by the name "$user". Check your spelling.
Observed behavior: Page has link to $user's User, Talk and Contributions page. Lists $user's group membership.

Environment

Wiki(s): MediaWiki 1.34.0-alpha (f0c2414) 21:03, 10 September 2019 and 1.32.1.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 11 2019, 7:50 AM
DannyS712 claimed this task.EditedDec 2 2019, 8:36 AM
DannyS712 added a subscriber: DannyS712.

@dom_walden would something like:

If $user->isHidden() and the viewer lacks hideuser rights, pretend the user doesn't exist

meet the requirements?

Restricted Application added a project: User-DannyS712. · View Herald TranscriptDec 2 2019, 8:36 AM
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Dec 5 2019, 4:25 AM

Change 556093 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] SpecialUserrights: If a viewer cannot see a hidden user, act as if the user doesn't exist

https://gerrit.wikimedia.org/r/556093

Legoktm set Security to Software security bug.Jul 3 2020, 4:07 AM
Legoktm added projects: Security, Security-Team.
Legoktm changed the visibility from "Public (No Login Required)" to "Custom Policy".
Legoktm changed the subtype of this task from "Bug Report" to "Security Issue".
Legoktm added a subscriber: Legoktm.

Leaking the existence of suppressed/hidden users is a security issue.

@dom_walden: next time, please report issues in which users that don't have the hideuser right can see the existence of hidden users as a security bug.

I'm going to merge Danny's change in a few minutes since it's already public, but it should be included in the next security release. He removed some of the internal refactoring to make it more straightforward to backport (thank you!).

I think this is low priority enough to wait a few days for deployment (at least, I don't want to deploy it alone during a holiday weekend). As far as I can tell, this bug has existed ever since hideuser was introduced (I gave up looking at git log around 2013).

Legoktm renamed this task from Should hidden users' group memberships be shown in Special:UserRights? to Special:UserRights exposes the existence of hidden users.Jul 3 2020, 4:49 AM
Reedy added a subscriber: Majavah.

The merged patch broke the ability to change user rights for users on other wikis (Special:UserRights/Majavah@commonswiki for example), for example see https://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3AUserRights&user=Majavah%40commonswiki. Probably a train blocker.

DannyS712 added a comment.EditedJul 4 2020, 2:17 PM

The merged patch broke the ability to change user rights for users on other wikis (Special:UserRights/Majavah@commonswiki for example), for example see https://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3AUserRights&user=Majavah%40commonswiki. Probably a train blocker.

Yeah, that one is on me - I should have remembered T254417: SpecialUserrights.php: Call to undefined method CentralAuthGroupMembershipProxy::canReceiveEmail(). Patch coming in a second. Since the underlying patch was already merged publically, sending it publically so that master isn't broken, but without an informative commit message

DannyS712 triaged this task as Unbreak Now! priority.Jul 4 2020, 2:25 PM
DannyS712 added a project: Patch-For-Review.
sbassett moved this task from Incoming to In Progress on the Security-Team board.Jul 6 2020, 3:12 PM
DannyS712 lowered the priority of this task from Unbreak Now! to High.Jul 6 2020, 6:15 PM
DannyS712 removed a project: Patch-For-Review.
CCicalese_WMF added a subscriber: CCicalese_WMF.

Untagging, since there is nothing to review right now. Feel free to re-tag if there's a new patch.

@Legoktm I cannot see the parent tasks, but is there anything more to be done here?

Legoktm closed this task as Resolved.Aug 11 2020, 9:04 PM

Nope. Here's a squashed version of the patch to make backporting easier:

Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".
Legoktm renamed this task from Special:UserRights exposes the existence of hidden users to Special:UserRights exposes the existence of hidden users (CVE-2020-25813).Sep 27 2020, 11:50 AM