[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 00:42:59 -0400
From: "Larry W. Cashdollar" <larry0@...com>
To: cve-assign@...re.org
Cc: Open Source Security <oss-security@...ts.openwall.com>
Subject: Re: Remote file upload vulnerability & SQLi in wordpress plugin
wp-powerplaygallery v3.3
> On Jul 20, 2015, at 10:58 AM, cve-assign@...re.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-----
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.
