Security: Difference between revisions

From Yocto Project
Jump to navigationJump to search
 
(68 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.  


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:
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:
Line 11: Line 11:




We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].  
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.
 
We also track CVEs reported to the oss-security list (Open Source Software Security) http://www.openwall.com/lists/oss-security/


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 ==
== Yocto Security Team ==
   
   
The purpose of creating a security team in the Yocto project is to discuss, sync and organize security related activities.
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].


'''The team's main responsibilities among others are:'''
'''Private List'''
: security [at] yoctoproject [dot] org
: For non-public or urgent issues.


*  Scanning of security forums/mailing list(s) to detect security vulnerabilities reported by community
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.
*  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'''
'''What you should do if you find a security vulnerability'''
---------------------------------------------
---------------------------------------------
Please send private vulnerability reports to '''security[at]yoctoprojct[dot]org'''.
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.
For secure communications, send your messages encrypted to '''sona[dot]sarmadi[at]enea[dot]com''' using the following GPG key:


Download public key: [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x773EF6EF68716A14 pgp.mit.edu]


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


== Branches maintained with security fixes ==
'''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.


{| class="wikitable"
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.
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
|1.7
|1.7
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|-
|1.6
|1.6.1
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|-
|1.5
|1.5.3
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[https://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}




All CVEs (security patches) should be backported to all branches above (if at all possible).
Versions in grey are no longer actively maintained, but well-tested security patches may still be accepted for them.)


'''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.)


See [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Stable branches maintenance]for detailed info regarding the policies and maintenance of Stable branch
== 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 ==


 
Kernel security patches are backported to Linux-yocto kernels regularly from https://www.kernel.org/
Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
=== Linux-yocto ===
=== Linux-yocto ===
linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Ross Burton)
linux-yocto_3 (maintainer: Bruce Ashfield)


=== Vendor kernels ===
=== Vendor kernels ===
Line 99: Line 74:
   
   
* meta-intel (meta-intel uses Linux-yocto)
* meta-intel (meta-intel uses Linux-yocto)
* meta-fsl-ppc (maintainer: xxx)
* meta-xilinx (meta-xilinx@lists.yoctoproject.org)
* meta-fsl-arm (maintainer: xxx)
* meta-ti (meta-ti@yoctoproject.org)
* meta-xilinx (maintainer: xxx)
* meta-ti (maintainer: xxx)
* etc
* etc


Line 112: Line 85:


If there isn’t any test case and it is complicated and time consuming to write a testcase
If there isn’t any test case and it is complicated and time consuming to write a testcase
  - Run the regressions test
  - Run the regression test




Line 121: Line 94:


== Patch name convention and commit message ==
== Patch name convention and commit message ==
Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.


Please make sure to add the package name in the subject and the reference to the CVE. Example for the commit comment:  
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]


     bash: CVE-2014-6278
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>
     <short description>
Line 132: Line 130:
      
      
     References
     References
     E.g. [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278 link to CVE] or other useful info/blog/advisory.
     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:  
     Signed-off-by: <your email address>
   
 
For additional guidelines refer to: [http://openembedded.org/wiki/Commit_Patch_Message_Guidelines Commit Patch Message Guidelines]
== Workflow of Yocto Project's bugzilla ==
* 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 ==


* [https://autobuilder.yocto.io/pub/non-release/patchmetrics/ Current CVE status for OE-Core/Poky] (generated by the Autobuilder)
* [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]
* [https://github.com/nluedtke/linux_kernel_cves/ 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 [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]
* [http://www.cvedetails.com CVE details]  
* [http://www.cvedetails.com CVE details]  
* [http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html  CVE list, Linux kernel 2014]
* [http://layers.openembedded.org/layerindex/branch/master/layer/meta-security/ Meta-security-layer]
* [https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available Meta-security-layer]
* [https://docs.yoctoproject.org/dev-manual/securing-images.html Making Images More Secure] (Development Tasks Manual)
* [http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure Making images more secure]
* [http://cvechecker.sourceforge.net Cvechecker]


== Security Issues Addressed in Yocto Releases ==
== Security Issues Addressed in Yocto Releases ==
'''Yocto 1.7.1 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy171
'''Yocto 1.7 - Dizzy'''
https://www.yoctoproject.org/downloads/core/dizzy17


'''Yocto 1.6 - Daisy'''
== Current work in progress ==
https://www.yoctoproject.org/downloads/core/daisy16
* [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