[wp-trac] [WordPress Trac] #13866: No dupe-checking on wp_users.display_name field allows impersonation attack, edge case privilege escalation venerability (was: No dupe-checking on wp_users.display_name field causes serious venerability)

[WordPress Trac]

#13866: No dupe-checking on wp_users.display_name field allows impersonation
attack, edge case privilege escalation venerability
--------------------------+-------------------------------------------------
 Reporter:  foxly         |       Owner:                                          
     Type:  defect (bug)  |      Status:  new                                     
 Priority:  high          |   Milestone:  Unassigned                              
Component:  Users         |     Version:  2.9.2                                   
 Severity:  major         |    Keywords:  security exploit, spoofing, display_name
--------------------------+-------------------------------------------------
Changes (by foxly):

  * priority:  normal => high
  * severity:  normal => major


Comment:

 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13866#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software