Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Oct 2014 14:56:49 -0400
From: "Larry W. Cashdollar" <larry0@...com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Re: Vulnerabilities in WordPress Database Manager
 v2.7.1

Hello,

My comments are below.

On Oct 20, 2014, at 1:48 PM, cve-assign@...re.org wrote:
> 
> 
> > 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?

It seems to me this would be the best approach. I hadn’t considered it originally, but it 
makes the most sense.


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

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