Confluence allows its users to specify a "Profile Picture," an image that appears on many pages related to the user. A user can either upload a custom image, or select one from a set provided by Confluence. Confluence uses the /users/doeditmyprofilepicture.action path to process requests to change a user's Profile Picture.

The doeditmyprofilepicture.action hander does not sufficiently validate the contents of the userProfilePictureName parameter, however. While Confluence does check the parameter to ensure that it begins with "/images/icons/profilepics/", which is the path to the built-in set of images, it does not reject ".." and similar strings. As a result, a user can use directory traversal to specify any URL on the Confluence web server as his or her Profile Picture.

Many (all?) Confluence administrative tasks can be accomplished using GET requests, so there are URLs on the Confluence web server that correspond to many administrative tasks. For example, this path:

/admin/users/adduserstogroup.action?usersToAdd=joeschmo&membersOfGroupTerm=confluence-administrators

Adds user joeschmo to the Confluence administrators group.

In order for an attacker to gain administrative access, then, all he or she must do it specify the appropriate adduserstogroup.action URL as a Profile Picture, and wait for an administrator to view a page that displays the Profile Picture. It should not be a very long wait, since many pages fit that description.

While Confluence 3.0 does not fix the validation of the userProfilePictureName parameter to doeditmyprofilepicture.action, it does
contain cross-site request forgery protection that makes exploiting it much more difficult.

All requests that actually "do things" require an additional parameter called atl_token, which is randomly generated and tied to a specific session. Without knowledge of their values for this parameter, it is not possible to cause other users to carry out actions when viewing a page with your Profile Picture.

See also a draft security advisory I would eventually like to release:

http://userwww.service.emory.edu/~ekenda2/EMORY-2009-02.txt