zedeldi/cve-2025-47827PoC 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 :
