WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#13866 closed defect (bug) (invalid)

No dupe-checking on wp_users.display_name field allows impersonation attack, edge case privilege escalation venerability

Reported by: foxly Owned by:
Milestone: Priority: normal
Severity: major Version: 2.9.2
Component: Users Keywords:
Focuses: Cc:

Description

This is a serious problem with how the wordpress core handles user data.

Wordpress has many different names for the same user. There's user_login, which they can't change, user_nicename, which is essentially the same thing, and display_name.

If display_name is unset, the user_login will be displayed. But if display_name is set, the value in display_name will be displayed.

That means if a user sets their display_name to say "admin" on either the back-end menu, or on the profile config in BuddyPress, their name will be displayed as "admin" *everywhere* on the site.

This would be great for a phishing attack. And there are probably some plugins that this could open security holes in as well.

Also: It's possible for more than one user to have the same "display_name".

Attachments (1)

display-name.jpg (126.7 KB) - added by foxly 4 years ago.
Screen Capture of Problem

Download all attachments as: .zip

Change History (6)

foxly4 years ago

Screen Capture of Problem

comment:1 wpmuguru4 years ago

  • Priority changed from highest omg bbq to normal
  • Severity changed from critical to normal

Demoting severity & criticality until steps to reproduce a vulnerability are provided.

comment:2 foxly4 years ago

  • Priority changed from normal to high
  • Severity changed from normal to major
  • Summary changed from No dupe-checking on wp_users.display_name field causes serious venerability to No dupe-checking on wp_users.display_name field allows impersonation attack, edge case privilege escalation venerability

WHY THIS IS A PROBLEM

Firstly, its a venerability because, as shown in the screen capture, it allows an attacker to impersonate any user they want, potentially tricking users into doing bad things.

Secondly, it's a venerability because if:

1) You have a plugin that maps user names back to their numeric User ID's
2) The plugin uses display_name instead of user_login as the source of the name string.
3) User #1 with user_login == "X" exists on the system
4) User #2 sets their display_name == "X"
5) The plugin now thinks User #2 == User #1

TO REPRODUCE #1:

1) Install WPMU 2.9.2
2) Install BuddyPress
3) Create two users.
4) Ensure "User Profiles" are activated.
5) Login with first user.
6) Go to Profile->Edit Profile and set the "Name" field to "Admin"
7) Login with second user.
8) Go to Profile->Edit Profile and set the "Name" field to "Admin"
9) You now have two users that display as "Admin" across the entire site.
10) Note that this is not a defect with BuddyPress. The plugin trusts WordPress to provide "safe" display names.

TO REPRODUCE #2:

1) Find a plugin or template that uses a SQL statement like "SELECT ID FROM " . CUSTOM_USER_TABLE . " WHERE display_name = %s". There are like 10,000 plugins for WordPress, somebody somewhere has to be doing this.

2) Install that plugin on a WordPress system.

Method A - (requires admin access)

3) Create a second account on the system.

4) Using the second account, go to Site Admin->Users and edit a user.

5) Change the display name to "admin", and save.

6) Plugin now thinks second account is the original admin account.

Method B - (does not require admin access)

3) Install BuddyPress (or ANY other plugin that lets users set display_name)

4) Sign up a new user.

5) Go to Profile->Edit Profile and set the "Name" field to "admin"

6) First plugin now thinks second user is admin.

HOW TO FIX THIS PROBLEM

In the WordPress core, do not let the function that sets display_name change its value to one which matches the user_login or display_name of another user on the system.


comment:3 nacin4 years ago

In the WordPress core, do not let the function that sets display_name change its value to one which matches the user_login or display_name of another user on the system.

I strongly disagree with that, nor does it scale well. You can easily write a plugin that does this, or simply rejects "Admin."

comment:4 nacin4 years ago

  • Keywords security exploit spoofing display_name removed
  • Priority changed from high to normal

comment:5 nacin3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.