Security

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we try our best not to release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

Upgrading recipes to the newer versions in the maintenance branches is not always easy, this is why we provide a patch for the existing version instead if we detect a vulnerability in a package. The patches are added to the recipes, see example below:

 poky/recipes-connectivity/bind/bind_9.9.5.bb
 
 SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
          file://conf.patch \
          ...
          file://bind9_9_5-CVE-2014-8500.patch \

We provide a tool cve-check.bbclass to help report possible security vulnerabilities in the Yocto Project against the National Vulnerability Database. Unpatched CVEs can be detected using the cve-checker which compares bitbake recipes, their versions and applied CVE patches to reported CVEs for that SW component name and version in the NVD database.

Another good source to track reported CVEs is via the oss-security mailing list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

Yocto Security Team

Currently, the Yocto Project DOES have a Security team. We have two methods of communicating with the project.

How to Contact the Yocto Project regarding Security

---

We have set up two security-related mailing lists:

• Public List

yocto [dash] security [at] yoctoproject[dot] org

This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches. For more information including subscription information please see the yocto-security mailing list info page.

• Private List

security [at] yoctoproject [dot] org

For non-public or urgent issues.

Anyone can contribute with security patches as before, but those volunteering to this security team will sync/organize security related activities and take more responsibility.

What you should do if you find a security vulnerability

---

If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source packages used by the Yocto Project, please report this to the Yocto Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at Yocto as well. If you believe this is sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

What Yocto Security Team does when it receives a security vulnerability

---

The team performs a quick analysis and reports the flaw to the upstream project. Normally the upstream projects analyzes the problem. If they deem that it is a real security problem in their software, the project will email the linux-distros mailing list and notify all the big Linux distributions/vendors about the existence of this vulnerability/flaw. These mailing lists are normally non-public. The project and people on the linux-distros can then agree on a release date when the flaw should be made public. There is also sometimes some coordination for handling patches or backporting of patches etc, or just understanding the problem or what caused it.

When the security issue is finally to be made public, normally upstream project is responsible to contact Mitre (cve.mitre.org) to get a CVE number assigned to it and copy the information to other Opens Source Security mailing lists to inform the whole world of the vulnerability.

If an upstream project does not respond quickly

---

If an upstream project does not fix the problem the Yocto's Security Team will contact linux-distros and community and together try to solve the vulnerability as quickly as possible. Normally big Linux vendors fix the problem if the problem affects their products. Chances are that everyone from the enterprise distros to the commercial Yocto vendors will get fixes done first, but it is nice to have safety net for issues that really are specific to OE and embedded.

Branches maintained with security fixes

See Stable branches maintenancefor detailed info regarding the policies and maintenance of Stable branch.

Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them.)

Policy for updating package versions for the stable branches

The Yocto project purposely limits updating of packages on oe-stable releases to items that address security problems (e.g. CVEs). For packages like QEMU we avoid updating between from one "dot.dot" to another related "dot.dot" version since it has been seen in the past that even with "simple" updates, things can go wrong and a lot more testing is required to verify compatibility. Better to only add CVE patches to fix specific point problems.

Kernel security patches

Kernel security patches are backported to Linux-yocto kernels regularly from https://www.kernel.org/

Linux-yocto

linux-yocto_3 (maintainer: Bruce Ashfield)

Vendor kernels

Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

• meta-intel (meta-intel uses Linux-yocto)
• meta-xilinx (meta-xilinx@lists.yoctoproject.org)
• meta-ti (meta-ti@yoctoproject.org)
• etc

How to test

If there is any test case for the vulnerability by the upstream project or community

- Run the test to reproduce the problem and verify the correction. 
- Run the regression test

If there isn’t any test case and it is complicated and time consuming to write a testcase

- Run the regression test

Regression test

• Build the core image for at least two architectures (preferably one big-endian and one little-endian)
• Run ptest (for those branches/packages that there is ptest mechanism)

Patch name convention and commit message

Security patches like any Open Source development should follow the openembedded's Guidelines:

• Commit Patch Message Guidelines
• kernel security bugs policy

Note that security patches should have CVE: tag and reference to the CVE identifier both in the patch file/s and the commit message.

Ex upstream patch:

Please change the upstream patch "wscanf-allocates-too-little-memory.patch" to "CVE-2015-1472.patch" (or CVE-2015-1472-wscanf-allocates-too-little-memory.patch). Keep the original commit message and add reference to the CVE and upstream patch.

   <Keep the original commit message>
   
   
   Upstream-Status: Accepted <or Backport>
   CVE: CVE-2015-8370   
   
   Reference to upstream patch:
   https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06
     
   Signed-off-by: Joe Developer <joe.developer@example.com>

Ex meta patch:

Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:

   bash: CVE-2014-6278 <if there are multiple CVEs list all>
   
   <short description>
   
   <[YOCTO #xxx] if there is any>
   
   References
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
   https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278
   xxxx
   
   Signed-off-by: <your email address>

Workflow of Yocto Project's bugzilla

• To Open a Security defect go to Security ‑ Recipe Upgrade
  • Access to this issue can only be viewed by the submitter and a small group of Bug triage folks:
    • Armin Kuster
    • Randy MacLeod
    • Richard Purdie
    • Ross Burton
    • Tim Orling
    • Stephen Jolley
  • The normal bug triage process will be applied.

• If the issue is already public please send the patch when available to the appropriate mailing list
• If the issue is private, attach a patch if available to the defect is preferred.

Some security related links/useful tools

• Current CVE status for OE-Core/Poky (generated by the Autobuilder)
• Yocto Project and CVEs, presentation by David Reyna in 2019 Yocto Developer day
• Linux kernel fixed and reported CVEs in all branches and point releases
  • Note that cherry-picking CVE fixes for kernel is not recommended and users should merge full stable releases instead, see What Stable Kernel Should I Use? by stable kernel maintainer Greg Kroah-Hartman
• CVE details
• Meta-security-layer
• Making Images More Secure (Development Tasks Manual)

Current work in progress

• Synchronization on the CVE work
• Security team and private reporting
• SECURITY.md file
• Related slides