[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE requests / Advisory: phpMyBackupPro
From:       Matthew Daley <mattd () bugfuzz ! com>
Date:       2015-06-02 6:01:34
Message-ID: CAD3CandbSkBH-MZwPH2uKpYR9SMBcT68Si5ZMPLhiDsu9WyDpA () mail ! gmail ! com
[Download RAW message or body]

Ping.

On 4 May 2015 at 21:24, Matthew Daley <mattd@bugfuzz.com> wrote:
> 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
[prev in list] [next in list] [prev in thread] [next in thread]