I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:

• LAYER: meta
• PACKAGE NAME: libksba
• PACKAGE VERSION: 1.6.0
• CVE: CVE-2016-4355
• CVE STATUS: Patched
• CVE SUMMARY: Multiple integer overflows in ber-decoder.c in Libksba before 1.3.3 allow remote attackers to cause a denial of service (crash) via crafted BER data, which leads to a buffer overflow.
• CVSS v2 BASE SCORE: 5.0
• CVSS v3 BASE SCORE: 7.5
• VECTOR: NETWORK
• MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-4355

As can be seen, the CVE was patched in version 1.3.3 of the libksba while the build is using the version 1.6.0.

Is there something wrong with what the cve-check is reporting or is it not bothering to match the version numbers before reporting a CVE? Or maybe my understanding of the report is incorrect?

Would really appreciate a feedback on this, seeing as how the documentation on the cve checker is sparse.


Thanks,
Gaurav

On 5 Jul 2022, at 13:31, gauravsuman007 via lists.yoctoproject.org <gauravsuman007=gmail.com@...> wrote:

I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:
• LAYER: meta
• PACKAGE NAME: libksba
• PACKAGE VERSION: 1.6.0
• CVE: CVE-2016-4355
• CVE STATUS: Patched
• CVE SUMMARY: Multiple integer overflows in ber-decoder.c in Libksba before 1.3.3 allow remote attackers to cause a denial of service (crash) via crafted BER data, which leads to a buffer overflow.
• CVSS v2 BASE SCORE: 5.0
• CVSS v3 BASE SCORE: 7.5
• VECTOR: NETWORK
• MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-4355
As can be seen, the CVE was patched in version 1.3.3 of the libksba while the build is using the version 1.6.0.

Is there something wrong with what the cve-check is reporting or is it not bothering to match the version numbers before reporting a CVE? Or maybe my understanding of the report is incorrect?

I’m not sure I understand what your concern is. We have version 1.6.0, the CVE was fixed in 1.3.3, so the security issue has been patched.

The status is “patched” even if there’s not a literal patch in the recipe, it should be “mitigated” but we’d need to move to a new format to change the values.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

On Tue, Jul 5, 2022 at 2:31 PM <gauravsuman007@...> wrote:

I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:

LAYER: meta
PACKAGE NAME: libksba
PACKAGE VERSION: 1.6.0
CVE: CVE-2016-4355
CVE STATUS: Patched

Hello Gaurav,
The CVE STATUS "Patched" means that there was an issue in the past,
but it is either fixed or otherwise mitigated. Open issues are marked
as "Unpatched". If you'd like to see only Unpatched issues in the
report, please use CVE_CHECK_REPORT_PATCHED = "0" in your local.conf
or other place you have your OE configuration from.

Kind regards,
Marta

Re-adding yocto@.

This brings me to the handling of the "Unpatched" CVEs in the project. I can get some idea for which version of the package may have the mitigation for the CVE but there is no "mitigated_version" variable which helps me figure out the updated path in an automated way. I'm guessing that such a variable must be present internally in the cve_check class for it to detemine if the existing package version is lower than the mitigated version. Can I change the configuration for this information to also be printed in the cve log? This can probably also be added to the documentation (I don't mind volunteering for that)

It’s not always a trivial “this version”, there’s a fairly complex expression in the CVE (see the CPE entry) which needs to be evaluated. Or there may not be a fixed release, or the CVE needs configuration changes.

Basically, I don’t think it’s feasible to put a “fixed version” entry in the report that isn’t misleading. Whoever is reviewing the CVEs should actually read the CVE details and make a judgement on what to do.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.