| Message ID | 20201104145145.1316167-2-thomas.petazzoni@bootlin.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Introduce CPE ID matching for CVEs | expand |
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
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
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 --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
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(-)