SLES oval DB is broken

[wagde-orca]

What did you do? (required. The issue will be closed when not provided.)

I fetched latest oval of sles 15
used vuls to scan sles 15.3

What did you expect to happen?

I expected to see CVEs

What happened instead?

I got no CVEs. instead I saw this
[Apr 21 11:19:56] WARN [localhost] Unknown Oval format. Please register the issue as it needs to be investigated. https://github.com/vulsio/goval-dictionary/issues family: suse.linux.enterprise.server, defID: oval:org.opensuse.security:def:20214024

I have an old DB for SLES, so I compared the old DB tables and the new DB table and I think I see the problem
In the OLD DB, in the table of cves. we have "normal" CVE values in the cve_id column like CVE-2024-3864. but in the NEW fetched DB I see that we have entries like CVE-2024-3864 at SUSE and CVE-2024-3864 at NVD and I think this what causes vuls to fail...
I downloaded the sles 15 xml from //ftp.suse.com/pub/projects/security/oval/suse.linux.enterprise.server.15.xml.gz
and I see that the entry looks like

<title>CVE-2023-7216</title> SUSE Linux Enterprise Server 15 SP1-LTSS SUSE Linux Enterprise Server 15 SP2-LTSS SUSE Linux Enterprise Server 15 SP3-LTSS SUSE Linux Enterprise Server 15-LTSS SUSE Linux Enterprise Server for SAP Applications 15 SP1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 SUSE Linux Enterprise Server for SAP Applications 15 SP3 A path traversal vulnerability was found in the CPIO utility. This issue could allow a remote unauthenticated attacker to trick a user into opening a specially crafted archive. During the extraction process, the archiver could follow symlinks outside of the intended directory, this allows writing files in arbitrary directories through symlinks. Important CVE-2023-7216 at SUSE CVE-2023-7216 at NVD SUSE bug 1219619 cpe:/o:suse:sles-ltss:15 cpe:/o:suse:sles-ltss:15:sp1 cpe:/o:suse:sles-ltss:15:sp2 cpe:/o:suse:sles-ltss:15:sp3 cpe:/o:suse:sles_sap:15:sp1 cpe:/o:suse:sles_sap:15:sp2 cpe:/o:suse:sles_sap:15:sp3 and in the goval suse fetcher code we have this code which I guess is not broken... for _, c := range d.Advisory.Cves { cves = append(cves, models.Cve{ CveID: c.CveID, Cvss3: c.Cvss3, Impact: c.Impact, Href: c.Href, }) }

to reporduce the DB problem just fetch the sles 15
./goval-dictionary fetch suse --suse-type suse-enterprise-server 15 --no-details and examine the DB
I do not have an old SLES oval xml file so I do not know what was the exact format

This is very serious problem because it means that scanning SLES is broken and does not return any CVEs... meaning lots of False Negatives :-(

[MaineK00n]

@wagde-orca

Thank you for your report. I'll take a look at the currently available OVALs.

[MaineK00n]

This seems to be because SUSE and NVD are now included in advisory.cves.

$ curl https://ftp.suse.com/pub/projects/security/oval/suse.linux.enterprise.server.15.xml.gz | gzip --decompress | grep -A100 "oval:org.opensuse.security:def:20214024"
<definition id="oval:org.opensuse.security:def:20214024" version="1" class="vulnerability">
...
<advisory from="security@suse.de">
	<issued date="2021-11-30"/>
	<updated date="2024-04-18"/>
	<severity>Moderate</severity>
	<cve impact="moderate" cvss3="4.8/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L" href="https://www.suse.com/security/cve/CVE-2021-4024/">CVE-2021-4024 at SUSE</cve>
	<cve impact="moderate" cvss3="6.5/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L" href="https://nvd.nist.gov/vuln/detail/CVE-2021-4024">CVE-2021-4024 at NVD</cve>
	<bugzilla href="https://bugzilla.suse.com/1193166">SUSE bug 1193166</bugzilla>
</advisory>
...

[MaineK00n]

@wagde-orca
If you like, please try using this Pull Request branch.
future-architect/vuls#1899

[wagde-orca]

ahh the fix is in vuls? not goval-dictionary?
I will check it later and update

[wagde-orca]

@MaineK00n the results of the scan look good

[wagde-orca]

@MaineK00n so the fix will be in goval-dictionary eventually? or in both goval and vuls?
I think that the fix should be in goval-dictionary... it should be transparent for vuls, we should filter the unneeded data in goval-dictionary and give vuls what it had before. what do you think?

[MaineK00n]

I think that the primary purpose of goval-dictionary is to handle the provided OVAL, so I would like to keep the contents of the OVAL unchanged as much as possible.

[wagde-orca]

sure... but it should not hold data from NVD :-)
go-cve-dictionary should hold such data... I think we should only keep the data that we get from SUSE in the oval like before. what do you think?

[MaineK00n]

It is true that NVD information is available in go-cve-dictionary, so from the perspective of a vuls user, I don't think it's necessary.
However, considering goval-dictionary as an independent tool that handles OVAL, I think that NVD information should also be retained.

[MaineK00n]

Considering goval-dictionary select/server, I decided to remove the CVE suffix at goval-dictionary.
However, as long as SUSE OVAL provides information on NVD, we will continue to handle information on NVD.
In Vuls, SUSE and others can be distinguished by Href.
Therefore, even in a DB created with old goval-dictionary, detection can be performed without adding an unnecessary suffix to the CVE ID part.