False positive: PHP packages from deb.sury.org (incorrect package version number parsing)

Our systems currently run PHP 7.1 on Debian Jessie, using packages from the semi-official third-party repository at deb.sury.org. Running an authenticated scan on this host is giving numerous failures relating to the php-pear package:

Detection Result

Vulnerable package: php-pear
Installed version: 1.10.8+submodules+notgz-1+0~20190219091008.9+jessi
Fixed version: 5.6.39+dfsg-0+deb8u1

Detection Method

This check tests the installed software version using the apt package manager.

Details: Debian LTS Advisory ([SECURITY] [DLA 1608-1] php5 security update) OID: 1.3.6.1.4.1.25623.1.0.891608
Version used: 2019-03-18T14:53:48Z

Looking at the Detection Result section suggests the check is comparing the package version numbers incorrectly. The package from deb.sury.org uses an “epoch” version, meaning that the version from the sury.org repository is newer than the one mentioned in the security update (epoch-less version numbers have an implicit epoch of zero).

Perhaps not the most important thing to fix since Jessie LTS will be EOL in June next year and this is a third-party repository, but I thought I’d mention it in case this is a generic issue with version number checking on Debian-based systems (and I think maybe RPM uses epochs too?) that might need fixing.

Thanks for the detailed report. There might be indeed some issues with epochs when checking the version via:

dpkg --compare-versions 1:1.10.1+submodules+notgz-9+deb9u1 gt 5.6.40+dfsg-0+deb8u4 && echo $?

→ Result 0 which means 1:1.10.1+submodules+notgz-9+deb9u1 > 5.6.40+dfsg-0+deb8u4

It seems the dpknorm() function of pkg-lib-deb.inc is just removing the epoch completely causing a comparison like e.g.

dpkg --compare-versions 1.10.1+submodules+notgz-9+deb9u1 gt 5.6.40+dfsg-0+deb8u4 && echo $?

→ No output which means 1:1.10.1+submodules+notgz-9+deb9u1 < 5.6.40+dfsg-0+deb8u4

Instead of removing the epoch dpknorm() should probably prepend a 0: to each version if no epoch exists to match the following:

I have raised an internal ticket on this to evaluate your observations and the previous suggestion or possible alternative solutions.

2 Likes