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 do not 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 are tracking security vulnerabilities in the Yocto Project against the National Vulnerability Database.

We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/

Yocto Security Team

The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.

The team's main responsibilities among others are:

• Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
• Responsible for fixing CVEs in the Yocto releases & maintained branches
• Evaluation of tools for security tests
• Responsible for security related info in the Yocto documentations
• Hardening of Yocto release

How to Contact Yocto's security team Securely

---

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.

• Private List

security [at] yoctoprojct [dot] org (Forwards to the following addresses)

- sona [dot] sarmadi [at] enea [dot] com

- mhalstead [at] linuxfoundation [dot] org

For secure communications, please send your messages encrypted to both using the following GPG keys.

Remember message headers are not encrypted so do not include sensitive information in the subject line.

Download public keys: Sona Sarmadi Michael Halstead

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 saftey 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. CVE's). 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-yoco kernels regularly from https://www.kernel.org/

Linux-yocto

linux-yocto_3.10 & linux-yocto_3.14 (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-fsl-ppc (meta-freescale@yoctoproject.org)
• 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 regressions 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 developmen should follow the openembedded's Commit Patch Message Guidelines and kernel security bugs policy for the kernel patches.

In addition security patches should have reference to the CVE identifier both in the patch file/s and the commit message.

Ex: 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)

   Fixes CVE-2015-1472.
   Upstream-Status: Backport
      
   Reference to upstream patch:
   The patch is from (Paul Pluzhnikov <ppluzhnikov@google.com>
   https://sourceware.org/git/?p=glibc.git;a=patch;h=5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06
     
   Signed-off-by:

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:

Some security related links/useful tools

• CVE details
• CVE list, Linux kernel 2014
• Meta-security-layer
• Making images more secure
• Cvechecker

Security Issues Addressed in Yocto Releases

Yocto 2.0 - Jethero https://www.yoctoproject.org/downloads/core/jethro20

Yocto 1.8.1 - Fido https://www.yoctoproject.org/downloads/core/fido181

Yocto 1.7.1 - Dizzy https://www.yoctoproject.org/downloads/core/dizzy171