1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3Checking for Vulnerabilities 4**************************** 5 6Vulnerabilities in Poky and OE-Core 7=================================== 8 9The Yocto Project has an infrastructure to track and address unfixed 10known security vulnerabilities, as tracked by the public 11:wikipedia:`Common Vulnerabilities and Exposures (CVE) <Common_Vulnerabilities_and_Exposures>` 12database. 13 14The Yocto Project maintains a `list of known vulnerabilities 15<https://autobuilder.yocto.io/pub/non-release/patchmetrics/>`__ 16for packages in Poky and OE-Core, tracking the evolution of the number of 17unpatched CVEs and the status of patches. Such information is available for 18the current development version and for each supported release. 19 20Security is a process, not a product, and thus at any time, a number of security 21issues may be impacting Poky and OE-Core. It is up to the maintainers, users, 22contributors and anyone interested in the issues to investigate and possibly fix them by 23updating software components to newer versions or by applying patches to address them. 24It is recommended to work with Poky and OE-Core upstream maintainers and submit 25patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details. 26 27Vulnerability check at build time 28================================= 29 30To enable a check for CVE security vulnerabilities using 31:ref:`ref-classes-cve-check` in the specific image or target you are building, 32add the following setting to your configuration:: 33 34 INHERIT += "cve-check" 35 36The CVE database contains some old incomplete entries which have been 37deemed not to impact Poky or OE-Core. These CVE entries can be excluded from the 38check using build configuration:: 39 40 include conf/distro/include/cve-extra-exclusions.inc 41 42With this CVE check enabled, BitBake build will try to map each compiled software component 43recipe name and version information to the CVE database and generate recipe and 44image specific reports. These reports will contain: 45 46- metadata about the software component like names and versions 47 48- metadata about the CVE issue such as description and NVD link 49 50- for each software component, a list of CVEs which are possibly impacting this version 51 52- status of each CVE: ``Patched``, ``Unpatched`` or ``Ignored`` 53 54The status ``Patched`` means that a patch file to address the security issue has been 55applied. ``Unpatched`` status means that no patches to address the issue have been 56applied and that the issue needs to be investigated. ``Ignored`` means that after 57analysis, it has been deemed to ignore the issue as it for example affects 58the software component on a different operating system platform. 59 60By default, no NVD API key is used to retrieve data from the CVE database, which 61results in larger delays between NVD API requests. See the :term:`NVDCVE_API_KEY` 62documentation on how to request and set a NVD API key. 63 64After a build with CVE check enabled, reports for each compiled source recipe will be 65found in ``build/tmp/deploy/cve``. 66 67For example the CVE check report for the ``flex-native`` recipe looks like:: 68 69 $ cat ./tmp/deploy/cve/flex-native_cve.json 70 { 71 "version": "1", 72 "package": [ 73 { 74 "name": "flex-native", 75 "layer": "meta", 76 "version": "2.6.4", 77 "products": [ 78 { 79 "product": "flex", 80 "cvesInRecord": "No" 81 }, 82 { 83 "product": "flex", 84 "cvesInRecord": "Yes" 85 } 86 ], 87 "issue": [ 88 { 89 "id": "CVE-2006-0459", 90 "status": "Patched", 91 "link": "https://nvd.nist.gov/vuln/detail/CVE-2006-0459", 92 "summary": "flex.skl in Will Estes and John Millaway Fast Lexical Analyzer Generator (flex) before 2.5.33 does not allocate enough memory for grammars containing (1) REJECT statements or (2) trailing context rules, which causes flex to generate code that contains a buffer overflow that might allow context-dependent attackers to execute arbitrary code.", 93 "scorev2": "7.5", 94 "scorev3": "0.0", 95 "scorev4": "0.0", 96 "modified": "2024-11-21T00:06Z", 97 "vector": "NETWORK", 98 "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", 99 "detail": "version-not-in-range" 100 }, 101 { 102 "id": "CVE-2016-6354", 103 "status": "Patched", 104 "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-6354", 105 "summary": "Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.", 106 "scorev2": "7.5", 107 "scorev3": "9.8", 108 "scorev4": "0.0", 109 "modified": "2024-11-21T02:55Z", 110 "vector": "NETWORK", 111 "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", 112 "detail": "version-not-in-range" 113 }, 114 { 115 "id": "CVE-2019-6293", 116 "status": "Ignored", 117 "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-6293", 118 "summary": "An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.", 119 "scorev2": "4.3", 120 "scorev3": "5.5", 121 "scorev4": "0.0", 122 "modified": "2024-11-21T04:46Z", 123 "vector": "NETWORK", 124 "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", 125 "detail": "upstream-wontfix", 126 "description": "there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address this." 127 } 128 ] 129 } 130 ] 131 } 132 133For images, a summary of all recipes included in the image and their CVEs is also 134generated in the JSON format. These ``.json`` reports can be found 135in the ``tmp/deploy/images`` directory for each compiled image. 136 137At build time CVE check will also throw warnings about ``Unpatched`` CVEs:: 138 139 WARNING: qemu-native-9.2.0-r0 do_cve_check: Found unpatched CVE (CVE-2023-1386) 140 141It is also possible to check the CVE status of individual packages as follows:: 142 143 bitbake -c cve_check flex libarchive 144 145Fixing CVE product name and version mappings 146============================================ 147 148By default, :ref:`ref-classes-cve-check` uses the recipe name :term:`BPN` as CVE 149product name when querying the CVE database. If this mapping contains false positives, e.g. 150some reported CVEs are not for the software component in question, or false negatives like 151some CVEs are not found to impact the recipe when they should, then the problems can be 152in the recipe name to CVE product mapping. These mapping issues can be fixed by setting 153the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of the software component in the 154upstream `NIST CVE database <https://nvd.nist.gov/>`__. 155 156The variable supports using vendor and product names like this:: 157 158 CVE_PRODUCT = "flex_project:flex westes:flex" 159 160In this example we have two possible vendors names, ``flex_project`` and ``westes``, 161with the product name ``flex``. With this setting the ``flex`` recipe only maps to this specific 162product and not products from other vendors with same name ``flex``. 163 164Similarly, when the recipe version :term:`PV` is not compatible with software versions used by 165the upstream software component releases and the CVE database, these can be fixed using 166the :term:`CVE_VERSION` variable. 167 168Note that if the CVE entries in the NVD database contain bugs or have missing or incomplete 169information, it is recommended to fix the information there directly instead of working 170around the issues possibly for a long time in Poky and OE-Core side recipes. Feedback to 171NVD about CVE entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__. 172 173Fixing vulnerabilities in recipes 174================================= 175 176Suppose a CVE security issue impacts a software component. In that case, it can 177be fixed by updating to a newer version, by applying a patch, or by marking it 178as patched via :term:`CVE_STATUS` variable flag. For Poky and OE-Core master 179branches, updating to a more recent software component release with fixes is 180the best option, but patches can be applied if releases are not yet available. 181 182For stable branches, we want to avoid API (Application Programming Interface) 183or ABI (Application Binary Interface) breakages. When submitting an update, 184a minor version update of a component is preferred if the version is 185backward-compatible. Many software components have backward-compatible stable 186versions, with a notable example of the Linux kernel. However, if the new 187version does or likely might introduce incompatibilities, extracting and 188backporting patches is preferred. 189 190Here is an example of fixing CVE security issues with patch files, 191an example from the :oe_layerindex:`ffmpeg recipe for dunfell </layerindex/recipe/122174>`:: 192 193 SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \ 194 file://mips64_cpu_detection.patch \ 195 file://CVE-2020-12284.patch \ 196 file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \ 197 file://CVE-2021-3566.patch \ 198 file://CVE-2021-38291.patch \ 199 file://CVE-2022-1475.patch \ 200 file://CVE-2022-3109.patch \ 201 file://CVE-2022-3341.patch \ 202 file://CVE-2022-48434.patch \ 203 " 204 205The recipe has both generic and security-related fixes. The CVE patch files are named 206according to the CVE they fix. 207 208When preparing the patch file, take the original patch from the upstream repository. 209Do not use patches from different distributions, except if it is the only available source. 210 211Modify the patch adding OE-related metadata. We will follow the example of the 212``CVE-2022-3341.patch``. 213 214The original `commit message <https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e.patch/>`__ 215is:: 216 217 From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001 218 From: Jiasheng Jiang <jiasheng@iscas.ac.cn> 219 Date: Wed, 23 Feb 2022 10:31:59 +0800 220 Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream 221 222 Check for failure of avformat_new_stream() and propagate 223 the error code. 224 225 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> 226 --- 227 libavformat/nutdec.c | 16 ++++++++++++---- 228 1 file changed, 12 insertions(+), 4 deletions(-) 229 230 231For the correct operations of the ``cve-check``, it requires the CVE 232identification in a ``CVE:`` tag of the patch file commit message using 233the format:: 234 235 CVE: CVE-2022-3341 236 237It is also recommended to add the ``Upstream-Status:`` tag with a link 238to the original patch and sign-off by people working on the backport. 239If there are any modifications to the original patch, note them in 240the ``Comments:`` tag. 241 242With the additional information, the header of the patch file in OE-core becomes:: 243 244 From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001 245 From: Jiasheng Jiang <jiasheng@iscas.ac.cn> 246 Date: Wed, 23 Feb 2022 10:31:59 +0800 247 Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream 248 249 Check for failure of avformat_new_stream() and propagate 250 the error code. 251 252 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> 253 254 CVE: CVE-2022-3341 255 256 Upstream-Status: Backport [https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e] 257 258 Comments: Refreshed Hunk 259 Signed-off-by: Narpat Mali <narpat.mali@windriver.com> 260 Signed-off-by: Bhabu Bindu <bhabu.bindu@kpit.com> 261 --- 262 libavformat/nutdec.c | 16 ++++++++++++---- 263 1 file changed, 12 insertions(+), 4 deletions(-) 264 265A good practice is to include the CVE identifier in the patch file name, the patch file 266commit message and optionally in the recipe commit message. 267 268CVE checker will then capture this information and change the CVE status to ``Patched`` 269in the generated reports. 270 271If analysis shows that the CVE issue does not impact the recipe due to configuration, platform, 272version or other reasons, the CVE can be marked as ``Ignored`` by using 273the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``. 274The entry should have the format like:: 275 276 CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded" 277 278As mentioned previously, if data in the CVE database is wrong, it is recommended 279to fix those issues in the CVE database (NVD in the case of OE-core and Poky) 280directly. 281 282Note that if there are many CVEs with the same status and reason, those can be 283shared by using the :term:`CVE_STATUS_GROUPS` variable. 284 285Recipes can be completely skipped by CVE check by including the recipe name in 286the :term:`CVE_CHECK_SKIP_RECIPE` variable. 287 288Implementation details 289====================== 290 291Here's what the :ref:`ref-classes-cve-check` class does to find unpatched CVE IDs. 292 293First the code goes through each patch file provided by a recipe. If a valid CVE ID 294is found in the name of the file, the corresponding CVE is considered as patched. 295Don't forget that if multiple CVE IDs are found in the filename, only the last 296one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch 297file. The found CVE IDs are also considered as patched. 298Additionally ``CVE_STATUS`` variable flags are parsed for reasons mapped to ``Patched`` 299and these are also considered as patched. 300 301Then, the code looks up all the CVE IDs in the NIST database for all the 302products defined in :term:`CVE_PRODUCT`. Then, for each found CVE: 303 304- If the package name (:term:`PN`) is part of 305 :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``. 306 307- If the CVE ID has status ``CVE_STATUS[<CVE ID>] = "ignored"`` or if it's set to 308 any reason which is mapped to status ``Ignored`` via ``CVE_CHECK_STATUSMAP``, 309 it is set as ``Ignored``. 310 311- If the CVE ID is part of the patched CVE for the recipe, it is 312 already considered as ``Patched``. 313 314- Otherwise, the code checks whether the recipe version (:term:`PV`) 315 is within the range of versions impacted by the CVE. If so, the CVE 316 is considered as ``Unpatched``. 317 318The CVE database is stored in :term:`DL_DIR` and can be inspected using 319``sqlite3`` command as follows:: 320 321 sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462 322 323When analyzing CVEs, it is recommended to: 324 325- study the latest information in `CVE database <https://nvd.nist.gov/vuln/search>`__. 326 327- check how upstream developers of the software component addressed the issue, e.g. 328 what patch was applied, which upstream release contains the fix. 329 330- check what other Linux distributions like `Debian <https://security-tracker.debian.org/tracker/>`__ 331 did to analyze and address the issue. 332 333- follow security notices from other Linux distributions. 334 335- follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailing-lists>`__ for 336 discussions and advance notifications of CVE bugs and software releases with fixes. 337 338