{"id":8099,"date":"2026-10-27T06:00:00","date_gmt":"2026-10-27T05:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=8099"},"modified":"2026-10-25T17:14:40","modified_gmt":"2026-10-25T16:14:40","slug":"filtrer-les-vulnerabilites-du-kernel-sur-un-systeme-embarque","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2026\/10\/27\/filtrer-les-vulnerabilites-du-kernel-sur-un-systeme-embarque\/","title":{"rendered":"Filtrer les vuln\u00e9rabilit\u00e9s du kernel sur un syst\u00e8me embarqu\u00e9"},"content":{"rendered":"
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Le suivi des vuln\u00e9rabilit\u00e9s d’un syst\u00e8me embarqu\u00e9 est essentiel. Nous avons vu dans l’article pr\u00e9c\u00e9dent<\/strong><\/a> comment analyser les fichiers produits par Yocto Project<\/strong> pour extraire la liste des CVE (Common Vulnerabilities and Exposures<\/em>) pr\u00e9sentes lors d’une production d’image. Nous avions observ\u00e9 que des vuln\u00e9rabilit\u00e9s \u00e9taient en nombre limit\u00e9 pour la plupart des packages, mais qu’un nombre astronomique de CVE<\/strong> \u00e9taient mentionn\u00e9 pour le kernel Linux.<\/p>\n\n\n\n

Nous allons voir \u00e0 pr\u00e9sent comment filtrer les r\u00e9sultats pour n’avoir \u00e0 traiter qu’un nombre raisonnable de vuln\u00e9rabilit\u00e9s.<\/p>\n\n\n\n\n\n\n\n

L’actualit\u00e9 est particuli\u00e8rement riche en ce qui concerne la cybers\u00e9curit\u00e9, notamment pour les syst\u00e8mes embarqu\u00e9s. Apr\u00e8s l’entr\u00e9e en vigueur des obligations de notifications incluses dans le Cyber Resilience Act<\/strong><\/em> d\u00e9but septembre, apr\u00e8s la faille de s\u00e9curit\u00e9 touchant les groupes frigorifiques<\/strong> d\u00e9but octobre, la semaine pass\u00e9e a \u00e9t\u00e9 bien remplie \u00e0 v\u00e9rifier les versions de PHP et mettre \u00e0 jour les syst\u00e8mes concern\u00e9s. Contrairement \u00e0 ce que l’on peut imaginer, les vuln\u00e9rabilit\u00e9s de PHP<\/strong> ne concernent pas uniquement les serveurs, mais aussi des \u00e9quipements embarqu\u00e9s qui l’emploient pour proposer une IHM sur leur port HTTP\/HTTPS.<\/p>\n\n\n\n

Il est donc plus que jamais crucial de d\u00e9terminer d\u00e8s la production initiale d’un syst\u00e8me embarqu\u00e9 les \u00e9ventuelles vuln\u00e9rabilit\u00e9s pr\u00e9sentes pour les \u00e9liminer, et s’assurer r\u00e9guli\u00e8rement de l’absence de nouvelles failles exploitables.<\/p>\n\n\n\n

Production d’une image<\/h1>\n\n\n\n
$ python3  -m venv  cooker-env<\/strong>\n$ source  cooker-env\/bin\/activate<\/strong>\n$ pip3  install  yocto-cooker<\/strong>\n  [...]<\/code><\/pre>\n\n\n\n
Je clone ensuite le repository<\/em> de Cooker pour prendre le menu d’exemple qemu-sample-menu-blacksail.json<\/code> bas\u00e9 sur la derni\u00e8re branche de Yocto Project, Blacksail<\/strong>, publi\u00e9e la semaine pass\u00e9e. <\/p>\n\n\n\n
$ git  clone  https:\/\/github.com\/cpb-\/yocto-cooker<\/strong>\n  [...]\n\n$ cp  yocto-cooker\/sample-menus\/qemu-sample-menu-blacksail.json  .<\/strong><\/code><\/pre>\n\n\n\n
Je l’\u00e9dite pour ajouter une ligne dans la section local.conf<\/code> :<\/p>\n\n\n\n
\"local.conf\": [\n    \"MACHINE = 'qemuarm'                     \",\n    \"DISTRO  = 'poky'                        \",\n    \"IMAGE_FEATURES += 'empty-root-password' \",\n    \"OE_FRAGMENTS += 'core\/yocto\/sbom-cve-check' \"<\/strong>\n]<\/code><\/pre>\n\n\n\n
Nous l’avons vu dans l’article pr\u00e9c\u00e9dent, cela permet d’extraire la liste des vuln\u00e9rabilit\u00e9s connues<\/strong> dans les packages produits.<\/p>\n\n\n\n
Lan\u00e7ons la compilation :<\/p>\n\n\n\n
$ cooker  cook  qemu-sample-menu-blacksail.json<\/strong>\n  [...]\nWARNING: core-image-base-1.0-r0 do_sbom_cve_check: alsa-lib-1.2.16.1: Found unpatched CVEs: CVE-2026-90781, CVE-2026-96674, CVE-2026-96675\nWARNING: core-image-base-1.0-r0 do_sbom_cve_check: busybox-1.38.0: Found unpatched CVEs: CVE-2026-38752, CVE-2026-38753, CVE-2026-38755\nWARNING: core-image-base-1.0-r0 do_sbom_cve_check: expat-2.8.5: Found unpatched CVEs: CVE-2026-102633, CVE-2026-113351, CVE-2026-115506, CVE-2026-77214\n [...]\nWARNING: core-image-base-1.0-r0 do_sbom_cve_check: linux-yocto-7.2.6+git: Found unpatched CVEs: CVE-1999-0524, CVE-2010-4563, CVE-2019-14899,  [...] CVE-2026-99077, CVE-2026-99080, CVE-2026-99084, CVE-2026-99085, CVE-2026-99999\n [...]\nNOTE: Tasks Summary: Attempted 6164 tasks of which 6142 didn't need to be rerun and all succeeded.\n\nSummary: There were 14 WARNING messages.<\/code><\/pre>\n\n\n\n
Les quatorze warnings indiquent que certains composants contiennent des vuln\u00e9rabilit\u00e9s connues.<\/p>\n\n\n\n
Liste des vuln\u00e9rabilit\u00e9s pr\u00e9sentes : cve-parse<\/h1>\n\n\n\n
Je clone le repository de Yocto CVE Parse<\/strong> comme nous l’avons vu dans l’article pr\u00e9c\u00e9dent<\/a> :<\/p>\n\n\n\n
$ git  clone  https:\/\/github.com\/cpb-\/yocto-cve-parser<\/strong>\n  [...]<\/code><\/pre>\n\n\n\n
Je demande \u00e0 cve-parse<\/code> une liste compl\u00e8te, en filtrant les packages effectivement pr\u00e9sents<\/strong> :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  builds\/build-qemuarm\/tmp\/deploy\/images\/qemuarm\/core-image-base-qemuarm.rootfs.sbom-cve-check.yocto.json  -f builds\/build-qemuarm\/tmp\/deploy\/images\/qemuarm\/core-image-base-qemuarm.rootfs.spdx.json  --restricted<\/strong>\nCOMPONENT    VERSION    TOTAL  PATCHED  UNPATCHED  IGNORED  OTHER\nacl          2.4.0      4      4        0          0        0\nalsa-lib     1.2.16.1   6      3        3          0        0\navahi        0.9~rc5    26     25       0          1        0\nbase-files   3.0.14     1      0        0          1        0\nbluez5       5.87       43     40       0          3        0\nbusybox      1.38.0     49     46       3          0        0\ndbus         1.16.2     26     26       0          0        0\ndosfstools   4.2        2      2        0          0        0\nexpat        2.8.5      72     68       4          0        0\nglib-2.0     2.90.0     35     35       0          0        0\nglibc        2.44+git   179    163      10         6        0\ninitscripts  1.0        2      2        0          0        0\nlibcap       2.78       5      5        0          0        0\nlibffi       3.8.0      1      1        0          0        0\nlibgcc       16.2.0     16     16       0          0        0\nlibpcre2     10.48      19     18       1          0        0\nlibtirpc     1.3.8      5      5        0          0        0\nlibx11       1.8.13     22     18       4          0        0\nlibxcb       1.17.0     1      1        0          0        0\nlibxdmcp     1.1.5      1      1        0          0        0\nlibxml2      2.15.4     120    120      0          0        0\nlinux-yocto  7.2.6+git  21502  20243    418        841      0<\/strong>\nncurses      6.6        31     31       0          0        0\nopenssl      4.0.3      322    321      0          1        0\nreadline     8.3        1      1        0          0        0\nrpcbind      1.3.1      4      4        0          0        0\nshadow       4.20.2     13     12       0          1        0\ntar          1.35       20     17       2          1        0\nttyrun       2.44.0     1      1        0          0        0\nutil-linux   2.42.4     35     34       1          0        0\nxz           5.8.4      9      8        0          1        0\nzlib         1.3.2      16     14       2          0        0\nTOTAL                   22589  21285    448        856      0\n\nComponents: 32; unique CVEs: 22586<\/code><\/pre>\n\n\n\n
L’option --restricted<\/strong><\/code> de cve-parse<\/code> a \u00e9t\u00e9 ajout\u00e9e depuis le dernier article. Elle permet de n’afficher que les packages avec un total de vuln\u00e9rabilit\u00e9s non nul.<\/p>\n\n\n\n
Une ligne attire le regard, celle du kernel : linux-yocto<\/code> avec plus de 20000 enregistrements CVE<\/strong> et plus de 400 class\u00e9s \u00ab\u00a0Unpatched<\/em>\u00a0\u00bb !<\/p>\n\n\n\n
Lors de sa conf\u00e9rence \u00ab\u00a0Security in the LLM age<\/strong><\/a><\/em>\u00a0\u00bb aux Kernel Recipes 2026<\/strong> Greg Kroah Hartman, le mainteneur des branches stable<\/em> et long-term<\/em> du noyau, a abord\u00e9 l’augmentation du nombre de CVE. Avec l’arriv\u00e9e des LLM, le nombre de CVE enregistr\u00e9es est pass\u00e9 d’une cinquantaine par semaine il y a un an (ce qui semblait  d\u00e9j\u00e0 \u00e9norme) \u00e0 33 par jour<\/strong> \u00e0 pr\u00e9sent.<\/p>\n\n\n\n
La plupart d’entre-elles sont b\u00e9nignes ou inapplicables (je vous conseille de voir son analyse des 79 vuln\u00e9rabilit\u00e9s m\u00e9diatis\u00e9es comme \u00ab\u00a0d\u00e9couvertes par Mythos\u00a0\u00bb), mais cela n\u00e9cessite quand m\u00eame une analyse cas-par-cas, ce qui lui impose une charge de travail \u00e9lev\u00e9e.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Nous ne sommes pas \u00e0 la m\u00eame \u00e9chelle ici : il n’y a \u00ab\u00a0que\u00a0\u00bb 400 CVE non-patch\u00e9es, mais c’est quand m\u00eame trop pour la maintenance r\u00e9guli\u00e8re d’un syst\u00e8me embarqu\u00e9. Nous allons utiliser un script fourni par Open Embedded<\/em> pour conserver uniquement les vuln\u00e9rabilit\u00e9s se trouvant dans des portions de code compil\u00e9es pour notre image.<\/p>\n\n\n\n
Filtrage des vuln\u00e9rabilit\u00e9s kernel<\/h1>\n\n\n\n
Tout d’abord nous devons ajouter deux lignes au local.conf<\/code> et relancer le build<\/em> (oui, on aurait pu le faire plus t\u00f4t, mais je pr\u00e9f\u00e8re expliquer mes actions progressivement).<\/p>\n\n\n\n
\"local.conf\": [\n    \"MACHINE = 'qemuarm'                     \",\n    \"DISTRO  = 'poky'                        \",\n    \"IMAGE_FEATURES += 'empty-root-password' \",\n    \"OE_FRAGMENTS += 'core\/yocto\/sbom-cve-check' \",\n    \"KERNEL_EXTRA_FEATURES:append = ' features\/debug\/debug-kernel.scc' \",<\/strong>\n    \"SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = '1' \"<\/strong>\n]<\/code><\/pre>\n\n\n\n
Apr\u00e8s avoir relanc\u00e9 le build<\/em> avec cooker cook qemu-sample-menu-blacksail.json<\/strong><\/code> le fichier builds\/build-qemuarm\/tmp\/deploy\/images\/qemuarm\/core-image-base-qemuarm.rootfs.spdx.json<\/code> contient entre autres la liste des fichiers sources du noyau qui ont \u00e9t\u00e9 compil\u00e9s. En voici un exemple :<\/p>\n\n\n\n
{\n      \"type\": \"software_File\",\n      \"spdxId\": \"http:\/\/spdx.org\/spdxdocs\/linux-yocto-f9f75dbe-e63f-5a48-86d8-e19d0ec693db\/9439fb773aa0308ba9f94d1c42b7902cda81ba3dfd21aaa3cb263aa740994f85\/sourcefile\/14760\",\n      \"software_primaryPurpose\": \"source\",\n      \"creationInfo\": \"_:CreationInfo4\",\n      \"name\": \"linux-yocto-7.2.6+git\/arch\/arm\/kernel\/irq.c\",\n      \"verifiedUsing\": [\n        {\n          \"type\": \"Hash\",\n          \"algorithm\": \"sha256\",\n          \"hashValue\": \"99c925c2016f219c9e8320da093959374194fb7cfbdad22f6a6457660b77188d\"\n        },\n        {\n          \"type\": \"Hash\",\n          \"algorithm\": \"sha512\",\n          \"hashValue\": \"070cbf06eee488298f5706644b1e0fecdc6a88f2aee5f9c09effbcb10eff9e241415107cfa44c5d643990a8ce233df205c991a6e3d4ad7d604e68d950976eb93\"\n        }\n      ]\n    },<\/code><\/pre>\n\n\n\n
Nous allons \u00e0 pr\u00e9sent r\u00e9cup\u00e9rer la base de donn\u00e9es des CVE actuelles du kernel<\/strong>. Depuis deux ans et demi, la \u00ab\u00a0Linux Kernel Organization<\/em>\u00a0\u00bb est devenue autorit\u00e9 d’identification des CVE li\u00e9es au kernel et la quantit\u00e9 de vuln\u00e9rabilit\u00e9s enregistr\u00e9es a sensiblement augment\u00e9.<\/p>\n\n\n\n
$ git  clone  https:\/\/git.kernel.org\/pub\/scm\/linux\/security\/vulns.git<\/strong>\n  [...]<\/code><\/pre>\n\n\n\n
Nous appelons un script fourni dans le layer openembedded-core<\/code> qui va filtrer les vuln\u00e9rabilit\u00e9s en se limitant aux fichiers source effectivement compil\u00e9s durant notre build<\/em>. Pour le faire fonctionner j’ai d\u00fb ajouter sur ma machine un module Python avec python3 -m pip install zstandard<\/strong><\/code>.<\/p>\n\n\n\n
Le script va consulter le r\u00e9pertoire de vuln\u00e9rabilit\u00e9s indiqu\u00e9 par l’option --datadir<\/strong><\/code>, utiliser le fichier fourni avec l’option --debug-sources-file<\/strong><\/code> pour conna\u00eetre les fichiers effectivement compil\u00e9s, lire le rapport donn\u00e9 par --old-cve-report<\/strong><\/code> et remplir le fichier mentionn\u00e9 par l’option --new-cve-report<\/strong><\/code>.<\/p>\n\n\n\n
$ python3  .\/layers\/openembedded-core\/scripts\/contrib\/improve_kernel_cve_report.py   --datadir vulns\/  --debug-sources-file  builds\/build-qemuarm\/tmp\/pkgdata\/qemuarm\/debugsources\/linux-yocto-debugsources.json.zstd  --old-cve-report  builds\/build-qemuarm\/tmp\/deploy\/images\/qemuarm\/core-image-base-qemuarm.rootfs.sbom-cve-check.yocto.json  --new-cve-report  filtered-cve.json<\/strong>\n[improve_kernel_cve_report.py:445] Total compiled files 5482\n[improve_kernel_cve_report.py:478] Checking kernel 7.2.6+git\n[improve_kernel_cve_report.py:93] CVE-2024-0000 doesn't have good metadata\n[improve_kernel_cve_report.py:93] CVE-2024-0053 doesn't have good metadata\n[improve_kernel_cve_report.py:193] Total CVEs ignored due to not applicable config: 1232\n[improve_kernel_cve_report.py:194] Total CVEs not vulnerable due version-not-in-range: 16806\n[improve_kernel_cve_report.py:195] Total vulnerable CVEs: 0\n[improve_kernel_cve_report.py:197] Total CVEs already backported in 7.2: 0\n[improve_kernel_cve_report.py:482] Total kernel cves from kernel CNA: 18360\n[improve_kernel_cve_report.py:484] Total kernel before processing cves: 21502\n[improve_kernel_cve_report.py:492] Total kernel cves after processing: 21826<\/code><\/pre>\n\n\n\n
Les deux derni\u00e8res lignes peuvent laisser perplexe : on passe de 21502 \u00e0 21826, ce n’est pas un filtrage tr\u00e8s efficace ! En r\u00e9alit\u00e9 le script enrichit le rapport et peut ajouter des entr\u00e9es, il ne fait pas que supprimer des lignes. N\u00e9anmoins le nombre de CVE non patch\u00e9es est plus raisonnable. J’utilise le fichier filtr\u00e9 pour alimenter cve-parse<\/code> :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  --component linux-yocto  -u --stat<\/strong>\nCOMPONENT    VERSION    TOTAL  PATCHED  UNPATCHED  IGNORED  OTHER\nlinux-yocto  7.2.6+git  11     0        11         0        0\nTOTAL                   11     0        11         0        0<\/code><\/pre>\n\n\n\n
Onze vuln\u00e9rabilit\u00e9s non-patch\u00e9es<\/strong>, nous avons bien progress\u00e9. Voyons les num\u00e9ros de CVE :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  --component linux-yocto  -u <\/strong>\nCOMPONENT    VERSION    CVE             STATUS     CVSS  SCORE  SEVERITY\nlinux-yocto  7.2.6+git  CVE-2023-3640   Unpatched  3.x   7.8    High\nlinux-yocto  7.2.6+git  CVE-2019-14899  Unpatched  3.x   7.4    High\nlinux-yocto  7.2.6+git  CVE-2021-3864   Unpatched  3.x   7.0    High\nlinux-yocto  7.2.6+git  CVE-2023-3397   Unpatched  3.x   7.0    High\nlinux-yocto  7.2.6+git  CVE-2023-6238   Unpatched  3.x   6.7    Medium\nlinux-yocto  7.2.6+git  CVE-2023-6240   Unpatched  3.x   6.5    Medium\nlinux-yocto  7.2.6+git  CVE-2021-3714   Unpatched  3.x   5.9    Medium\nlinux-yocto  7.2.6+git  CVE-2020-10774  Unpatched  3.x   5.5    Medium\nlinux-yocto  7.2.6+git  CVE-2022-4543   Unpatched  3.x   5.5    Medium\nlinux-yocto  7.2.6+git  CVE-2010-4563   Unpatched  2.0   5.0    Medium\nlinux-yocto  7.2.6+git  CVE-1999-0524   Unpatched  3.x   4.0    Medium<\/code><\/pre>\n\n\n\n
Examen des CVE restantes<\/h1>\n\n\n\n
Nous allons examiner en d\u00e9tail les quelques vuln\u00e9rabilit\u00e9s les plus critiques (colonne SCORE<\/code> les plus \u00e9lev\u00e9es).<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  cve CVE-2023-3640  --details<\/strong>\ncomponent: linux-yocto\nversion: 7.2.6+git\nlayer: core\ncve: CVE-2023-3640\nstatus: Unpatched\ncvss: 3.x\nscore: 7.8\nseverity: High\nissue.id: CVE-2023-3640\nissue.status: Unpatched\nissue.link: https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2023-3640\nissue.summary: A possible unauthorized memory access flaw was found in the Linux kernel's cpu_entry_area mapping of X86 CPU data to memory, where a user may guess the location of exception stacks or other important data. Based on the previous CVE-2023-0597, the 'Randomize per-cpu entry area' feature was implemented in \/arch\/x86\/mm\/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. This issue could allow a local user to gain access to some important data with memory in an expected location and potentially escalate their privileges on the system.\nissue.scorev2: 0.0\nissue.scorev3: 7.8\nissue.scorev4: 0.0\nissue.modified: 2026-07-21T20:05:58.000\nissue.vector: LOCAL\nissue.vectorString: CVSS:3.1\/AV:L\/AC:L\/PR:L\/UI:N\/S:U\/C:H\/I:H\/A:H\nissue.detail: no-version-ranges\nissue.description: Check package version<\/code><\/pre>\n\n\n\n
La description vise clairement du code x86. Notre script l’a affich\u00e9e car il n’a pas pu v\u00e9rifier la plage de versions vuln\u00e9rables (issue.detail: no-version-ranges<\/code>).<\/p>\n\n\n\n
Cette CVE peut \u00eatre ignor\u00e9e pour notre produit<\/strong>, m\u00eame dans ses versions ult\u00e9rieures. Nous pourrions ajouter la ligne suivante dans un fichier .bbappend<\/code> surchargeant la recette du noyau pour cette cible.<\/p>\n\n\n\n
CVE_STATUS[CVE-2023-3640] = \"not-applicable-config: x86-specific and target is qemuarm.\"<\/code><\/pre>\n\n\n\n
La seconde CVE par gravit\u00e9 d\u00e9croissante est d\u00e9crite ainsi :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  cve CVE-2019-14899 --details<\/strong>\ncomponent: linux-yocto\nversion: 7.2.6+git\nlayer: core\ncve: CVE-2019-14899\nstatus: Unpatched\ncvss: 3.x\nscore: 7.4\nseverity: High\nissue.id: CVE-2019-14899\nissue.status: Unpatched\nissue.link: https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2019-14899\nissue.summary: A vulnerability was discovered in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android that allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel.\n  [...]<\/code><\/pre>\n\n\n\n
Cette entr\u00e9e concerne un sc\u00e9nario assez pr\u00e9cis, impliquant un attaquant qui peut injecter des donn\u00e9es dans le flux TCP d’un utilisateur employant un VPN. On ne peut pas l’\u00e9liminer compl\u00e8tement, il faut examiner sp\u00e9cifiquement<\/strong> si elle concerne notre syst\u00e8me.<\/p>\n\n\n\n
Voyons la suivante :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  cve CVE-2021-3864 --details<\/strong>\ncomponent: linux-yocto\nversion: 7.2.6+git\nlayer: core\ncve: CVE-2021-3864\nstatus: Unpatched\ncvss: 3.x\nscore: 7.0\nseverity: High\nissue.id: CVE-2021-3864\nissue.status: Unpatched\nissue.link: https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2021-3864\nissue.summary: A flaw was found in the way the dumpable flag setting was handled when certain SUID binaries executed its descendants. The prerequisite is a SUID binary that sets real UID equal to effective UID, and real GID equal to effective GID. The descendant will then have a dumpable value set to 1. As a result, if the descendant process crashes and core_pattern is set to a relative value, its core dump is stored in the current directory with uid:gid permissions. An unprivileged local user with eligible root SUID binary could use this flaw to place core dumps into root-owned directories, potentially resulting in escalation of privileges.\n  [...]<\/code><\/pre>\n\n\n\n
L’exploitation de cette vuln\u00e9rabilit\u00e9 est assez complexe, car elle implique un fichier ex\u00e9cutable Set-UID<\/code> modifiant ses identifiants R-UID<\/code> et R-GID<\/code> puis lan\u00e7ant un descendant qui d\u00e9clenchera l’\u00e9criture d’un fichier core<\/code>.  Sur un syst\u00e8me embarqu\u00e9 on peut assez facilement lister les ex\u00e9cutables Set-UID<\/code> et les examiner au cas par cas. Une solution avanc\u00e9e par RedHat consiste \u00e0 mettre un chemin d’acc\u00e8s absolu dans le param\u00eatre kernel.core_pattern<\/code> du noyau.<\/p>\n\n\n\n
Nous choisissons de conserver cette CVE<\/strong> et de noter en commentaire de notre .bbappend<\/code> du kernel qu’elle peut  \u00eatre contourn\u00e9e par un sysctl kernel.core_pattern=\/tmp\/core<\/strong><\/code> par exemple.<\/p>\n\n\n\n
Pour la CVE suivante, on s’int\u00e9resse au syst\u00e8me de fichiers JFS.<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  cve CVE-2023-3397 --details<\/strong>\ncomponent: linux-yocto\nversion: 7.2.6+git\nlayer: core\ncve: CVE-2023-3397\nstatus: Unpatched\ncvss: 3.x\nscore: 7.0\nseverity: High\nissue.id: CVE-2023-3397\nissue.status: Unpatched\nissue.link: https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2023-3397\nissue.summary: A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information.\n  [...]<\/code><\/pre>\n\n\n\n
Pour s’assurer que le syst\u00e8me de fichier n’est pas compil\u00e9 dans le kernel, il ne suffit pas de consulter \/proc\/filesystems<\/code> sur la cible, car rien n’emp\u00eache que JFS soit compil\u00e9 sous forme de module du kernel non encore charg\u00e9. Pour v\u00e9rifier plus pr\u00e9cis\u00e9ment, on analysera le fichier de configuration du noyau :<\/p>\n\n\n\n
root@qemuarm:~# zcat \/proc\/config.gz | grep -E 'CONFIG_JFS_FS'<\/strong>\n# CONFIG_JFS_FS is not set<\/code><\/pre>\n\n\n\n
On peut ignorer cette CVE<\/strong> et ajouter donc dans notre fichier .bbappend<\/code><\/p>\n\n\n\n
CVE_STATUS[CVE-2023-3397] = \"not-applicable-config: CONFIG_JFS_FS is disabled in the target kernel\"<\/code><\/pre>\n\n\n\n
Voyons une derni\u00e8re vuln\u00e9rabilit\u00e9 en d\u00e9tail :<\/p>\n\n\n\n
$ .\/yocto-cve-parser\/cve-parse  filtered-cve.json  cve CVE-2023-6238 --details<\/strong>\ncomponent: linux-yocto\nversion: 7.2.6+git\nlayer: core\ncve: CVE-2023-6238\nstatus: Unpatched\ncvss: 3.x\nscore: 6.7\nseverity: Medium\nissue.id: CVE-2023-6238\nissue.status: Unpatched\nissue.link: https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2023-6238\nissue.summary: A buffer overflow vulnerability was found in the NVM Express (NVMe) driver in the Linux kernel. Only privileged user could specify a small meta buffer and let the device perform larger Direct Memory Access (DMA) into the same buffer, overwriting unrelated kernel memory, causing random kernel crashes and memory corruption.\n  [...]<\/code><\/pre>\n\n\n\n
La consultation de la configuration du kernel montre que le support NVME est d\u00e9sactiv\u00e9 (NVMEM n’a rien \u00e0 voir) :<\/p>\n\n\n\n
# zcat \/proc\/config.gz | grep -E 'NVME'<\/strong>\n# NVME Support\n# CONFIG_BLK_DEV_NVME is not set\n# CONFIG_NVME_FC is not set\n# CONFIG_NVME_TCP is not set\n# CONFIG_NVME_TARGET is not set\n# end of NVME Support\nCONFIG_RTC_NVMEM=y\nCONFIG_NVMEM=y\nCONFIG_NVMEM_SYSFS=y\nCONFIG_NVMEM_LAYOUTS=y\n# CONFIG_NVMEM_LAYOUT_SL28_VPD is not set\n# CONFIG_NVMEM_LAYOUT_ONIE_TLV is not set\n# CONFIG_NVMEM_LAYOUT_U_BOOT_ENV is not set\n# CONFIG_NVMEM_RMEM is not set<\/code><\/pre>\n\n\n\n
On peut donc raisonnablement \u00e9liminer cette CVE<\/strong> avec une ligne comme :<\/p>\n\n\n\n
CVE_STATUS[CVE-2023-6238] = \"not-applicable-config: NVMe support is disabled\"<\/code><\/pre>\n\n\n\n
dans un fichier d’amendement de la recette kernel.<\/p>\n\n\n\n
En continuant la liste, nous voyons que nous pouvons conserver et \u00e9tudier<\/strong> la possibilit\u00e9 d’exploitation dans notre environnement propre de certaines vuln\u00e9rabilit\u00e9s :<\/p>\n\n\n\n

Comme exemple de syst\u00e8me dont on souhaite v\u00e9rifier les \u00e9ventuelles vuln\u00e9rabilit\u00e9s, nous allons prendre une image minimale produite avec Yocto Project<\/strong> pour un \u00e9mulateur Qemu Arm<\/strong>. Je commence par installer Yocto Cooker <\/strong>comme indiqu\u00e9 dans cet article<\/strong><\/a> :<\/p>\n\n\n\n