[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator
Create Task
Maniphest T232568

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

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.

Details

SubjectRepoBranchLines +/-
Fix SpecialUserrights for UserRightsProxymediawiki/coreREL1_31+3 -1
SpecialUserrights: If a viewer lacks `hideuser`, ignore hidden usersmediawiki/coreREL1_31+6 -0
SpecialUserrights: If a viewer lacks `hideuser`, ignore hidden usersmediawiki/coreREL1_34+8 -0
Fix SpecialUserrights for UserRightsProxymediawiki/coreREL1_34+5 -3
Fix SpecialUserrights for UserRightsProxymediawiki/coremaster+5 -3
SpecialUserrights: If a viewer lacks `hideuser`, ignore hidden usersmediawiki/coremaster+8 -0
Customize query in gerrit

Related Objects
Search...

Event Timeline

dom_walden created this task.Sep 11 2019, 7:50 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 11 2019, 7:50 AM
MarcoAurelio subscribed.Sep 11 2019, 9:34 AM
JJMC89 moved this task from Backlog to User list on the MediaWiki-User-management board.Sep 12 2019, 5:44 AM
DannyS712 claimed this task.EditedDec 2 2019, 8:36 AM
DannyS712 subscribed.

@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
gerritbot added a comment.Dec 10 2019, 1:24 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

gerritbot added a project: Patch-For-Review.Dec 10 2019, 1:24 AM
DannyS712 moved this task from Next to Awaiting review and deployment on the User-DannyS712 board.Dec 15 2019, 6:35 AM
DannyS712 added a project: Platform Team Workboards (External Code Reviews).Jun 28 2020, 6:18 AM
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 subscribed.

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

DannyS712 added a project: Vuln-Infoleak.Jul 3 2020, 4:17 AM
Legoktm added a comment.Jul 3 2020, 4:24 AM

@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
Legoktm added a parent task: T256335: Tracking bug for MediaWiki 1.31.9/1.34.3/1.35.0.
Reedy removed a project: Patch-For-Review.Jul 4 2020, 2:03 PM
Reedy added a subscriber: taavi.
taavi added a comment.Jul 4 2020, 2:05 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.

DannyS712 added a comment.EditedJul 4 2020, 2:17 PM
In T232568#6278885, @Majavah wrote:

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.

Train blocker - patch at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/609532

DannyS712 added a parent task: T256668: 1.35.0-wmf.40 deployment blockers.Jul 4 2020, 2:26 PM
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 parent task: T256668: 1.35.0-wmf.40 deployment blockers.
DannyS712 removed a project: Patch-For-Review.
In T232568#6278943, @DannyS712 wrote:

Train blocker - patch at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/609532

Merged

Jdforrester-WMF added a project: MW-1.35-notes (1.35.0-wmf.40; 2020-07-07).Jul 6 2020, 7:20 PM
CCicalese_WMF removed a project: Platform Team Workboards (External Code Reviews).Aug 11 2020, 8:46 PM
CCicalese_WMF subscribed.

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

DannyS712 added a comment.Aug 11 2020, 8:49 PM

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

0001-SECURITY-SpecialUserrights-If-a-viewer-lacks-hideuse.patch1 KBDownload

Reedy mentioned this in T256335: Tracking bug for MediaWiki 1.31.9/1.34.3/1.35.0.Sep 7 2020, 10:28 PM
Reedy mentioned this in T256341: Obtain CVEs for 1.31.9/1.34.3/1.35.0 security releases.Sep 22 2020, 9:41 PM
Jdforrester-WMF edited projects, added MW-1.34-notes, MW-1.31-release-notes, MW-1.35-notes; removed MW-1.35-notes (1.35.0-wmf.40; 2020-07-07).Sep 23 2020, 11:53 AM
Reedy removed a project: MW-1.31-release-notes.Sep 24 2020, 11:16 PM
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
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits