Vulnerabilities/CVE in Zephyr modules

[tgagneret-embedded]

Hi,

I'd like to check that my Zephyr product is not affected by any CVE. For this, I use the NVD database (using CPE "zephyrproject:zephyr") which mostly links to the "Security Advisories" on this github repository.

However I did not find information about the vulnerabilities in Zephyr modules. Indeed Zephyr is not using mainline modules, but instead use its own repository with some modification. The west.yml points to a commit in this repository. So it means that for every version of Zephyr, since theses modules are part of Zephyr, there should be some information about CVE in these modules I think.

If I take an example, like mbedTLS. The last version of mbedTLS merged in the zephyr mbedTLS module is "3.1.0" if I'm not mistaken (https://github.com/zephyrproject-rtos/mbedtls) but there is a recent CVE on this version (https://nvd.nist.gov/vuln/detail/CVE-2022-35409). How can I know if I'm affected by this one ? If so, is there any fixes that has been added ?

So I would like to know if there is any existing documentation/report about this ? If not, how can I solve this issue ? Should I "manually" check the last merged version (from mainline to zephyr module) and then check CVE for this component ?

Thanks

[stephanosio]

cc @ceolin

[ceolin]

That is a good point that we are bring to security working group. Right now, we don't a process to monitor and publish vulnerabilities on modules. Modules and HALs are "generally" updated before a release. I acknowledge that from the security perspective it is not ideal, so we are planning to use github dependabot to minimize this gap. I'm glad this topic was brought up since we are looking into it.

[tgagneret-embedded]

Hi,

Thanks for your answer.

Do you have any schedule or delivery date for this "feature" ?

Thanks

[ceolin]

We don't have a date yet, but I'll come out with a proposal this month. For now the best thing is filling an issue asking for update a module if you find a vulnerability in one of them.

[tgagneret-embedded]

On a close topic, I checked some of the Security advisories for Zephyr and it seems that the commit associated with the CVE (that fixes the vulnerabilities) is not always a dedicated commit/PR (it can include multiple modification not related to the CVE).
I think it could be interesting if your policy forces to have a dedicated commit/PR when it fixes a CVE. That would allow to improve backport for people not using current version (or Long Term).

Would it make sense for you to adopt this policy ?

Thanks

[dkalowsk]

@tgagneret-embedded you may find it useful to attend the bi-weekly security working group meeting. Details can be found at https://lists.zephyrproject.org/

[beriberikix]

@kestewart FYI

[ceolin]

On a close topic, I checked some of the Security advisories for Zephyr and it seems that the commit associated with the CVE (that fixes the vulnerabilities) is not always a dedicated commit/PR (it can include multiple modification not related to the CVE). I think it could be interesting if your policy forces to have a dedicated commit/PR when it fixes a CVE. That would allow to improve backport for people not using current version (or Long Term).

Would it make sense for you to adopt this policy ?

We disclose the pr that fixes the vulnerability in the respective advisory, but yep, some times it fixes more than the original CVE. This can happen because the developer decided to change how something was implemented or because they found other related issues. That is something that we can review and have a more strict policy if it makes user's life easier.

[ceolin]

A heads up on this item. I've tried to automate it finding for vulnerabilities based on a generated SBOM. I've tested https://github.com/intel/cve-bin-tool, but there are other tools like https://github.com/google/osv-scanner too. The main problem is that our SBOM lacks information like package name and package version, so these tools are not able to identify which modules / libraries are being used and consequently find vulnerabilities on them.

One possibility is introduce more responsibilities for modules maintainers to check for it, but it will be hard to ensure it is properly being done. Our best shot IMHO is properly fix our SBOM generator and have some of these CVE finding tools integrated in CI.