Just got 35 failures against 5.4.4-14+deb7u12

[vdroznik]

Does it correctly validate PHP vulnerabilities with Debian patches?

[enygma]

It doesn't handle patched versions for distros yet - that's something that a lot of people have been asking for. I'm looking into how to track these updates for the distros to see if it's possible before I do much work on it.

[tenken]

ya I was gonna ask how this helps at all with an LTS distro release like REL or Ubuntu LTS versions which pin the PHP version:

REL7

php -r "echo PHP_VERSION;"
php-5.4.16-23.el7_0

Ubuntu 14.04 LTS

php -r "echo PHP_VERSION;"
5.5.9-1ubuntu4.4

These will always return the same major/minor numbers although security patches will have been applied by the distribution updates. Silly to run any production webapp on a non-LTS linux distribution.

[enygma]

Yeah, I'm looking for good data sources where I can see what bugs were fixed in which released. Haven't had too much time to devote to it yet, so if anyone knows of any, that'd be great.

[xsist10]

@enygma For the ubuntu distributions, we could parse https://launchpad.net/ubuntu/+source/php5/ and loop through the security branches (e.g.: https://launchpad.net/ubuntu/+source/php5/5.5.9+dfsg-1ubuntu4.4 then https://launchpad.net/ubuntu/+source/php5/5.5.9+dfsg-1ubuntu4.3, etc) and regex match against CVE-\d{4/}-\d{2}. Then we build up a checklist of CVEs that we tick off from the original result.

So, using 5.5.9-1ubuntu4.4, we would:

• run a check against 5.5.9 and return a result list
• run a check against 1ubuntu4.4 (and all entries < than) and mark the CVEs we found patched in those releases off the result list
• return the final compiled result

Then we could extend this to RH, Debian and any other distribution with LTS support done in this way. It will be a pain to setup and maintain the scrappers (especially if something changes on the sites) and we'll probably need to rely on some eyeballs spotting mistakes (changelogs aren't always 100% reliable).

An alternative is to checkout the source code from launchpad and see when certain patches are added to the build process like this:

diff -u php5-5.3.2/debian/rules php5-5.3.2/debian/rules
--- php5-5.3.2/debian/rules
+++ php5-5.3.2/debian/rules
@@ -225,6 +225,7 @@
    sed -i -re "s#('PEAR_CONFIG_SYSCONFDIR', PHP_SYSCONFDIR)#\1 . '/pear'#" $(CURDIR)/pear-build/usr/share/php/PEAR/Config.php
    patch -s -d $(CURDIR)/pear-build/usr/share/php/ -p0 -i $(CURDIR)/debian/patches/php5-pear-CVE-2011-1072.patch
    patch -s -d $(CURDIR)/pear-build/usr/share/php/ -p0 -i $(CURDIR)/debian/patches/php5-pear-CVE-2011-1144.patch
+   patch -s -d $(CURDIR)/pear-build/usr/share/php/ -p0 -i $(CURDIR)/debian/patches/php5-pear-CVE-2011-1144-regression.patch
    touch build-pear-stamp

[enygma]

Hmm, I'm good with writing the tools to run those updates. I can find a place to run them from every so often and try for an update to the file....crossing fingers for no merge conflicts? :)

[xsist10]

@enygma, I've put a prototype up here https://github.com/xsist10/versionscan/tree/ubuntu-releases if you care to give it a look.

Test like so:

# 2 failures
/bin/versionscan scan --php-version="5.5.9-1ubuntu4.4"
# 4 failures
/bin/versionscan scan --php-version="5.5.9-1ubuntu4.3"
# 13 failures
/bin/versionscan scan --php-version="5.5.9-1ubuntu4.1"

[xsist10]

Added the ubuntu scrapper to the gist with the check scrapper: https://gist.github.com/xsist10/f623f03634c73a8ad0ac

[xsist10]

I think we may need to build a list of patch masks. I've come across the following already:

• 5.5.12-2ubuntu4
• 5.5.12+dfsg-2ubuntu4
• 5.4.4-14+deb7u12
• 5.6.0-1+deb.sury.org~trusty+1

The last was on an Ubuntu box with what looked like a manual merge in from Debian to ensure the latest release of PHP.

A comprehensive list will help us safe guard against missing any.

[xsist10]

Sorry about the delay. Here are the Debian patches. Just need to put together the redhat versions. Give it a test here: https://github.com/xsist10/versionscan/tree/ubuntu-releases

# 10 failures
./bin/versionscan scan --php-version="5.4.4-14+deb7u12"

# 17 failures
./bin/versionscan scan --php-version="5.4.4-14+deb7u11"

# 25 failures
./bin/versionscan scan --php-version="5.4.4"

[xsist10]

Added Redhat versions. I'll clean up the scrapers so anyone can update the files.

# 17 failures
.bin/versionscan scan --php-version php-5.4.16

# 4 failures
.bin/versionscan scan --php-version php-5.4.16-23.el7_0

[xsist10]

Pull request #7

[xsist10]

Gist has been updated with Debian and Redhat scrappers (warning, they could take a couple of runs to finish if Kimono decides to block your requests after too many).

https://gist.github.com/xsist10/f623f03634c73a8ad0ac

[remicollet]

Notice, on RHEL/Fedora/CentOS, PHP_VERSION is upstream version, doesn't provide any useful information about patch

 $ php -r "echo PHP_VERSION;"
 5.4.16

[remicollet]

About redhat, package version is also not relevant (I mean, version compare is not relevant), as various branches are maintained (5.11, 6.4, 6.5, 6.6, 7.0, 7.1...)

So, for example, you can have

• In 6.5, a CVE fix in update from 5.3.3-38.el6 to 5.3.3-38.el6_5.1
• In 6.6, same CVE fix in update from 5.3.3-40.el6_6 to 5.3.3-41.el6_6

[xsist10]

What does $ php --version return? Same response or a more useful tag?
On 24 Jan 2015 9:48 AM, "Remi Collet" [email protected] wrote:

Notice, on RHEL/Fedora/CentOS, PHP_VERSION is upstream version, doesn't
provide any useful information about patch

$ php -r "echo PHP_VERSION;"
5.4.16

—
Reply to this email directly or view it on GitHub
#5 (comment).

[remicollet]

# php --version
PHP 5.4.16 (cli) (built: Oct 31 2014 12:59:36) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[remicollet]

Here is a small script to get CVEs fixed on a RHEL package.

 function getPatches() {
    /* not a RPM based distro */
    if (!is_executable('/bin/rpm')) {
        return NULL;
    }
    /* Find package name which own php command */
    @exec('/bin/rpm --queryformat "%{NAME}\n" --query --file '.PHP_BINARY, $ret, $error);
   /* not a packaged PHP version */
    if ($error || empty($ret[0])) {
        return NULL;
    }
    $name = $ret[0];
    /* Read Changelog */
    @exec('/bin/rpm --query --changelog '.$name, $ret, $error);
    $cves = array();
    foreach ($ret as $line) {
        if (preg_match_all('/CVE-[0-9]+-[0-9]+/', $line, $reg)) {
            foreach ($reg[0] as $cve) {
                $cves[]=$cve;
            }
        }
    }
    return $cves;
 }
 printf("PHP Version : %s\n", PHP_VERSION);
 print_r(getPatches());

Output:

 $ php getpatches.php
 PHP Version : 5.4.16
 Array
 (
     [0] => CVE-2014-3710
     [1] => CVE-2014-3668
     [2] => CVE-2014-3669
     [3] => CVE-2014-3670
     ...
 )

Of course, this should be considered with base version (5.4.16 here), I mean some can be old (due to nature of changelog), but if they appear in the list, they are fixed, if not, should check PHP_VERSION

Notice, this also work for SCL base packages (RHEL 6 provides 5.3.3, 5.4.16 and 5.5.6, package name can be, php-cli, php54-php-cli, php55-php-cli, ...)

 $ scl enable php55 'php getpatches.php'
 PHP Version : 5.5.21
 Array
  (
     [0] => CVE-2014-2270
     [1] => CVE-2013-7345
 ...
 )

[xsist10]

We could definitely include that for systems that detect the rpm package manager. We'd need to just have an over-ride so if a custom version is specified using the --php-version=4.3.2 command (to test against target versions rather than current ones) that we skip this check.

If someone does use the --php-version=x.x.x check for a redhat tag we don't be able to tell the vulnerabilities without a lookup list, so we'd need to just inform the user (provide them a link to Redhat resources).