﻿id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
6014	Hook needed on wp_dropdown_roles() to secure 'edit_users' capability (see last comment)	jeremyclarke	jeremyclarke	"This is only relevant if you are using the 'role manager' plugin to modify caps, but if a role or user is given the 'edit_users' capability using role manager, they are able to change the roles of existing users to anything they want, even if the new role is above their user level. 

Thus an 'editor' who is given the edit_users cap so they can create new user accounts for new 'authors' is able to make themselves or anyone else and 'administrator' (or assign individual capabilities such that the same effect is achieved). 

This is obviously disastrous from a security perspective, and after having our system compromised this bug was exploited by our attackers to create new admin users (and promote inactive accounts to administrator status) for their various nefarious purposes. 

The expected behavior, IMHO, is that a user can alter other users to NO HIGHER than their current level, and simililarly that they can not add any capability to a user that they do not have themselves. 

On a deeper level, it seems like they should only be able to assign roles and capabilities BELOW their current level (e.g. an editor could create and modify 'authors', but not editors or admins). However I understand that the intricacies of controlling priviliges at that level is so complicated it's probably not worht attempting. 


A basic fix would need to alter the user editing scripts such that:

	- when loading the user profile edit page it checks the privileges of the logged-in user 
	- if the edited user has a role ABOVE the logged-in user the logged-in user just gets an error (they should not see the edit link on the listing screen in the first place). 
	- the list of roles and capabilities displayed to the logged-in user are truncated to only show those that the user already has access to themselves. 
	- on execution, the script checks that the logged-in user has correct priviliges to be making that change to the privileges/role of the edited user. 
	
Let me know if this is a duplicate or something. I searched and coudlnt' find anything about this problem. 	

"	defect (bug)	closed	high		Security		major	duplicate		jeremyclarke
