zlib: add vendor to CVE_PRODUCT to exclude false positives

To avoid false positives (such as CVE-2023-6992, cloudflare:zlib), add a
CVE_PRODUCT to identify the vendor that has been used.

Signed-off-by: Het Patel <hetpat@cisco.com>
---
 meta/recipes-core/zlib/zlib_1.2.13.bb | 3 +++
 1 file changed, 3 insertions(+)

There is also gnu:zlib in CVE reports for zlib...

sqlite3 nvdcve_2-1.db
sqlite> select vendor, count(*) from products where product='zlib' group by vendor;
cloudflare|1
gnu|1
zlib|13
sqlite> select * from products where product='zlib' and vendor = 'gnu';
CVE-2016-9842|gnu|zlib|1.2.3.4|>=|1.2.9|<

Peter

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, August 8, 2024 8:24
> To: openembedded-core@lists.openembedded.org
> Cc: Het Patel <hetpat@cisco.com>
> Subject: [OE-core] [PATCH] zlib: add vendor to CVE_PRODUCT to exclude false
> positives
> 
> To avoid false positives (such as CVE-2023-6992, cloudflare:zlib), add a
> CVE_PRODUCT to identify the vendor that has been used.
> 
> Signed-off-by: Het Patel <hetpat@cisco.com>
> ---
>  meta/recipes-core/zlib/zlib_1.2.13.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-core/zlib/zlib_1.2.13.bb b/meta/recipes-
> core/zlib/zlib_1.2.13.bb
> index ec977a3035..8f3814068a 100644
> --- a/meta/recipes-core/zlib/zlib_1.2.13.bb
> +++ b/meta/recipes-core/zlib/zlib_1.2.13.bb
> @@ -45,3 +45,6 @@ do_install_ptest() {
>  }
> 
>  BBCLASSEXTEND = "native nativesdk"
> +
> +# adding 'CVE_PRODUCT' to avoid false detection of CVEs
> +CVE_PRODUCT = "zlib:zlib"

On 8 Aug 2024, at 07:33, Peter Marko via lists.openembedded.org <peter.marko=siemens.com@lists.openembedded.org> wrote:
> 
> There is also gnu:zlib in CVE reports for zlib...
> 
> sqlite3 nvdcve_2-1.db
> sqlite> select vendor, count(*) from products where product='zlib' group by vendor;
> cloudflare|1
> gnu|1
> zlib|13
> sqlite> select * from products where product='zlib' and vendor = 'gnu';
> CVE-2016-9842|gnu|zlib|1.2.3.4|>=|1.2.9|<

Which is obviously wrong, as there isn’t a GNU zlib.  The references point to the same git tree, so this is a mistake in the CPE data. The CPE database acknowledges this by deprecating the gnu:zlib name and pointing at zlib:zlib:

  <cpe-item name="cpe:/a:gnu:zlib:-" deprecated="true" deprecation_date="2022-06-22T16:40:44.440Z">
    <title xml:lang="en-US">GNU zlib</title>
    <cpe-23:cpe23-item name="cpe:2.3:a:gnu:zlib:-:*:*:*:*:*:*:*">
      <cpe-23:deprecation date="2022-06-22T12:40:44.440-04:00">
        <cpe-23:deprecated-by name="cpe:2.3:a:zlib:zlib:-:*:*:*:*:*:*:*" type="NAME_CORRECTION"/>
      </cpe-23:deprecation>
    </cpe-23:cpe23-item>
  </cpe-item>

We _could_ canonicalise the CPEs when we load the CVEs but that’s another 500MB file to fetch, so I’m unconvinced that’s worthwhile.

I was actually going to mail NIST about any attempt at rationalising the CPE data for historical CVEs, I’ll use this as a test case to see if they’re willing to retroactively fix the name in historical CVEs.

Ross