Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Oct 2014 13:48:47 -0400 (EDT)
From: cve-assign@...re.org
To: larry0@...com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Vulnerabilities in WordPress Database Manager v2.7.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Download: https://wordpress.org/plugins/wp-dbmanager/
> Contacted: 10/13/2014, Vulnerabilities addressed in v2.7.2.
> Full Advisory: http://www.vapid.dhs.org/advisories/wordpress/plugins/wp-dbmanager-2.7.1/index.html

> In the following lines commands can be injected into the variables
> being used to build the command by using ;command;
> 
> $backup['filepath'] 
> $backup['mysqldumppath']

Use CVE-2014-8334 for this issue involving shell metacharacters.


> --password="passwordhere"
> 
> while (true); do  echo -n `ps ax | grep m[y]sqldump`; done

Use CVE-2014-8335 for this issue in which local users can see a
password by listing process arguments.


> only a few queries are allowed (Use Only INSERT, UPDATE, REPLACE,
> DELETE, CREATE and ALTER statements.) but these are sufficient to
> download sensitive system files:

> INSERT into password (passwords) VALUES(LOAD_FILE("/etc/passwd"));

This report seems related to:

  if ( preg_match( "/LOAD_FILE/i", $sql_query ) ) {

in the

  https://github.com/lesterchan/wp-dbmanager/commit/7037fa8f61644098044379190d1d4bf1883b8e4a

commit. Our question here is whether this is best categorized as a
WP-DBManager vulnerability fix, or a workaround for a MySQL
misconfiguration. It seems that, ideally, if WP-DBManager is not
supposed to be able to use MySQL to read arbitrary files, then this
would have been addressed with the configuration of the FILE privilege
or the secure_file_priv variable.

Presumably there are other products in which users are intended to be
able to use INSERT, but are not intended to be able to use LOAD_FILE.
It's not clear that, for every such product, doing preg_match for
/LOAD_FILE/i is the recommended approach, and absence of this approach
means that a CVE ID is assigned.

Also, in the WP-DBManager case, CREATE is allowed, and this could
conceivably mean that CREATE FUNCTION is available (again, depending
on the MySQL privilege configuration), possibly resulting in the user
gaining unintended access to the server machine and its local
filesystem.

Should there be one CVE ID now for "attempts to offer a subset of
MySQL statements without considering the possible MySQL privilege
configurations" as applied to the LOAD_FILE attack, and then other
"incomplete fix" CVE IDs later if a new attack against 2.7.2/2.7.3 is
disclosed?

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

iQEcBAEBAgAGBQJURUpKAAoJEKllVAevmvmsxC8H/RbAUETRxb72HufQQIx3+7Qf
ksf3B8IRz+4mnd/b97Fa4kFw+B04eOhXwUtp1Dl/BoGXGWn3kqcDvaqVxDRzLTL7
zNDt4b1riq4YFxWLStFv0gh8rIRcyMLMqP6iwY0WHT0ycliO4CaoAj240UF32OBo
e4PSqFZSm4o7915cg0nBhGYhI41TUBfETqruZnZ7oum/8SMvCjNJAqgn1xR+XDIE
mZggSYW2gvdFGxrjXcxyGhDDwAMBRArZhIZwczDzVIQJpx427GYFNKYrApB2mlze
4+R7Rq36RIylrqXvkvdGYSD4TvbcEhritEnV1qgc2PJ3pxI8XKpJr9oxSf065ZI=
=jsGy
-----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.