Redhat package_name with / do not always reference modules

[wagoodman]

While looking into anchore/grype#1541 we found a secondary issue: We have a section of code in the rhel provider that I believe (after some debate/discovery with @willmurphyscode @nurmi @kzantow @tgerla ) is incorrectly assuming an RPM modularity from a value, specifically the package_name field with /:

...
 {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Affected",
    "package_name" : "inkscape:flatpak/python-lxml",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  },
...

full output

❯ cat data/vunnel/rhel/input/cve/full/CVE-2022-2309
   1 {
   2   "threat_severity" : "Moderate",
   3   "public_date" : "2022-07-05T00:00:00Z",
   4   "bugzilla" : {
   5     "description" : "CVE-2022-2309 lxml: NULL Pointer Dereference in lxml",
   6     "id" : "2107571",
   7     "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2107571"
   8   },
   9   "cvss3" : {
  10     "cvss3_base_score" : "7.5",
  11     "cvss3_scoring_vector" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
  12     "status" : "verified"
  13   },
  14   "cwe" : "CWE-476",
  15   "details" : [ "NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.
     9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also u
     sed by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter
      that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk functi
     on, a crash can be triggered.", "A NULL Pointer dereference vulnerability found in lxml, caused by the iterwalk function (also used by the canonicalize function). This flaw can lead to a crash when the i
     ncorrect parser input occurs together with usages." ],
  16   "affected_release" : [ {
  17     "product_name" : "Red Hat Enterprise Linux 9",
  18     "release_date" : "2022-11-15T00:00:00Z",
  19     "advisory" : "RHSA-2022:8226",
  20     "cpe" : "cpe:/a:redhat:enterprise_linux:9",
  21     "package" : "python-lxml-0:4.6.5-3.el9"
  22   } ],
  23   "package_state" : [ {
  24     "product_name" : "Red Hat Enterprise Linux 8",
  25     "fix_state" : "Not affected",
  26     "package_name" : "python38:3.8/python-lxml",
  27     "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  28   }, {
  29     "product_name" : "Red Hat Enterprise Linux 8",
  30     "fix_state" : "Not affected",
  31     "package_name" : "python39:3.9/python-lxml",
  32     "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  33   }, {
  34     "product_name" : "Red Hat Enterprise Linux 8",
  35     "fix_state" : "Not affected",
  36     "package_name" : "python-lxml",
  37     "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  38   }, {
  39     "product_name" : "Red Hat Enterprise Linux 9",
  40     "fix_state" : "Affected",
  41     "package_name" : "inkscape:flatpak/python-lxml",
  42     "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  43   }, {
  44     "product_name" : "Red Hat Software Collections",
  45     "fix_state" : "Not affected",
  46     "package_name" : "rh-python38-python-lxml",
  47     "cpe" : "cpe:/a:redhat:rhel_software_collections:3"
  48   } ],
  49   "references" : [ "https://www.cve.org/CVERecord?id=CVE-2022-2309\nhttps://nvd.nist.gov/vuln/detail/CVE-2022-2309" ],
  50   "name" : "CVE-2022-2309",
  51   "csaw" : false
  52 }

Specifically, in inkscape:flatpak/python-lxml I think the value inkscape:flatpak is being parsed as the RPM modularity:

sqlite> select id,package_name,package_qualifiers,version_constraint from vulnerability where id == "CVE-2022-2309" and namespace == "redhat:distro:redhat:9";
id             package_name  package_qualifiers                                       version_constraint
-------------  ------------  -------------------------------------------------------  ------------------
CVE-2022-2309  python-lxml   [{"kind":"rpm-modularity","module":"inkscape:flatpak"}]
CVE-2022-2309  python-lxml                                                            < 0:4.6.5-3.el9

(note the first row).

I cannot find any reference to python-lxml that is part of an appstream named this, however, the indicator :flatpak might indicate that this is referring to a python-lxml package within the contents of the inkscape flatpak image.

This means that the row in the DB is wrong (should not exist). My vote would be to drop any entry where the modularity value is *:flatpack.

CC @westonsteimel

[westonsteimel]

We can drop those, but I don't really understand how that correlates to incorrect results in grype since it should only be matching that row if the package has a modularity matching inkscape:flatpak and it shouldn't have that unless that was set by the logic which extracts the rpm modularity into from syft? Or something is incorrect in the matching logic because it shouldn't ever be matching that qualifier

[wagoodman]

I was thinking something similar, and I think it comes down to this conditional but I don't recall why this conditional should be there (I'm sure we've talked about this before).

[westonsteimel]

Ah right, because if the package has no modularity specified we can't make any assumptions about what it should match because that was a new qualifier added to v5 and if someone were using sboms from an older version of syft or some input that knew nothing about modularity it would result in no matches ever being raised and therefore false negatives, whereas just returning all rows only results in false positives

[westonsteimel]

I'll take a look at the data later to see if there are more instances like this and get it cleaned up in vunnel

[westonsteimel]

I'm also wondering if we can somehow do better for the cases with no modularity by ensuring we always create a row with blank modularity and some combination of constraints. Then we could get rid of that condition in grype.

[westonsteimel]

Really I think the modularity we're looking for should always have a numerical component to it, but I need to look at the data again to verify that assumption. That would make this easier I think

[westonsteimel]

Ah, except I'd like to determine the correct version constraints for records with no modularity in vunnel, but that isn't possible with the current schema since is entries only emit fixes. I guess I could just add a new property for version_constraint though and then update grype-db to use that accordingly. That would also allow me to improve the amazon entries which are getting out of control since they never have modularity but issue separate advisories for multiple release lines.

[westonsteimel]

I'll split it up into multiple pieces of work and get the filtering in first though which should solve the current grype issue at least.

[westonsteimel]

select distinct package_qualifiers from vulnerability where namespace like 'redhat%' and package_qualifiers like '%rpm-modularity%' order by package_qualifiers;
package_qualifiers
------------------------------------------------------------
[{"kind":"rpm-modularity","module":"389-ds:1.4"}]

[{"kind":"rpm-modularity","module":"ant:1.10"}]

[{"kind":"rpm-modularity","module":"container-tools:1.0"}]

[{"kind":"rpm-modularity","module":"container-tools:2.0"}]

[{"kind":"rpm-modularity","module":"container-tools:3.0"}]

[{"kind":"rpm-modularity","module":"container-tools:4.0"}]

[{"kind":"rpm-modularity","module":"container-tools:rhel8"}]

[{"kind":"rpm-modularity","module":"eclipse:rhel8"}]

[{"kind":"rpm-modularity","module":"firefox:flatpak"}]

[{"kind":"rpm-modularity","module":"freeradius:3.0"}]

[{"kind":"rpm-modularity","module":"gimp:2.8"}]

[{"kind":"rpm-modularity","module":"gimp:flatpak"}]

[{"kind":"rpm-modularity","module":"go-toolset:rhel8"}]

[{"kind":"rpm-modularity","module":"httpd:2.4"}]

[{"kind":"rpm-modularity","module":"idm:DL1"}]

[{"kind":"rpm-modularity","module":"inkscape:flatpak"}]

[{"kind":"rpm-modularity","module":"javapackages-tools:20180
1"}]

[{"kind":"rpm-modularity","module":"libreoffice:flatpak"}]

[{"kind":"rpm-modularity","module":"llvm-toolset:rhel8"}]

[{"kind":"rpm-modularity","module":"log4j:2"}]

[{"kind":"rpm-modularity","module":"mailman:2.1"}]

[{"kind":"rpm-modularity","module":"mariadb-devel:10.3"}]

[{"kind":"rpm-modularity","module":"mariadb:10.3"}]

[{"kind":"rpm-modularity","module":"mariadb:10.5"}]

[{"kind":"rpm-modularity","module":"maven:3.5"}]

[{"kind":"rpm-modularity","module":"maven:3.6"}]

[{"kind":"rpm-modularity","module":"mod_auth_openidc:2.3"}]

[{"kind":"rpm-modularity","module":"mysql:8.0"}]

[{"kind":"rpm-modularity","module":"nginx:1.14"}]

[{"kind":"rpm-modularity","module":"nginx:1.16"}]

[{"kind":"rpm-modularity","module":"nginx:1.18"}]

[{"kind":"rpm-modularity","module":"nginx:1.20"}]

[{"kind":"rpm-modularity","module":"nginx:1.22"}]

[{"kind":"rpm-modularity","module":"nodejs:10"}]

[{"kind":"rpm-modularity","module":"nodejs:12"}]

[{"kind":"rpm-modularity","module":"nodejs:14"}]

[{"kind":"rpm-modularity","module":"nodejs:16"}]

[{"kind":"rpm-modularity","module":"nodejs:18"}]

[{"kind":"rpm-modularity","module":"nodejs:20"}]

[{"kind":"rpm-modularity","module":"parfait:0.5"}]

[{"kind":"rpm-modularity","module":"perl-App-cpanminus:1.704
4"}]

[{"kind":"rpm-modularity","module":"perl:5.24"}]

[{"kind":"rpm-modularity","module":"perl:5.30"}]

[{"kind":"rpm-modularity","module":"perl:5.32"}]

[{"kind":"rpm-modularity","module":"php:7.2"}]

[{"kind":"rpm-modularity","module":"php:7.3"}]

[{"kind":"rpm-modularity","module":"php:7.4"}]

[{"kind":"rpm-modularity","module":"php:8.0"}]

[{"kind":"rpm-modularity","module":"php:8.1"}]

[{"kind":"rpm-modularity","module":"pki-core:10.6"}]

[{"kind":"rpm-modularity","module":"pki-deps:10.6"}]

[{"kind":"rpm-modularity","module":"postgresql:10"}]

[{"kind":"rpm-modularity","module":"postgresql:12"}]

[{"kind":"rpm-modularity","module":"postgresql:13"}]

[{"kind":"rpm-modularity","module":"postgresql:15"}]

[{"kind":"rpm-modularity","module":"postgresql:9.6"}]

[{"kind":"rpm-modularity","module":"python27:2.7"}]

[{"kind":"rpm-modularity","module":"python36:3.6"}]

[{"kind":"rpm-modularity","module":"python38-devel:3.8"}]

[{"kind":"rpm-modularity","module":"python38:3.8"}]

[{"kind":"rpm-modularity","module":"python39-devel:3.9"}]

[{"kind":"rpm-modularity","module":"python39:3.9"}]

[{"kind":"rpm-modularity","module":"redis:5"}]

[{"kind":"rpm-modularity","module":"redis:6"}]

[{"kind":"rpm-modularity","module":"redis:7"}]

[{"kind":"rpm-modularity","module":"ruby:2.5"}]

[{"kind":"rpm-modularity","module":"ruby:2.6"}]

[{"kind":"rpm-modularity","module":"ruby:2.7"}]

[{"kind":"rpm-modularity","module":"ruby:3.0"}]

[{"kind":"rpm-modularity","module":"ruby:3.1"}]

[{"kind":"rpm-modularity","module":"rust-toolset:rhel8"}]

[{"kind":"rpm-modularity","module":"squid:4"}]

[{"kind":"rpm-modularity","module":"subversion:1.10"}]

[{"kind":"rpm-modularity","module":"subversion:1.14"}]

[{"kind":"rpm-modularity","module":"thunderbird:flatpak"}]

[{"kind":"rpm-modularity","module":"varnish:6"}]

[{"kind":"rpm-modularity","module":"virt:rhel"}]

[westonsteimel]

Yeah, looking at the full set the rest do appear to be actual app streams from what I can tell, so I think for now just eliminating the flatpak records is the way to go since we're not going to know what to do with those in grype anyways

[westonsteimel]

Also, looking at the full set of rpm-modularity package qualifiers, I noticed that sles and mariner are creating blank modularity qualifier records like [{"kind":"rpm-modularity"}] for everything for some reason, so I'm going to try and get rid of that, though I'll do it separately