Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 00:42:59 -0400
From: "Larry W. Cashdollar" <>
Cc: Open Source Security <>
Subject: Re: Remote file upload vulnerability & SQLi in wordpress plugin
 wp-powerplaygallery v3.3

> On Jul 20, 2015, at 10:58 AM, 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.


> - -- 
> CVE assignment team, MITRE CVE Numbering Authority
> M/S M300
> 202 Burlington Road, Bedford, MA 01730 USA
> [ PGP key available through ]
> 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ