xref: /openbmc/openbmc/poky/documentation/dev-manual/vulnerabilities.rst (revision edff49234e31f23dc79f823473c9e286a21596c1)
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 poky/build/tmp/deploy/cve/flex-native
70   LAYER: meta
71   PACKAGE NAME: flex-native
72   PACKAGE VERSION: 2.6.4
73   CVE: CVE-2016-6354
74   CVE STATUS: Patched
75   CVE 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.
76   CVSS v2 BASE SCORE: 7.5
77   CVSS v3 BASE SCORE: 9.8
78   VECTOR: NETWORK
79   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
80
81   LAYER: meta
82   PACKAGE NAME: flex-native
83   PACKAGE VERSION: 2.6.4
84   CVE: CVE-2019-6293
85   CVE STATUS: Ignored
86   CVE 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.
87   CVSS v2 BASE SCORE: 4.3
88   CVSS v3 BASE SCORE: 5.5
89   VECTOR: NETWORK
90   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
91
92For images, a summary of all recipes included in the image and their CVEs is also
93generated in textual and JSON formats. These ``.cve`` and ``.json`` reports can be found
94in the ``tmp/deploy/images`` directory for each compiled image.
95
96At build time CVE check will also throw warnings about ``Unpatched`` CVEs::
97
98   WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
99   WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
100
101It is also possible to check the CVE status of individual packages as follows::
102
103   bitbake -c cve_check flex libarchive
104
105Fixing CVE product name and version mappings
106============================================
107
108By default, :ref:`ref-classes-cve-check` uses the recipe name :term:`BPN` as CVE
109product name when querying the CVE database. If this mapping contains false positives, e.g.
110some reported CVEs are not for the software component in question, or false negatives like
111some CVEs are not found to impact the recipe when they should, then the problems can be
112in the recipe name to CVE product mapping. These mapping issues can be fixed by setting
113the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of the software component in the
114upstream `NIST CVE database <https://nvd.nist.gov/>`__.
115
116The variable supports using vendor and product names like this::
117
118   CVE_PRODUCT = "flex_project:flex"
119
120In this example the vendor name used in the CVE database is ``flex_project`` and the
121product is ``flex``. With this setting the ``flex`` recipe only maps to this specific
122product and not products from other vendors with same name ``flex``.
123
124Similarly, when the recipe version :term:`PV` is not compatible with software versions used by
125the upstream software component releases and the CVE database, these can be fixed using
126the :term:`CVE_VERSION` variable.
127
128Note that if the CVE entries in the NVD database contain bugs or have missing or incomplete
129information, it is recommended to fix the information there directly instead of working
130around the issues possibly for a long time in Poky and OE-Core side recipes. Feedback to
131NVD about CVE entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__.
132
133Fixing vulnerabilities in recipes
134=================================
135
136Suppose a CVE security issue impacts a software component. In that case, it can
137be fixed by updating to a newer version, by applying a patch, or by marking it
138as patched via :term:`CVE_STATUS` variable flag. For Poky and OE-Core master
139branches, updating to a more recent software component release with fixes is
140the best option, but patches can be applied if releases are not yet available.
141
142For stable branches, we want to avoid API (Application Programming Interface)
143or ABI (Application Binary Interface) breakages. When submitting an update,
144a minor version update of a component is preferred if the version is
145backward-compatible. Many software components have backward-compatible stable
146versions, with a notable example of the Linux kernel. However, if the new
147version does or likely might introduce incompatibilities, extracting and
148backporting patches is preferred.
149
150Here is an example of fixing CVE security issues with patch files,
151an example from the :oe_layerindex:`ffmpeg recipe for dunfell </layerindex/recipe/122174>`::
152
153   SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
154              file://mips64_cpu_detection.patch \
155              file://CVE-2020-12284.patch \
156              file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
157              file://CVE-2021-3566.patch \
158              file://CVE-2021-38291.patch \
159              file://CVE-2022-1475.patch \
160              file://CVE-2022-3109.patch \
161              file://CVE-2022-3341.patch \
162              file://CVE-2022-48434.patch \
163          "
164
165The recipe has both generic and security-related fixes. The CVE patch files are named
166according to the CVE they fix.
167
168When preparing the patch file, take the original patch from the upstream repository.
169Do not use patches from different distributions, except if it is the only available source.
170
171Modify the patch adding OE-related metadata. We will follow the example of the
172``CVE-2022-3341.patch``.
173
174The original `commit message <https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e.patch/>`__
175is::
176
177   From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001
178   From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
179   Date: Wed, 23 Feb 2022 10:31:59 +0800
180   Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream
181
182   Check for failure of avformat_new_stream() and propagate
183   the error code.
184
185   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
186   ---
187    libavformat/nutdec.c | 16 ++++++++++++----
188    1 file changed, 12 insertions(+), 4 deletions(-)
189
190
191For the correct operations of the ``cve-check``, it requires the CVE
192identification in a ``CVE:`` tag of the patch file commit message using
193the format::
194
195   CVE: CVE-2022-3341
196
197It is also recommended to add the ``Upstream-Status:`` tag with a link
198to the original patch and sign-off by people working on the backport.
199If there are any modifications to the original patch, note them in
200the ``Comments:`` tag.
201
202With the additional information, the header of the patch file in OE-core becomes::
203
204   From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001
205   From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
206   Date: Wed, 23 Feb 2022 10:31:59 +0800
207   Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream
208
209   Check for failure of avformat_new_stream() and propagate
210   the error code.
211
212   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
213
214   CVE: CVE-2022-3341
215
216   Upstream-Status: Backport [https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e]
217
218   Comments: Refreshed Hunk
219   Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
220   Signed-off-by: Bhabu Bindu <bhabu.bindu@kpit.com>
221   ---
222    libavformat/nutdec.c | 16 ++++++++++++----
223    1 file changed, 12 insertions(+), 4 deletions(-)
224
225A good practice is to include the CVE identifier in the patch file name, the patch file
226commit message and optionally in the recipe commit message.
227
228CVE checker will then capture this information and change the CVE status to ``Patched``
229in the generated reports.
230
231If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
232version or other reasons, the CVE can be marked as ``Ignored`` by using
233the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``.
234The entry should have the format like::
235
236   CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded"
237
238As mentioned previously, if data in the CVE database is wrong, it is recommended
239to fix those issues in the CVE database (NVD in the case of OE-core and Poky)
240directly.
241
242Note that if there are many CVEs with the same status and reason, those can be
243shared by using the :term:`CVE_STATUS_GROUPS` variable.
244
245Recipes can be completely skipped by CVE check by including the recipe name in
246the :term:`CVE_CHECK_SKIP_RECIPE` variable.
247
248Implementation details
249======================
250
251Here's what the :ref:`ref-classes-cve-check` class does to find unpatched CVE IDs.
252
253First the code goes through each patch file provided by a recipe. If a valid CVE ID
254is found in the name of the file, the corresponding CVE is considered as patched.
255Don't forget that if multiple CVE IDs are found in the filename, only the last
256one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch
257file. The found CVE IDs are also considered as patched.
258Additionally ``CVE_STATUS`` variable flags are parsed for reasons mapped to ``Patched``
259and these are also considered as patched.
260
261Then, the code looks up all the CVE IDs in the NIST database for all the
262products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
263
264-  If the package name (:term:`PN`) is part of
265   :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``.
266
267-  If the CVE ID has status ``CVE_STATUS[<CVE ID>] = "ignored"`` or if it's set to
268   any reason which is mapped to status ``Ignored`` via ``CVE_CHECK_STATUSMAP``,
269   it is  set as ``Ignored``.
270
271-  If the CVE ID is part of the patched CVE for the recipe, it is
272   already considered as ``Patched``.
273
274-  Otherwise, the code checks whether the recipe version (:term:`PV`)
275   is within the range of versions impacted by the CVE. If so, the CVE
276   is considered as ``Unpatched``.
277
278The CVE database is stored in :term:`DL_DIR` and can be inspected using
279``sqlite3`` command as follows::
280
281   sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
282
283When analyzing CVEs, it is recommended to:
284
285-  study the latest information in `CVE database <https://nvd.nist.gov/vuln/search>`__.
286
287-  check how upstream developers of the software component addressed the issue, e.g.
288   what patch was applied, which upstream release contains the fix.
289
290-  check what other Linux distributions like `Debian <https://security-tracker.debian.org/tracker/>`__
291   did to analyze and address the issue.
292
293-  follow security notices from other Linux distributions.
294
295-  follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailing-lists>`__ for
296   discussions and advance notifications of CVE bugs and software releases with fixes.
297
298