oss-sec mailing list archives
Re: CVE requests / Advisory: phpMyBackupPro
From: Matthew Daley <mattd () bugfuzz com>
Date: Mon, 4 May 2015 21:24:06 +1200
On 4 May 2015 at 18:14, <cve-assign () mitre 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
Current thread:
- CVE requests / Advisory: phpMyBackupPro Matthew Daley (Apr 24)
- Re: CVE requests / Advisory: phpMyBackupPro cve-assign (May 03)
- Re: CVE requests / Advisory: phpMyBackupPro Matthew Daley (May 04)
- Re: CVE requests / Advisory: phpMyBackupPro Matthew Daley (Jun 01)
- Re: CVE requests / Advisory: phpMyBackupPro cve-assign (Jun 04)
- Re: CVE requests / Advisory: phpMyBackupPro Matthew Daley (May 04)
- Re: CVE requests / Advisory: phpMyBackupPro cve-assign (May 03)