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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ