Re: Remote file upload vulnerability & SQLi in wordpress plugin wp-powerplaygallery v3.3

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This seems to be one of several cases where a third party has taken
example code from the Ephox (formerly Moxiecode) Plupload product and
added undesirable new behavior.

For background,
https://raw.githubusercontent.com/moxiecode/plupload/master/examples/upload.php
is the current upstream code. Although this upstream code could
introduce security problems in some contexts, the code is not assigned
any CVE IDs because it is clearly marked as an example, and would not
be installed on a web server as a normal part of installing Plupload:

  #!! IMPORTANT: 
  #!! this file is just an example, it doesn't incorporate any security checks and 
  #!! is not recommended to be used in production environment as it is. Be sure to 
  #!! revise it and customize to your needs.

The code reported here is from
http://plugins.svn.wordpress.org/wp-powerplaygallery/trunk/upload.php
instead. All of the specific reported issues are ones that exist in
wp-powerplaygallery and don't exist in Plupload.

The most obvious difference is that the "INSERT INTO" is a new code
block in wp-powerplaygallery - the upstream code doesn't use SQL at
all.

> 3. Sql injection 
> Lines 131-135 of upload.php fail to handle user input appropriately either by sanitizing or paramaterizing it. 
> Injection points are
> any GET/POST to albumid or name.

Use CVE-2015-5599.


> 1. Ability to create directories out side of the upload path by using ../:
> Lines 56-59 of upload.php:
>
> 56 // Create target dir
> 57 if (!file_exists($targetDir)) {
> 58         @mkdir($targetDir);

As far as we can tell, the issue you are reporting (when a current PHP
version is used) is that the attacker can create a directory anywhere
with "_uploadfolder" at the end of its name. This behavior isn't
required for achieving PHP code execution, and seems unlikely to help
with other important attacks. It might waste disk space on a small
filesystem, and might allow an attacker to store files outside of
wp-content (e.g., in a directory that wouldn't be checked during a
user's post-exploitation cleanup). If so, then this is an issue that
can be included in CVE, but it seems marginal.

For anyone who is interested in reporting these types of low-priority
side issues: it would be helpful to explicitly state that the issue is
independently relevant and could be independently fixed.


> 2. Arbitrary file uploads to a path in the web root directory:
> Lines 138-160 of uploads.php don't verify what types of files are allowed or where they should be placed:

We didn't completely understand this part. 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. Is there
also a problem with "where they should be placed" within this part of
the code? The files seem to be placed in a *_uploadfolder/big/
directory, which is a correct directory for an upload of an image
file.

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?


> albumid needs to be a numeric value matching an existing album number, 1 is probably a good start
> but you can enumerate these by using curl, and looking for redirect 301 responses:

Why does the album number need to exist? Wasn't the mkdir supposed to
create the directory for an arbitrary $_REQUEST['albumid'] value?

- -- 
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)

iQEcBAEBAgAGBQJVrQv+AAoJEKllVAevmvmsO8AH/3hMf5MDgzozxwptBSXnBrVv
8gjPcUDIDop1KqM5ZDAeC8X+tp/oQzgtN9ZPqL2mkyYWdhs3Rm+Pv/+VlFIAKjTC
NbrL9LsuaVe9UrK2KL0zzQ0okyXOEeDGz2Myb5YrGVvshNMTmYcGOyL4oP/IiZmy
8XZCM6QJolEiMjtX2w1J9ZdlBV7yRh+d4ie/XEdmvcPBEWdvmYt/UxTs8guZ1PZM
8PBEUz8sTdI94Cl0mW0DRGZLzZ/T9tOvHq/Gxl0+wb+khRzWJkfPL8zuVjoi1P5x
ZFQrcWkK6pyQCYimLLRTQs6x6MY8NdKdlUQ0t4hljg1UEVm4QSYiab9qBGsDVwM=
=94ua
-----END PGP SIGNATURE-----