Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jul 2015 10:58:20 -0400 (EDT)
Subject: Re: Remote file upload vulnerability & SQLi in wordpress plugin wp-powerplaygallery v3.3

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

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

> 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

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.