Security: Difference between revisions

From Yocto Project
Jump to navigationJump to search
 
(139 intermediate revisions by 9 users not shown)
Line 1: Line 1:
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.  
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.  


We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].
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 \


== Branches that are maintained with security fixes ==


1.7 dizzy (maintainer: Armin Kuster)
We provide a tool [https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cve-check.bbclass cve-check.bbclass] to help report possible security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm 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.
1.6 daisy (maintainer: Saul Wold)
1.5 dora (maintainer: Robert Yang)
1.4 dylan (maintainer: Paul Eggleton)
master (maintainer: Richard Purdie)


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/


== Kernel security patches ==
== 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 [https://lists.yoctoproject.org/g/yocto-security 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 [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for 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 are backported to Linux-yoco kernels regularly from https://www.kernel.org/
== Kernel security patches ==
# Linux-yocto; linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Ross Burton)


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
=== Vendor kernels ===
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/
   
   
meta-fsl-ppc (maintainer: xxx)
* meta-intel (meta-intel uses Linux-yocto)
meta-fsl-arm (maintainer: xxx)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
meta-intel (maintainer: xxx)
* meta-ti (meta-ti@yoctoproject.org)
meta-xilinx (maintainer: xxx)
* etc
meta-ti (maintainer: xxx)


== How to test? ==
== How to test ==
   
   
If there is any test case for the vulnerability by the upstream project or community; we normally run the test to reproduce the problem and after applying the correction to verify that the problem is solved.
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:
*[http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
*[https://www.kernel.org/doc/Documentation/SecurityBugs 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.


If there isn’t any test case and it is complicated and time consuming to write a testcase, we only build the core image for at least two architectures and run the regressions test (ptest) for those branches which have ptest mechanism.


'''Ex upstream patch:'''


== Patch name convention and commit comment ==
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.
Security patches should have  reference to the CVE identifier both in the patch file/s and the commit comment.
    <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>


A) Backport of upstream patch (the patch inside poky/meta/recipes- …) Most of the time security patches are backported from upstream project or kernel.org. When backporting a patch, keep the commit comment, signoff etc as it is but add the following:
    1) Add upstream status E.g. upstream “status: backport”
    2) Add CVE identifier in the patch file, use the pattern: Fix-for-CVE-201X-XXXX.patch
    E.g.  poky/meta/recipes-connectivity/openssl/openssl/ Fix-for-CVE-201X-XXXX.patch 




B) The patch sent to the OE-core (patch file + recipes):
'''Ex meta patch:'''
After adding the backported security patch in the  meta*/recipes- */ directory and modifying the yocto recipes, you need to generate a new recipes to send to OE-core or yocto.
This patch/s need also have reference to the CVE/s. Please make sure to add:
  1) The package name in the subject
  2) The reference to the CVE


Example for the commit comment:
Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit message:  
-----------------------------------------------
    bash: Fix for CVE-2014-6278


    bash: CVE-2014-6278 <if there are multiple CVEs list all>
   
     <short description>
     <short description>
 
   
    <[YOCTO #xxx] if there is any>
   
     References
     References
     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
     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>


    Signed-off-by: <your email addres>
== Workflow of Yocto Project's bugzilla ==
    Signed-off-by: example@example.com
* To Open a Security defect go to [https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security%20-%20Recipe%20Upgrade 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 ==
== Some security related links/useful tools ==


CVE details (http://www.cvedetails.com)
* [https://autobuilder.yocto.io/pub/non-release/patchmetrics/ Current CVE status for OE-Core/Poky] (generated by the Autobuilder)
CVE list, Linux kernel 2014 (http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html)
* [https://wiki.yoctoproject.org/wiki/images/5/58/Yocto_Summit_Lyon_Day1_2019.pdf#page=36 Yocto Project and CVEs, presentation by David Reyna in 2019 Yocto Developer day]
• Meta-security-layer (https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available)
* [https://github.com/nluedtke/linux_kernel_cves/ Linux kernel fixed and reported CVEs in all branches and point releases]
• Making images more secure (http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure)
** Note that cherry-picking CVE fixes for kernel is not recommended and users should merge full stable releases instead, see [http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/ What Stable Kernel Should I Use? by stable kernel maintainer Greg Kroah-Hartman]
• Cvechecker (http://cvechecker.sourceforge.net)  
* [http://www.cvedetails.com CVE details]
* [http://layers.openembedded.org/layerindex/branch/master/layer/meta-security/ Meta-security-layer]
* [https://docs.yoctoproject.org/dev-manual/securing-images.html Making Images More Secure] (Development Tasks Manual)


== Security Issues Addressed in Yocto Releases ==


== Security Issues Addressed in Yocto 1.7 / Poky x. ==
== Current work in progress ==
* [https://wiki.yoctoproject.org/wiki/Synchronization_CVEs Synchronization on the CVE work]
* [https://wiki.yoctoproject.org/wiki/Security_private_reporting Security team and private reporting]
* [https://wiki.yoctoproject.org/wiki/SECURITY_file SECURITY.md file]
* [https://wiki.yoctoproject.org/wiki/File:Yocto_Project_Security_-_26_09_2023.pdf Related slides]

Latest revision as of 15:56, 6 February 2024

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:

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

Security Issues Addressed in Yocto Releases

Current work in progress