Privilege Escalation Vulnerability in File Upload handling

[doit-cu]

Description:
It is possible to upload and execute arbitrary PHP code via the inline uploads section of the write posts area. This can lead, among other things, to privilege escelation.

Exploit:
Please contact webmaster@… if you require a working proof of concept. This proof of concept makes all users of any wordpress 2.0 installation administrators. I will not release this code until this problem has been addressed. Exploit code will only be provided to those working on solving the problem; otherwise, don't ask.

Solution:
Possible work around is to do a RemoveHandler in an .htaccess file in the uploads directory: RemoveHandler .php for instance. However, if you have defined more than just .php as PHP code in an apache configuration, you will need to add those filetypes to the RemoveHandler directive.

Better solution is to disallow uploading of PHP handled filetypes unless the wordpress user is an administrator.

(In [3444]) Don't allow uploading PHP files, fixes #2300.

What other file types should we block?

You may want to consider using mimetype directives in a .htaccess file in UPLOADS to supplement this solution. For example:

ForceType text/plain

<Files ~ "\.gif">

ForceType image/gif

</Files>

<Files ~ "\.jpe?g">

ForceType image/jpeg

</Files>

...

This way you don't have to worry about people who have configured apache to recognize htm, phtml, html, php3, php4, etc, etc, etc files as PHP. Please forgive me if the formatting is not right above, this wiki-formatting thing is new and frightens me.

Thank you for your quick response on this issue, by the way.

doit-cu, thank you for the report and continued suggestions. I don't think WP should be expected to harden the upload dirs as you suggest because our upload handler only allows certain filename extensions, none of which are now handled as PHP in standard installations.

If someone can upload a php4 file, it's because they modified the filename extension whitelist. If someone's server parses .html files as PHP, it's because they modified the default PHP config.

As you are no doubt aware, this vulnerability only affected blogs with users given the roles Author and Editor. These roles were otherwise unable to affect raw PHP code because they lacked the capabilities.

Milestone 2.0.1 deleted