Bug 14929 - Cve database corruption after cve-update-db-native fetch fail
Summary: Cve database corruption after cve-update-db-native fetch fail
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: Scripts and Tools (show other bugs)
Version: 4.3
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 4.2
Assignee: Marta Rybczynska
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2022-10-13 05:46 UTC by Marta Rybczynska
Modified: 2023-04-25 08:09 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marta Rybczynska 2022-10-13 05:46:37 UTC
Alberto Pianon reported:

while implementing stats aggregation for CVE metadata in the Oniro
project, I encountered a severe issue in Yocto's CVE checker, apparently
due to this:
https://git.yoctoproject.org/poky/tree/meta/recipes-core/meta/cve-update-db-native.bb#n81

It appears that when cve-update-db-native fails to fetch some years of
NIST CVE db, it just issues a warning but goes on anyway.

The result is that in some builds, randomly (depending on NIST webserver
timeouts or other connection problems), CVE db is not complete, so the
CVE check returns false negatives (i.e. no vulnerabilities found in some
components even if such vulnerabilities do exist)

I ran into such problem because in Oniro we need aggregate data from
different builds for a large target matrix; I added a check to check
that CVE metadata for each component are the same in all builds, and it
failed, so I tried to figure out the cause and I found this:

- in a build where cve-check found a vulnerability for acl:
     $ sqlite3 build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db
     sqlite> SELECT DISTINCT ID FROM PRODUCTS WHERE PRODUCT IS "acl";
     CVE-2009-4411
     sqlite>

- in another build where cve-check did not found any vulnerability for
the very same version of acl:
     $ sqlite3 build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db
     sqlite> SELECT DISTINCT ID FROM PRODUCTS WHERE PRODUCT IS "acl";
     sqlite>

so I listed both CVE db files in those two builds and this is what I
got:

     $ ls -ll build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db
build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db
     -rw-r--r-- 1 ubuntu ubuntu 215093248 Oct 11 10:56
build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db
     -rw-r--r-- 1 ubuntu ubuntu     28672 Oct 11 10:00
build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db

The two CVE db files were fetched just about 1h apart, but the second
file is apparently incomplete.

I checked the log for the second build, and I found this:

     WARNING: cve-update-db-native-1.0-r0 do_fetch: Failed to fetch CVE
data ([Errno 99] Cannot assign requested address)
     NOTE: recipe cve-update-db-native-1.0-r0: task do_fetch: Succeeded

Fetch fails, but do_fetch task succeeds.

So I looked into the recipe's code, and I found this:
https://git.yoctoproject.org/poky/tree/meta/recipes-core/meta/cve-update-db-native.bb#n81

It iterates over NIST CVE db years, but if some year fail to download,
it goes on anyway, and it still merges the successful downloads into
nvdcve_1.1.db, without returning error.

IMHO this is a severe issue because it may silently lead to false
negatives in the CVE check. If some downloads fail due to timeouts or
other connection problems, cve-check should retry a number of times, and
if any download still fails, cve-update-db-native do_fecth should fail,
and it turn all do_cve_check tasks should fail, since doing a CVE check
against a corrupted/incomplete CVE database is clearly useless
Comment 1 Marta Rybczynska 2022-10-13 05:48:11 UTC
I'll be looking into how to fix it. My current idea is to make the download a transaction, so do not update the database until we're sure the download is complete. Plus a warning that we have had an issue, I think.
Comment 2 Randy MacLeod 2023-01-03 16:47:03 UTC
Marta,
  Thanks for bumping this issue along. The 4.99 target is used to mean that you won't be working on this issue in the coming months but we should get to is in the next release or two. Does that correspond to your intention for this bug?
../Randy
Comment 3 Marta Rybczynska 2023-01-04 15:24:09 UTC
Hi Randy, 
I think I was overly pessimistic. In fact the fix is up for a review here: https://lists.openembedded.org/g/openembedded-core/message/175355