[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD3CanfvEFLMpKbLaqfAX7b-q76yS63c95t+=J5hcNFjNdwYcA@mail.gmail.com>
Date: Mon, 4 May 2015 21:24:06 +1200
From: Matthew Daley <mattd@...fuzz.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE requests / Advisory: phpMyBackupPro
On 4 May 2015 at 18:14, <cve-assign@...re.org> wrote:
> The final concern is Issue #3. We believe it's valuable to search for
> duplicate CVEs, but there was no comment about whether CVE-2009-4050
> is the same issue. If that 2009 issue was fixed and then reintroduced
> between versions 2.1 and 2.5, then there can be two new CVE IDs for
> the 2015 report.
Huh, didn't stumble across that CVE.
> If that 2009 issue was never fixed, then there was a duplicate
> discovery. We believe that CVE-2009-4050 applies to the larger
> problem: an attacker could use any number of "../" sequences after the
> "get_file.php?view=" part of the URI, including zero "../" sequences.
> There would then be one additional CVE ID for the behavior in 2.5,
> because that behavior represents an incomplete fix for CVE-2009-4050.
>
> By default, we would use the second interpretation for Issue #3. In
> other words, unless someone can establish that CVE-2009-4050 was fixed
> in 2.2, 2.3, or 2.4, we'll conclude that Issue #3 is a duplicate
> discovery, and we'll send the one ID for the "incomplete fix" CVE.
So, a disclosure for CVE-2009-4050 is at
<https://www.exploit-db.com/exploits/10169/>. Looking at it, there's a
relevant snippet of (presumably) 2.1's code:
--- 8< ---
// show the requested file
if (isset($_GET['view']) && file_exists($_GET['view'])) {
if (isset($_GET['download'])) {
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment;
filename=".basename($_GET['view']));
readfile($_GET['view']);
} else {
...
}
--- 8< ---
The equivalent code in 2.4 is:
--- 8< ---
// show the requested file
if (isset ($_GET['view']) && file_exists($_GET['view'])) {
$ext4 = substr($_GET['view'],-4);
$ext5 = substr($_GET['view'],-5);
$ext7 = substr($_GET['view'],-7);
$ext8 = substr($_GET['view'],-8);
if ($ext4 != ".php" && $ext5 != ".html" && $ext4 != ".htm" &&
$ext5 != ".php3" && $ext4 != ".sql" && $ext8 != ".sql.zip" && $ext7 !=
".sql.gz") {
echo GF_INVALID_EXT . "!";
} else {
if (isset ($_GET['download'])) {
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment;
filename=" . basename($_GET['view']));
readfile($_GET['view']);
} else {
...
}
}
--- 8< ---
So it appears that the attempted fix to CVE-2009-4050 was to add a
file extension whitelist (.php, .html, .php3, ...). However, directory
traversal was still possible after this fix, and the whitelisted file
extensions still allow "interesting" files to be retrieved, namely the
config PHP file.
In response to my bug report, in 2.5 a filename suffix blacklist was
added to attempt to fix the latter issue, but it can still be bypassed
(by adding a /x/../ sequence to the last part of the path).
So, I would suggest:
* CVE-2009-4050 = original fully-arbitrary file download
* New 2009 CVE = incomplete fix in 2.2(?) (adding a file extension whitelist)
* New 2015 CVE = incomplete fix in 2.5 (adding a filename suffix blacklist)
HTH,
- Matthew
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.
