| Message ID | 20241127125945.3211089-1-colinmca242@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | cve-update-nvd2-native: Update vector logic | expand |
On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via lists.openembedded.org wrote: > The database used by cve-check currently stores the access vector and > vector string for the oldest CVSS version for each CVE. This should be > reversed, where the newest possible CVSS version is included instead. > > Signed-off-by: Colin McAllister <colinmca242@gmail.com> Hi, I believe this patch breaks some selftests: 2024-11-28 13:29:06,536 - oe-selftest - INFO - cve_check.CVECheck.test_image_json (subunit.RemotedTestCase) 2024-11-28 13:29:06,539 - oe-selftest - INFO - ... FAIL https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio
On Thu, 2024-11-28 at 12:56 +0100, Mathieu Dubois-Briand via lists.openembedded.org wrote: > On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via > lists.openembedded.org wrote: > > The database used by cve-check currently stores the access vector > > and > > vector string for the oldest CVSS version for each CVE. This should > > be > > reversed, where the newest possible CVSS version is included > > instead. > > > > Signed-off-by: Colin McAllister <colinmca242@gmail.com> > > Hi, > > I believe this patch breaks some selftests: > > 2024-11-28 13:29:06,536 - oe-selftest - INFO - > cve_check.CVECheck.test_image_json (subunit.RemotedTestCase) > 2024-11-28 13:29:06,539 - oe-selftest - INFO - ... FAIL > > https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio > Is that not from the ongoing NVD issues meaning we can't actually obtain a new updated database? :/ Cheers, Richard
On Thu, Nov 28, 2024 at 11:58:41AM +0000, Richard Purdie via lists.openembedded.org wrote: > On Thu, 2024-11-28 at 12:56 +0100, Mathieu Dubois-Briand via > lists.openembedded.org wrote: > > On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via > > lists.openembedded.org wrote: > > > The database used by cve-check currently stores the access vector > > > and > > > vector string for the oldest CVSS version for each CVE. This should > > > be > > > reversed, where the newest possible CVSS version is included > > > instead. > > > > > > Signed-off-by: Colin McAllister <colinmca242@gmail.com> > > > > Hi, > > > > I believe this patch breaks some selftests: > > > > 2024-11-28 13:29:06,536 - oe-selftest - INFO - > > cve_check.CVECheck.test_image_json (subunit.RemotedTestCase) > > 2024-11-28 13:29:06,539 - oe-selftest - INFO -� ... FAIL > > > > https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio > > > > Is that not from the ongoing NVD issues meaning we can't actually > obtain a new updated database? :/ > > Cheers, > > Richard > > It might be. I don't see any issue with the patch itself, so it might be an external factor.
On Wed, Nov 27, 2024 at 1:59 PM Colin McAllister via lists.openembedded.org <colinmca242=gmail.com@lists.openembedded.org> wrote: > The database used by cve-check currently stores the access vector and > vector string for the oldest CVSS version for each CVE. This should be > reversed, where the newest possible CVSS version is included instead. > > Signed-off-by: Colin McAllister <colinmca242@gmail.com> > --- > meta/classes/cve-check.bbclass | 2 +- > meta/recipes-core/meta/cve-update-nvd2-native.bb | 12 ++++++------ > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/meta/classes/cve-check.bbclass > b/meta/classes/cve-check.bbclass > index 0c92b87f52..c4cbcdf8e3 100644 > --- a/meta/classes/cve-check.bbclass > +++ b/meta/classes/cve-check.bbclass > @@ -31,7 +31,7 @@ > CVE_PRODUCT ??= "${BPN}" > CVE_VERSION ??= "${PV}" > > -CVE_CHECK_DB_FILENAME ?= "nvdcve_2-2.db" > +CVE_CHECK_DB_FILENAME ?= "nvdcve_2-3.db" > CVE_CHECK_DB_DIR ?= "${STAGING_DIR}/CVE_CHECK" > CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/${CVE_CHECK_DB_FILENAME}" > CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock" > diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb > b/meta/recipes-core/meta/cve-update-nvd2-native.bb > index a68a8bb89f..e111709b22 100644 > --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb > +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb > @@ -355,21 +355,21 @@ def update_db(conn, elt): > cvssv2 = 0.0 > cvssv3 = None > try: > - accessVector = accessVector or > elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector'] > - vectorString = vectorString or > elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString'] > + accessVector = > elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector'] > + vectorString = > elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString'] > cvssv3 = > elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['baseScore'] > except KeyError: > pass > try: > - accessVector = accessVector or > elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector'] > - vectorString = vectorString or > elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString'] > + accessVector = > elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector'] > + vectorString = > elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString'] > cvssv3 = cvssv3 or > elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['baseScore'] > except KeyError: > pass > cvssv3 = cvssv3 or 0.0 > try: > - accessVector = accessVector or > elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector'] > - vectorString = vectorString or > elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString'] > + accessVector = > elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector'] > + vectorString = > elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString'] > cvssv4 = > elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['baseScore'] > except KeyError: > cvssv4 = 0.0 > -- > When we're at this patch... I'm wondering if anyone is actually using the vectorString from our database for any processing? In other terms, is someone extracting parts of the vector (like network vulnerabilities)? Or we can just remove it and people who want it, will have a look in other places? test_image_json is not checking for the vector string, most likely time outs when downloading the database. Kind regards, Marta
Hi, I would like to use the vector string to do some analysis and prioritization of CVEs and have found that the vector string is better than using the CVSS score. I would argue that in embedded contexts, the environment that a device is used in will result in a different scoring of the vector. The most easy example is a standalone device that does not have any network connections will likely prioritize physical over network attacks, which I believe is opposite to how the CVSS score is determined. I would like for the vector string to be included in the outputs so it is also cached. Post-build tooling could use the NIST API to pull down the vector string, but I would like to avoid hitting the API for what I imagine are the same reasons caching is already done for cve-check. As others have noted in this thread, the NIST API has been rather unreliable lately. I agree that the fetch is likely what is failing the build, since I had to bump the database filename to refresh the contents with the correct vector string. I didn't test_image_json locally, but I did run builds that included fetching the nvd database and everything seemed to have been working. Thanks, Colin
On Fri, Nov 29, 2024 at 3:02 PM Colin <colinmca242@gmail.com> wrote: > Hi, > > > I would like to use the vector string to do some analysis > and prioritization of CVEs and have > found that the vector string is better than using the CVSS score. I would > argue that in > embedded contexts, the environment that a device is used in will result in > a different scoring > of the vector. The most easy example is a standalone device that does not > have any network > connections will likely prioritize physical over network attacks, which I > believe is opposite to > how the CVSS score is determined. > > I would like for the vector string to be included in the outputs so it is > also cached. Post-build > tooling could use the NIST API to pull down the vector string, but I would > like to avoid hitting > the API for what I imagine are the same reasons caching is already done > for cve-check. > > As others have noted in this thread, the NIST API has been rather > unreliable lately. I agree > that the fetch is likely what is failing the build, since I had to bump > the database filename to > refresh the contents with the correct vector string. I didn't > test_image_json locally, but I did > run builds that included fetching the nvd database and everything seemed > to have been > working. > > Hello, I'm not totally convinced by the fact that having the vector will avoid you getting the complete entry. What is the database if what is needed for the analysis. CVSS scores are a little an exception here. If we want to change the database format, I think it might make sense to add ALL the vector strings and not only the last one. That makes way more sense for interpretation purposes and allows you compare entries that have multiple vectors. That being said, NVD entries often have multiple vectors - one from the vendor issuing the CVE, one from the NVD and so on. They often differ quite a bit, and those days there might be other assignments too. For such an analysis I would rather use the raw CVE database instead. Please note that we keep NVD for now because of the CPEs. Product names in the CVE database are not always set correctly (also, the vector is not always set). For all more complete analysis I use CVE that is available as a simple repository at https://github.com/CVEProject/cvelistV5 Kind regards, Marta
On Fri, Nov 29, 2024 at 9:05 AM Marta Rybczynska <rybczynska@gmail.com> wrote: > On Fri, Nov 29, 2024 at 3:02 PM Colin <colinmca242@gmail.com> wrote: > >> Hi, >> >> >> I would like to use the vector string to do some analysis >> and prioritization of CVEs and have >> found that the vector string is better than using the CVSS score. I would >> argue that in >> embedded contexts, the environment that a device is used in will result >> in a different scoring >> of the vector. The most easy example is a standalone device that does not >> have any network >> connections will likely prioritize physical over network attacks, which I >> believe is opposite to >> how the CVSS score is determined. >> >> I would like for the vector string to be included in the outputs so it is >> also cached. Post-build >> tooling could use the NIST API to pull down the vector string, but I >> would like to avoid hitting >> the API for what I imagine are the same reasons caching is already done >> for cve-check. >> >> As others have noted in this thread, the NIST API has been rather >> unreliable lately. I agree >> that the fetch is likely what is failing the build, since I had to bump >> the database filename to >> refresh the contents with the correct vector string. I didn't >> test_image_json locally, but I did >> run builds that included fetching the nvd database and everything seemed >> to have been >> working. >> >> > Hello, > I'm not totally convinced by the fact that having the vector will avoid > you getting the complete entry. > What is the database if what is needed for the analysis. CVSS scores are a > little an exception here. > If we want to change the database format, I think it might make sense to > add ALL the vector strings > and not only the last one. That makes way more sense for interpretation > purposes and allows you > compare entries that have multiple vectors. > > That being said, NVD entries often have multiple vectors - one from the > vendor issuing the CVE, > one from the NVD and so on. They often differ quite a bit, and those days > there might be other > assignments too. For such an analysis I would rather use the raw CVE > database instead. > > Please note that we keep NVD for now because of the CPEs. Product names in > the CVE database > are not always set correctly (also, the vector is not always set). For all > more complete analysis I > use CVE that is available as a simple repository at > https://github.com/CVEProject/cvelistV5 > > Kind regards, > Marta > > I don't disagree. I figured including all CVSS vector strings would probably be best, but I also figured that would also lead to a breaking API change in the cve-check output. I was concerned that a breaking change may not be able to be backported to Kirkstone and Scarthgap, which is what I wanted. However, if a patch that adds all CVSS version vector strings would be accepted over this patch, I would be happy to make that change instead. Thank you, Colin
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 0c92b87f52..c4cbcdf8e3 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -31,7 +31,7 @@ CVE_PRODUCT ??= "${BPN}" CVE_VERSION ??= "${PV}" -CVE_CHECK_DB_FILENAME ?= "nvdcve_2-2.db" +CVE_CHECK_DB_FILENAME ?= "nvdcve_2-3.db" CVE_CHECK_DB_DIR ?= "${STAGING_DIR}/CVE_CHECK" CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/${CVE_CHECK_DB_FILENAME}" CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock" diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb index a68a8bb89f..e111709b22 100644 --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb @@ -355,21 +355,21 @@ def update_db(conn, elt): cvssv2 = 0.0 cvssv3 = None try: - accessVector = accessVector or elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector'] - vectorString = vectorString or elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString'] + accessVector = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector'] + vectorString = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString'] cvssv3 = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['baseScore'] except KeyError: pass try: - accessVector = accessVector or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector'] - vectorString = vectorString or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString'] + accessVector = elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector'] + vectorString = elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString'] cvssv3 = cvssv3 or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['baseScore'] except KeyError: pass cvssv3 = cvssv3 or 0.0 try: - accessVector = accessVector or elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector'] - vectorString = vectorString or elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString'] + accessVector = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector'] + vectorString = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString'] cvssv4 = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['baseScore'] except KeyError: cvssv4 = 0.0
The database used by cve-check currently stores the access vector and vector string for the oldest CVSS version for each CVE. This should be reversed, where the newest possible CVSS version is included instead. Signed-off-by: Colin McAllister <colinmca242@gmail.com> --- meta/classes/cve-check.bbclass | 2 +- meta/recipes-core/meta/cve-update-nvd2-native.bb | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-)