diff mbox series

[01/10] support/scripts/cve.py: properly match CPEs with version '*'

Message ID 20201104145145.1316167-2-thomas.petazzoni@bootlin.com
State Accepted
Headers show
Series Introduce CPE ID matching for CVEs | expand

Commit Message

Thomas Petazzoni Nov. 4, 2020, 2:51 p.m. UTC
Currently, when the version encoded in a CPE is '-', we assume all
versions are affected, but when it's '*' with no further range
information, we assume no version is affected.

This doesn't make sense, so instead, we handle '*' and '-' in the same
way. If there's no version information available in the CVE CPE ID, we
assume all versions are affected.

This increases quite a bit the number of CVEs and package affected:

-    "total-cves": 302,
-    "pkg-cves": 100,
+    "total-cves": 597,
+    "pkg-cves": 135,

For example, CVE-2007-4476 has a CPE ID of:

    cpe:2.3:a:gnu:tar:*:*:*:*:*:*:*:*

So it should be taken into account. In this specific case, it is
combined with an AND with CPE ID
cpe:2.3:o:suse:suse_linux:10:*:enterprise_server:*:*:*:*:* but since
we don't support this kind of matching, we'd better be on the safe
side, and report this CVE as affecting tar, do an analysis of the CVE
impact, and document it in TAR_IGNORE_CVES.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 support/scripts/cve.py | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

Comments

Matthew Weber Nov. 4, 2020, 4:45 p.m. UTC | #1
Thomas,


On Wed, Nov 4, 2020 at 8:53 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Currently, when the version encoded in a CPE is '-', we assume all
> versions are affected, but when it's '*' with no further range
> information, we assume no version is affected.
>
> This doesn't make sense, so instead, we handle '*' and '-' in the same
> way. If there's no version information available in the CVE CPE ID, we
> assume all versions are affected.
>
> This increases quite a bit the number of CVEs and package affected:
>
> -    "total-cves": 302,
> -    "pkg-cves": 100,
> +    "total-cves": 597,
> +    "pkg-cves": 135,
>
> For example, CVE-2007-4476 has a CPE ID of:
>
>     cpe:2.3:a:gnu:tar:*:*:*:*:*:*:*:*
>
> So it should be taken into account. In this specific case, it is
> combined with an AND with CPE ID
> cpe:2.3:o:suse:suse_linux:10:*:enterprise_server:*:*:*:*:* but since
> we don't support this kind of matching, we'd better be on the safe
> side, and report this CVE as affecting tar, do an analysis of the CVE
> impact, and document it in TAR_IGNORE_CVES.


I agree, it is better to over-report and give people the option of
setting the ignore entry or to go work with the CPE dictionary team to
make an update to how that CVE is being mapped to the CPE.

I was interested to know if yocto has an existing listing of CVE they
are ignoring as well.  I looked a bit at the cve-checker[2] but I
couldn't find any existing list or metadata within yocto but instead a
few forked tools that all allow you to create a Software Bill Of
Materials (SBOM) and provide a list of overall excluded CVE [1].  It
seems better to keep the initial refinement within Buildroot or to
push instead for making a correction in the actual CVE mapping.  If
the user wants to whitelist it outside of Buildroot for their specific
use case, that could be a topic for a future patchset on creation of a
Software Bill Of Materials matching/tailored for their defconfig.
Thoughts?

Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>


[1] https://github.com/LairdCP/cve-checker/blob/master/cli.py
[2] https://hub.mender.io/t/how-to-run-cve-checks-using-the-yocto-project/1142
Thomas Petazzoni Nov. 4, 2020, 4:54 p.m. UTC | #2
Hello,

On Wed, 4 Nov 2020 10:45:32 -0600
Matthew Weber <matthew.weber@collins.com> wrote:

> > So it should be taken into account. In this specific case, it is
> > combined with an AND with CPE ID
> > cpe:2.3:o:suse:suse_linux:10:*:enterprise_server:*:*:*:*:* but since
> > we don't support this kind of matching, we'd better be on the safe
> > side, and report this CVE as affecting tar, do an analysis of the CVE
> > impact, and document it in TAR_IGNORE_CVES.  
> 
> I agree, it is better to over-report and give people the option of
> setting the ignore entry or to go work with the CPE dictionary team to
> make an update to how that CVE is being mapped to the CPE.

That is the idea. And among the new CVEs that appear, there are really
some CVEs where the NVD database just specify "*", without any
combination with a particular operating system or distribution: i.e the
CVE description is so imprecise that it doesn't even say which versions
of the software component are affected.

> I was interested to know if yocto has an existing listing of CVE they
> are ignoring as well.  I looked a bit at the cve-checker[2] but I
> couldn't find any existing list or metadata within yocto but instead a
> few forked tools that all allow you to create a Software Bill Of
> Materials (SBOM) and provide a list of overall excluded CVE [1].  It
> seems better to keep the initial refinement within Buildroot or to
> push instead for making a correction in the actual CVE mapping.  If
> the user wants to whitelist it outside of Buildroot for their specific
> use case, that could be a topic for a future patchset on creation of a
> Software Bill Of Materials matching/tailored for their defconfig.
> Thoughts?

Yes, we could certainly think of allowing the user to extend the list
of ignored CVEs. I haven't tried doing <pkg>_IGNORE_CVES +=
CVE-YYYY-XYZ in external.mk from an external tree. I don't know if it's
going to play well with the expansion ordering, though.

> Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>

Thanks!

Thomas
Thomas Petazzoni Nov. 26, 2020, 3:32 p.m. UTC | #3
On Wed,  4 Nov 2020 15:51:35 +0100
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> Currently, when the version encoded in a CPE is '-', we assume all
> versions are affected, but when it's '*' with no further range
> information, we assume no version is affected.
> 
> This doesn't make sense, so instead, we handle '*' and '-' in the same
> way. If there's no version information available in the CVE CPE ID, we
> assume all versions are affected.
> 
> This increases quite a bit the number of CVEs and package affected:
> 
> -    "total-cves": 302,
> -    "pkg-cves": 100,
> +    "total-cves": 597,
> +    "pkg-cves": 135,
> 
> For example, CVE-2007-4476 has a CPE ID of:
> 
>     cpe:2.3:a:gnu:tar:*:*:*:*:*:*:*:*
> 
> So it should be taken into account. In this specific case, it is
> combined with an AND with CPE ID
> cpe:2.3:o:suse:suse_linux:10:*:enterprise_server:*:*:*:*:* but since
> we don't support this kind of matching, we'd better be on the safe
> side, and report this CVE as affecting tar, do an analysis of the CVE
> impact, and document it in TAR_IGNORE_CVES.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>  support/scripts/cve.py | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)

Since Matt gave his Reviewed-by, and it's a fairly simple patch
touching just pkg-stats/CVE, I've applied to next. Thanks!

Thomas
diff mbox series

Patch

diff --git a/support/scripts/cve.py b/support/scripts/cve.py
index 6396019e0e..e7472cd470 100755
--- a/support/scripts/cve.py
+++ b/support/scripts/cve.py
@@ -144,10 +144,6 @@  class CVE:
                 # Version is defined, this is a '=' match
                 op_start = '='
                 v_start = version
-            elif version == '-':
-                # no version information is available
-                op_start = '='
-                v_start = version
             else:
                 # Parse start version, end version and operators
                 if 'versionStartIncluding' in cpe:
@@ -206,11 +202,8 @@  class CVE:
         for cpe in self.each_cpe():
             if cpe['product'] != name:
                 continue
-            if cpe['v_start'] == '-':
-                return self.CVE_AFFECTS
             if not cpe['v_start'] and not cpe['v_end']:
-                print("No CVE affected version")
-                continue
+                return self.CVE_AFFECTS
             if not pkg_version:
                 continue