[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 11:33:48 -0400 (EDT)
From: cve-assign@...re.org
To: larry0@...com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Remote file upload vulnerability & SQLi in wordpress plugin wp-powerplaygallery v3.3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> ... It seems that the essence
>> of the problem is that the product could reject unsafe file types such
>> as .php files, but doesn't do that. That can have one CVE ID.
> It should filter out what file types are allowed for uploading at least.
Use CVE-2015-5681 for the issue in which an executable file is not
blocked, and consequently an attacker has the ability to create and
execute arbitrary PHP code, such as at the
/wp-content/uploads/power_play/4_uploadfolder/big/shell.php URI in
your original example.
> The directory creation code in upload.php doesn't create the
> subdirectories big and thumb. These directories are added when a new
> album is created through normal use of the plugin.
Thanks for this additional information. In that case, we feel that it
is best to categorize the:
// Create target dir
if (!file_exists($targetDir)) {
@mkdir($targetDir);
}
code block as, more or less, an authorization bypass. The user of
upload.php has no legitimate need to create a $targetDir directory,
because this directory is usable only if previously created by a
power_play.php code block of:
if( !is_dir( $album_dir ) )
mkdir($album_dir);
if( !is_dir($album_dir . '/big') )
mkdir($album_dir . '/big');
if( !is_dir($album_dir . '/thumb') )
mkdir($album_dir . '/thumb');
The user of upload.php can choose to use directory traversal (as you
mentioned) or can simply create a huge number of directories with (for
example) numeric or alphanumeric $_REQUEST['albumid'] values.
Directory traversal is not an independent primary vulnerability and
cannot have its own separate CVE ID.
Use CVE-2015-5682 for the issue of a superfluous "@mkdir($targetDir);"
line that allows attackers to create arbitrarily many useless
directories via a series of requests.
>> Are you also reporting any authorization problem? Is upload.php
>> responsible for verifying that the client user has the upload_files
>> capability, regardless of what file type is being uploaded?
> I know I wouldn't want arbitrary images uploaded to my Wordpress
> instance from users who aren't logged in.
This was a somewhat philosophical question about WordPress security.
There are no more CVE ID assignments below, but here are our comments
in case anyone is interested.
As far as we can tell, there is no expectation that the author of a
plugin must determine whether the plugin offers a feature associated
with the concept of "uploading files" and, if so, make that feature
available only to users who have the upload_files capability. In some
cases, this would be a good idea for aligning the plugin's behavior
with user expectations, or for making the plugin's authorization model
easy to understand. However, a plugin may have a good reason to do
something entirely different. For example, if there are many people
who need to do exactly one upload and will never interact with that
WordPress installation again, it might be simpler to have an upload
password.
WordPress apparently supports the behavior of some plugins with:
wp-admin/media-new.php
/**
* Manage media uploaded file.
*
* There are many filters in here for media. Plugins can extend functionality
* by hooking into the filters.
...
if (!current_user_can('upload_files'))
wp_die(__('You do not have permission to upload files.'));
The current case is, essentially, that an unauthenticated attacker can
send a request to upload.php and place non-executable content at the
URI:
/wp-content/uploads/power_play/4_uploadfolder/big/not-a-shell.jpg
Your comment was "I know I wouldn't want arbitrary images uploaded,"
which doesn't directly answer the question of whether this is a
reported vulnerability or not. Our current feeling is that we will not
universally categorize this as a vulnerability unless there is
confirming feedback from the author. We didn't find anything at
either:
https://web.archive.org/web/20150503133237/https://wordpress.org/plugins/wp-powerplaygallery/
http://wpslideshow.com/powerplay-gallery/
documenting that the upload process should be authenticated or that
uploaded files should be initially inaccessible. There are obviously
very good reasons to prevent an unauthenticated upload of a JPG file
to an accessible and predictable URL; however, there might sometimes
be a tradeoff with usability and the WordPress installation might want
to deploy the plugin anyway until abuse is actually observed. We also
realize that, for any specific example in which this is occurring,
there is probably a possible design improvement that preserves nearly
all usability and makes abuse much more difficult. Still, our decision
for now is that there's no CVE ID associated with creating
/wp-content/uploads/power_play/4_uploadfolder/big/not-a-shell.jpg in
the above example.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVtk5cAAoJEKllVAevmvmswL4H/1jFeB0Dr3s+KqtbJX+xTvzP
LvTFb9m4gG5OGfzqUVWeQPnjURgWw7Hz7Qcdj3WIo3SpsmOkq89RgaQFSWKsYxAp
BzedA08ztTzEaaVSGHHN/7TgXe05xuVpYPzyO2D4SRmXU7LRCSDg/lpi5SHCTcJY
GMW5inwiB1LiJhsQ+c3CsY5iD+HjSTk7t640wHuMY5aIRfcbdd5utVfR9PUlfafg
Wyu7jJhNmqGOSKe4lXa9jwtjND31SQcCIgLe5HnI/E1fOpIzaHh/oS0yLcRID/nM
mWeHDCoXHeF4seHFXNHg4pSl/BOVxJqBWQKz6ZVklqIf4ryLQ2dWxAITZ2NuTwQ=
=KocW
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
