Une modification du noyau de Windows destinée à améliorer la sécurité a finalement permis de provoquer un écran bleu de manière fiable.
Les chercheurs de Check Point ont découvert que des métafichiers EMF/EMF+ malformés pouvaient faire planter des systèmes Windows 11 entièrement corrigés en déclenchant une panique dans un nouveau composant de gestion des régions GDI basé sur Rust.
« Ce problème est probablement dû au fait que les variables de boucle v88 et v95 s’incrémentent au-delà des limites valides sans protections adéquates », ont indiqué les chercheurs de Check Point.
Le risque
Pour les entreprises, le risque concerne davantage une perturbation à grande échelle qu’une exécution de code : un métafichier spécialement conçu, rendu dans le contexte d’un utilisateur, peut provoquer un écran bleu sur les terminaux d’un domaine entier, entraînant des interruptions de service, des pertes de données et des coûts de reprise.
Bien que Microsoft ait classé le problème comme étant de gravité modérée et l’ait corrigé au moyen d’une mise à jour, les travaux de Check Point montrent l’existence d’une preuve de concept (PoC) pratique de déni de service (DoS) à l’échelle de l’entreprise, que les équipes de sécurité doivent considérer comme un risque opérationnel important.
Ce que Check Point a découvert
Le fuzzing des graphiques Windows réalisé par les chercheurs à partir de minuscules fichiers sources EMF/EMF+ a révélé à plusieurs reprises une erreur SYSTEM_SERVICE_EXCEPTION dans win32kbase_rs.sys, l’implémentation Rust des régions GDI.
Le plantage se produit lorsque la conversion d’un chemin en région (par exemple, après EmfPlusDrawBeziers) rencontre un index hors limites, ce que Rust détecte correctement avant de déclencher une panique — laquelle se propage jusqu’à provoquer un arrêt système.
Check Point a vérifié qu’un enregistrement EMF+ malformé rendu par l’intermédiaire de Graphics::FromImage() et de DrawImage() dans une session utilisateur standard pouvait déclencher systématiquement la panique du noyau sur les versions Windows 11 24H2 antérieures au correctif de Microsoft.
Fonctionnement de la vulnérabilité
Dans les versions vulnérables, la création d’une région (region_from_path_mut) parcourait des listes d’arêtes dérivées de chemins élargis ou aplatis.
Certaines entrées de Bézier modifiées et certains attributs de plume produisaient des blocs d’arêtes qui faisaient dépasser l’index de ses limites.
La fonction panic_bounds_check() de Rust l’a détecté, mais la panique qui en a résulté a fait planter le système d’exploitation (OS) au lieu d’échouer proprement en mode noyau.
L’équipe de Check Point a publié une preuve de concept montrant que le plantage pouvait être déclenché depuis un contexte à faible intégrité et sans droits d’administrateur, en affichant un métafichier malveillant.
Il s’agit d’un scénario de déni de service — aucun élément ne démontre une exécution de code à distance —, mais sa complexité est faible et son impact sur la disponibilité élevé. Microsoft a déjà publié un correctif pour ce problème.
Mesures d’atténuation
- Correctif : mettez à jour tous les terminaux Windows 11 24H2 vers la version du système d’exploitation 26100.4202 ou ultérieure et vérifiez que les éventuelles mises à jour préliminaires ignorées sont couvertes par la dernière mise à jour cumulative.
- Bloquer les contenus à risque : bloquez ou supprimez les fichiers EMF/EMF+ dans les outils de messagerie, de navigation web et de collaboration, en les considérant comme des contenus assimilables à des exécutables et en privilégiant des formats plus sûrs comme PNG ou JPEG.
- Sécuriser les chemins de rendu : n’ouvrez les pièces jointes non fiables que dans le mode protégé ou dans des visionneuses en bac à sable, et désactivez si possible les aperçus automatiques des métafichiers dans les clients de messagerie.
- Détecter et réagir: surveillez les erreurs BugCheck 0x3B liées à l’activité de métafichiers et recherchez les pics inhabituels de télémétrie des plantages win32k sur plusieurs systèmes.
- Former les utilisateurs : sensibilisez les utilisateurs à la prudence face aux pièces jointes et aux contenus partagés inattendus contenant des fichiers image ou graphiques.
Lorsque des chemins de panique du noyau peuvent être déclenchés par des données contrôlées par l’utilisateur, ils deviennent de fait des vecteurs fiables de déni de service (DoS).
Avant d’activer de nouvelles fonctionnalités à grande échelle, les entreprises doivent associer les réécritures utilisant la sûreté mémoire à une gestion robuste des erreurs et à des tests de fuzzing approfondis — en particulier pour les analyseurs graphiques.
N’oubliez pas que la disponibilité est un élément fondamental de la sécurité : même des plantages « sûrs » peuvent provoquer de véritables interruptions de service si des attaquants peuvent les déclencher à répétition.
Appliquez rapidement les correctifs, réduisez les surfaces d’exposition aux fichiers à risque et concevez une infrastructure résiliente face aux cyberattaques.
Pour réellement limiter l’impact des vulnérabilités, les entreprises doivent aller au-delà de l’application des correctifs et adopter une approche zero-trust.