linux/poky.git/meta/classes/cve-check.bbclass, branch zeus-next2

cve-check: Switch to NVD CVE JSON feed version 1.1

2019-12-16T23:08:52+00:00

Switch to recently released version 1.1 of NVD CVE JSON feed, as in https://nvd.nist.gov/General/News/JSON-1-1-Vulnerability-Feed-Release it is mentioned that Due to changes required to support CVSS v3.1 scoring, the JSON vulnerability feeds must be modified. This will require the consumers of this data to update their internal processes. We will be providing the JSON 1.1 schema on the data feeds page and the information below to prepare for this transition. ... The JSON 1.1 data feeds will be available on September 9th, 2019. At that time the current JSON 1.0 data feeds will no longer available. This change was tested briefly by issuing 'bitbake core-image-minimal' with 'cve-check.bbclass' inherited via local.conf, and then comparing the content between the resulting two 'DEPLOY_DIR_IMAGE/core-image-minimal-qemux86.cve' files, which did not seem to contain any other change, except total of 167 entries like CVSS v3 BASE SCORE: 0.0 were replaced with similar 'CVSS v3 BASE SCORE:' entries which had scores that were greater than '0.0' (up to '9.8'). (From OE-Core rev: cc20e4d8ff2f3aa52a2658404af9a0ff358cc323) (From OE-Core rev: c92b8804d6e59b2707332859957f0e6a46db0a73) Signed-off-by: Niko Mauno Signed-off-by: Richard Purdie Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

cve-check: fetch CVE data once at a time instead of in a single call

2019-11-25T21:37:40+00:00

This code used to construct a single SQL statement that fetched the NVD data for every CVE requested. For recipes such as the kernel where there are over 2000 CVEs to report this can hit the variable count limit and the query fails with "sqlite3.OperationalError: too many SQL variables". The default limit is 999 variables, but some distributions such as Debian set the default to 250000. As the NVD table has an index on the ID column, whilst requesting the data CVE-by-CVE is five times slower when working with 2000 CVEs the absolute time different is insignificant: 0.05s verses 0.01s on my machine. (From OE-Core rev: 53d0cc1e9b7190fa66d7ff1c59518f91b0128d99) (From OE-Core rev: 3ded9a64c95ae02df7562fc69e2af08c150d2452) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

cve-check: neaten get_cve_info

2019-11-25T21:37:40+00:00

Remove obsolete Python 2 code, and use convenience methods for neatness. (From OE-Core rev: f19253cc9e70c974a8e21a142086c13d7cde04ff) (From OE-Core rev: 98162c04c877925c737674a1635b08cf998b92f5) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

cve-check: rewrite look to fix false negatives

2019-11-25T21:37:40+00:00

A previous optimisation was premature and resulted in false-negatives in the report. Rewrite the checking algorithm to first get the list of potential CVEs by vendor:product, then iterate through every matching CPE for that CVE to determine if the bounds match or not. By doing this in two stages we can know if we've checked every CPE, instead of accidentally breaking out of the scan too early. (From OE-Core rev: d61aff9e22704ad69df1f7ab0f8784f4e7cc0c69) (From OE-Core rev: 0f42a1d4dbb74ab39e81449cf222302bcc04f7db) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

cve-check: we don't actually need to unpack to check

2019-11-25T21:37:40+00:00

The patch scanner works with patch files in the layer, not in the workdir, so it doesn't need to unpack. (From OE-Core rev: 2cba6ada970deb5156e1ba0182f4f372851e3c17) (From OE-Core rev: 02e6b727bf62858be7dba061879a6d57bd5a725d) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

cve-check: failure to parse versions should be more visible

2019-11-13T22:02:16+00:00

(From OE-Core rev: 6b5cadd1a5822641285946f7e2ad56e294658621) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

cve-check: ensure all known CVEs are in the report

2019-11-13T22:02:16+00:00

CVEs that are whitelisted or were not vulnerable when there are version comparisons were not included in the report, so alter the logic to ensure that all relevant CVEs are in the report for completeness. (From OE-Core rev: 29d926802e7f8b4614a2dafa0af4c923912e1811) Signed-off-by: Ross Burton Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

cve-update-db-native: Remove hash column from database.

2019-07-19T07:41:40+00:00

djb2 hash algorithm was found to do collisions, so the database was sometime missing data. Remove this hash mechanism, clear and populate elements from scratch in PRODUCTS table if the current year needs an update. (From OE-Core rev: 78de2cb39d74b030cd4ec811bf6f9a6daa003d19) Signed-off-by: Pierre Le Magourou Signed-off-by: Richard Purdie

cve-check: Replace CVE_CHECK_CVE_WHITELIST by CVE_CHECK_WHITELIST

2019-07-19T07:41:40+00:00

CVE_CHECK_WHITELIST does not contain version anymore, as it was not used. This variable should be set per recipe. (From OE-Core rev: 7069302a4ccbb5b72e1902f284cf078516fd7294) Signed-off-by: Pierre Le Magourou Signed-off-by: Richard Purdie

cve-check: allow comparison of Vendor as well as Product

2019-07-18T11:16:19+00:00

Some product names are too vague to be searched without also matching the vendor, for example Flex could be the parser compiler we ship, or Adobe Flex, or Apache Flex, or IBM Flex. If entries in CVE_PRODUCT contain a colon then split it as vendor:product to improve the search. Also don't use .format() to construct SQL as that can lead to security issues. Instead, use ? placeholders and lets sqlite3 handle the escaping. (From OE-Core rev: e6bf90009877d00243417898700d2320fd87b39c) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie