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

[foxly]

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".

[foxly]

Screen Capture of Problem

[wpmuguru]

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

[foxly]

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.

[nacin]

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."