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

["Larry W. Cashdollar" <larry0 () me com>]

> On Jul 20, 2015, at 10:58 AM, cve-assign () mitre org wrote:
>
> 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.

It is marginal, but I thought note worthy and decided to mention it in my advisory.

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

Yes, good point.

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

It should filter out what file types are allowed for uploading at least.  I know I wouldn’t want arbitrary images 
uploaded to my Wordpress instance from users who aren’t logged in.


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

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.  So the file upload will fail if the album doesn’t exist.


From power_play.php:

263                         if( !is_dir($album_dir . '/big') )
264                                 mkdir($album_dir . '/big');
265                         if( !is_dir($album_dir . '/thumb') )
266                                 mkdir($album_dir . '/thumb');


I hope I answered your questions.

Thanks!
Larry

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