CVE-2019-16738: ⚓ T230402 Exposed suppressed username via Special:Redirect

**

Exposed suppressed username via Special:Redirect

Closed, ResolvedPublicSecurity

**

• Problem: Special:Redirect/user/NNN does not check target user_id’s suppressed status.

• Step to reproduce :

1. 1. Go to Special:Redirect
   2. Make sure Lookup: type is User ID
   3. Entry Value: in optimal numbers. e.g. increase user_id until finding not listed entry at Special:ListUsers
2. Directly link as [[Special:Redirect/user/SUPPRESSED_USER_ID]] replace SUPPRESSED_USER_ID for optimal numbers.
3. Actual Results: Redirect to suppressed user’s user page .
4. Expected Results: Forbid redirecting to suppressed username.

• Task Graph
• Mentions

Event Timeline

Comment Actions

@Rxy - a couple of thoughts:

1. So this patch just prevents a Special:Redirect based upon the numerical user_id of a hidden user, correct? I believe the User: pages of hidden users are still publicly-viewable if they exist (i.e. they don’t display the User account “xxx” is not registered. error message.) The intention here is to throw an error if anyone tries to Special:Redirect to them, to prevent some information disclosure, correct?
2. I’m not sure the hideuser permissions error message makes sense within the context of a Special:Redirect:

You do not have permission to block a username, hiding it from the public…

as it seems to be more directed at users with that permission as opposed to someone trying to visit a redirect. I agree that’s the right permission to check but I might recommend something like this for throwing a more relevant error message:

throw new ErrorPageError( 'badaccess-group0’, ‘badaccess-group0’ );

Otherwise, I think this seems fine and I can security-deploy it whenever, though honestly I’d view this more as a hardening measure that could probably be done in gerrit.

Comment Actions

1. Yes, It is correct. If who knew hideuser-ed user name, they can directly access to user page or they can check account existence via trying account creation. I guess no need to shown message User account “xxx” is not registered… The patch is prevent leaks hideuser-ed account name who aren’t know hideuser-ed account name by trying increase user_id.

2. Here is Patch Set 2:

Thanks for reviewing.

Comment Actions

I’m deploying this now through gerrit. Will make this task public once deployed.

Comment Actions

Hmm, this is the second issue with revdel & Special:Redirect :( [The other one being T187638]. Guess we need to be careful with this page

Comment Actions

@Reedy - CVE requested. I’ll post here when they send over the ID, then we can definitely resolve this task. Is there a specific date/time this week you were thinking about for the new release and announcements?

Comment Actions

@Legoktm - I think there was some confusion on my part here as I had originally just done this as a code-hardening measure in gerrit (T230402#5416849) since it was some lightweight information disclosure, and for information findable in other ways via trivial User: namespace searches, our data dumps, etc. Then @Reedy mentioned getting a CVE for it in T225160, which I thought I’d just do for good measure. And we still aren’t tracking this task on the current security release tracking bug: T225152. If we want to protect any security-related bug for core (and bundled extensions?) going forward, even low/info disclosure issues like this, then I can do that. Though we’d probably want to update our security release doc (1, 2) to emphasize this point or provide some basic guidance around what types of security patches should remain protected until an official security release.

Comment Actions

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user’s information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I’ve been given until Oct 5 to resolve this vulnerability. Thanks in advance.

Reedy raised the priority of this task from High to Needs Triage.Sep 22 2020, 4:29 PM

Reedy set Security to Software security bug.

Reedy changed the visibility from "Public (No Login Required)" to "Custom Policy".

Reedy changed the subtype of this task from “Task” to "Security Issue".

Comment Actions

Per comment

Reedy reopened this task as Open.Sep 22 2020, 4:32 PM

Reedy triaged this task as High priority.

Comment Actions

Can someone test this in WMF prod/master?

I’m interested if this is still is replicable there… Or whether something regressed?

The REL1_34 patch would’ve been master at the time

Comment Actions

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user’s information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I’ve been given until Oct 5 to resolve this vulnerability. Thanks in advance.

Looks like I misread a bit. The code fixed the redirect, but you have to have suppressed/’hide’ the users

The userright you need is hideuser, which isn’t default assigned to the sysop group.

There is a ‘suppress’ group

# $wgGroupPermissions[‘sysop’][‘deletelogentry’] = true; # $wgGroupPermissions[‘sysop’][‘deleterevision’] = true; // To hide usernames from users and Sysops $wgGroupPermissions[‘suppress’][‘hideuser’] = true; // To hide revisions/log items from users and Sysops $wgGroupPermissions[‘suppress’][‘suppressrevision’] = true; // To view revisions/log items hidden from users and Sysops $wgGroupPermissions[‘suppress’][‘viewsuppressed’] = true; // For private suppression log access $wgGroupPermissions[‘suppress’][‘suppressionlog’] = true; // Basic rights for revision delete $wgGroupPermissions[‘suppress’][‘deleterevision’] = true; $wgGroupPermissions[‘suppress’][‘deletelogentry’] = true;

So it’s that, or you need to do

$wgGroupPermissions[‘sysop’][‘hideuser’] = true;

Then, from memory, when you block, there is a check box to suppress/hide the username

See also https://www.mediawiki.org/wiki/Manual:User_rights

Also https://www.mediawiki.org/wiki/Help:Blocking_users

Hide username from edits and lists: When selected, the blocked username or IP address will not be added to the block log, the active block list, or the user list. Other users with the ability to view these hidden entries will still be able to see and unblock the username or IP address. This option is not enabled in a default installation of MediaWiki; the person putting the block in place must have the hideuser permission. See Manual:User rights.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or 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