En bref

  • Une vulnérabilité UEFI permet des attaques DMA pré-boot sur les cartes mères ASRock, ASUS, Gigabyte et MSI.
  • CVE-2025-11901, CVE-2025-14302, CVE-2025-14303 et CVE-2025-14304 affectent la protection DMA au démarrage.
  • Action requise : appliquer les mises à jour firmware des constructeurs et restreindre l'accès physique aux machines critiques.

Les faits

Points clés à retenir

  • Les faits
  • Impact et exposition
  • Recommandations

Des chercheurs en sécurité de Riot Games, Nick Peterson et Mohamed Al-Sharifi, ont mis au jour une vulnérabilité UEFI cartes mères qui touche simultanément quatre fabricants majeurs : ASRock, ASUS, Gigabyte et MSI. Divulguée de manière responsable puis rendue publique début avril 2026, cette faille repose sur une incohérence dans le statut de protection DMA (Direct Memory Access) durant la phase de démarrage. Concrètement, le micrologiciel annonce une protection active alors que les accès mémoire directs restent possibles, ouvrant une fenêtre d'attaque avant même le chargement du système d'exploitation. Un attaquant disposant d'un accès physique — ou d'un périphérique Thunderbolt/PCIe malveillant — peut ainsi lire et modifier la mémoire, contourner Secure Boot et implanter un code persistant, invisible pour les antivirus et les solutions EDR. Des millions de machines grand public et professionnelles sont potentiellement exposées, en attente de correctifs constructeurs.

Quatre identifiants CVE ont été attribués : CVE-2025-11901, CVE-2025-14302, CVE-2025-14303 et CVE-2025-14304, couvrant respectivement chaque fabricant affecté. Selon SecurityWeek et BleepingComputer, un attaquant disposant d'un accès physique peut connecter un périphérique PCI Express malveillant pour accéder à la mémoire système ou injecter du code avant le chargement du système d'exploitation, contournant ainsi les mécanismes de sécurité logiciels traditionnels.

Impact et exposition

L'exploitation nécessite un accès physique au port PCIe de la machine cible, ce qui limite le risque pour les postes de travail classiques en environnement contrôlé. Cependant, les scénarios suivants sont particulièrement exposés : serveurs en colocation ou datacenters partagés, postes en libre-service (kiosques, bornes), machines de développement dans des espaces ouverts, et tout environnement où le matériel peut être manipulé par un tiers. L'attaque permet l'injection de code pré-boot, ce qui rend inefficaces toutes les protections logicielles — antivirus, EDR, chiffrement disque — qui ne sont activées qu'après le démarrage de l'OS. Un attaquant peut ainsi installer un bootkit persistant indétectable par les outils de sécurité conventionnels.

Recommandations

  • Appliquer immédiatement les mises à jour firmware publiées par ASRock, ASUS, Gigabyte et MSI pour les cartes mères affectées.
  • Activer Secure Boot et vérifier que la configuration UEFI n'a pas été altérée sur les machines critiques.
  • Restreindre l'accès physique aux serveurs et postes sensibles : verrouillage des châssis, surveillance des salles serveurs, contrôle d'accès strict.
  • Intégrer la vérification de l'intégrité firmware dans vos procédures d'audit de sécurité régulières.

Quelles cartes mères sont concernées et comment vérifier si je suis affecté ?

Les quatre fabricants concernés sont ASRock, ASUS, Gigabyte et MSI. Consultez les bulletins de sécurité de chaque constructeur pour la liste exacte des modèles affectés. En attendant, vérifiez la version de votre firmware UEFI dans les paramètres BIOS et comparez-la avec la dernière version disponible sur le site du fabricant. Si votre firmware est antérieur au correctif, planifiez une mise à jour prioritaire.

Le Secure Boot protège-t-il contre cette attaque DMA pré-boot ?

Le Secure Boot seul ne suffit pas. Cette vulnérabilité agit au niveau de la protection DMA avant même que Secure Boot n'intervienne pleinement. Secure Boot vérifie l'intégrité des composants logiciels au démarrage, mais l'attaque DMA permet d'accéder directement à la mémoire physique via le bus PCIe. La combinaison du correctif firmware, de Secure Boot activé et de la restriction d'accès physique constitue la meilleure défense.

Voici le HTML d'enrichissement demandé :
  • Auditer l'inventaire matériel pour identifier les modèles de cartes mères ASRock, ASUS, Gigabyte et MSI déployés en environnement sensible (salles serveurs, colocation, postes libre-service).
  • Désactiver les ports PCIe/Thunderbolt non utilisés dans le BIOS/UEFI lorsque l'usage métier le permet, en particulier sur les machines exposées physiquement.
  • Renforcer le contrôle d'accès physique : armoires verrouillées pour les serveurs, badges nominatifs, vidéosurveillance des salles techniques.
  • Mettre en place un mot de passe BIOS/UEFI robuste pour empêcher toute modification non autorisée des paramètres DMA et de démarrage.
  • Prioriser les correctifs firmware sur les machines critiques (contrôleurs de domaine, hyperviseurs, postes RSSI) avant un déploiement générique.
  • Cette découverte s'inscrit dans une lignée de recherches sur les faiblesses structurelles du démarrage pré-OS, déjà documentées avec Thunderclap (2019) et Thunderspy (2020), qui exploitaient des angles morts similaires dans la gestion DMA des ports Thunderbolt. Ce qui distingue le cas ASRock/ASUS/Gigabyte/MSI, c'est l'ampleur du parc concerné : ces quatre fabricants couvrent une part dominante du marché des cartes mères grand public et professionnel, ce qui multiplie mécaniquement la surface d'exposition par rapport à des failles ciblant un seul constructeur. Les chercheurs de Riot Games soulignent que la faille touche directement la confiance accordée par les administrateurs système à l'indicateur d'état DMA remonté par le firmware — un indicateur jusqu'ici considéré comme fiable pour arbitrer les politiques de sécurité matérielle en entreprise.

    Quelles cartes mères sont concernées et comment vérifier si je suis affecté ?

    Les CVE couvrent des gammes de cartes mères commercialisées sur plusieurs générations de chipsets, principalement autour des plateformes Intel et AMD récentes. Pour vérifier l'exposition d'un parc, l'approche recommandée consiste à croiser la référence exacte de la carte mère et la version du firmware UEFI installée avec les avis de sécurité publiés par chaque fabricant (ASRock, ASUS, Gigabyte, MSI ont chacun émis un bulletin dédié référençant les CVE concernées). Les outils de gestion de parc (SCCM, Intune, ou équivalents open source comme Fleet) permettant de remonter automatiquement modèle et version BIOS facilitent cet inventaire à grande échelle, évitant une vérification manuelle machine par machine.

    Le Secure Boot protège-t-il contre cette attaque DMA pré-boot ?

    Non : le Secure Boot vérifie la signature cryptographique des composants logiciels chargés au démarrage (bootloader, noyau), mais il n'intervient pas sur le contrôle des accès mémoire via DMA. Un périphérique PCIe malveillant exploitant cette faille contourne la chaîne de confiance du Secure Boot en accédant directement à la mémoire physique, sans jamais passer par le processus de vérification de signature. C'est précisément ce qui rend cette classe de vulnérabilités dangereuse : elle opère à un niveau matériel en dessous des protections logicielles de démarrage sécurisé, y compris lorsque celui-ci est correctement configuré et actif.

    Votre infrastructure est-elle exposée ?

    L'évaluation du risque réel dépend moins du modèle de carte mère que du contexte physique d'exploitation. Un datacenter avec contrôle d'accès strict, un poste de travail dans un bureau fermé ou un serveur en rack verrouillé réduisent fortement la probabilité d'exploitation, malgré la présence du firmware vulnérable. À l'inverse, tout équipement partagé, itinérant ou installé en zone publique (bornes, salles de réunion en libre accès, matériel de démonstration) mérite une revue prioritaire, y compris via un audit de sécurité physique complémentaire à la mise à jour firmware.

    Votre infrastructure est-elle exposée ?

    Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

    Demander un audit

    Sources et références