Microsoft a principalement réparé une faille dans le matériel Surface qui permettait de bloquer des appareils non protégés par un seul paquet.

EXCLUSIF Au cours des 90 derniers jours, Microsoft a discrètement corrigé une faille du micrologiciel dans les appareils Surface qui permettait de relier le matériel avec un seul paquet, mais uniquement pour ceux qui ont désactivé Secure Core et Secure Boot.

Et le logiciel Copilot AI de la société a aidé par inadvertance à identifier le micrologiciel défectueux.

Selon Jack Darcy, un chercheur en sécurité basé en Australie, son instance de Microsoft Copilot est tombée sur le bug après avoir été invité à régler le rétroéclairage de l’écran d’un appareil Surface. Le script Python créé par Copilot a fini par rendre l’ordinateur portable du chercheur inutilisable en écrasant le micrologiciel du contrôleur intégré.

« Copilot a créé et exécuté de manière autonome quatre scripts Python progressivement agressifs lors d’une sonde pour les valeurs de contrôle du rétroéclairage qui envoyaient des commandes ioctl SSAM brutes (SSAM_CDEV_REQUEST = 0xC028A501) directement au microcontrôleur SAM via le chemin logiciel SAM », a expliqué Darcy à Le registre.

Le SAM ou SSAM est le contrôleur intégré utilisé dans les appareils Surface. Et comme notre source l’a expliqué, l’implémentation du contrôleur par Microsoft dans les appareils Surface n’incluait aucune défense contre les valeurs d’écriture arbitraires.

Microsoft ne considère pas le bug comme une menace pratique. « Il n’y a pas de scénario d’attaque réaliste concernant ce problème », a déclaré un porte-parole. Le registre. « Pour réussir à l’exploiter, un attaquant devrait interagir avec des pilotes spécifiques et envoyer des commandes à une interface matérielle. Cela nécessiterait des privilèges d’administrateur sur la machine, ainsi que la désactivation de la fonction de démarrage sécurisé. Avec cet accès, il pourrait effectuer un certain nombre d’actions. »

Généralement, a déclaré Darcy, les appareils numériques nécessitent de maintenir un bouton enfoncé ou de connecter un câble de démarrage pour permettre un accès en écriture arbitraire. Mais ce contrôle de sécurité est absent des appareils Surface, nous dit-on, ce qui permet à Copilot de vandaliser le micrologiciel en l’absence de Secure Core et de Secure Boot. Essentiellement, la sonde a déclenché une commande de mise à jour du SAM qui a écrasé le micrologiciel UEFI et Secure Boot.

Les appareils Surface soumis à ce type de sondage devraient continuer à fonctionner car le SAM a déjà été initialisé et s’exécute dans la RAM. Mais au redémarrage, lorsque le SAM tente de recharger en utilisant des données corrompues dans son stockage non volatile, il ne parviendra pas à s’initialiser et le système ne pourra pas effectuer l’auto-test de mise sous tension (POST).

Le script Python conçu par Copilot sur l’appareil Surface du chercheur en sécurité a itéré aveuglément sur une catégorie cible particulière et l’ensemble des paires d’ID de commande (CID), envoyant des charges utiles vides/nulles aux commandes WRITE.

Le résultat, a expliqué Darcy, est que le rapport de fonctionnalités SET a été appelé avec une charge utile nulle, le rapport de sortie a été appelé avec une charge utile nulle et d’autres CID ont été touchés par des commandes SET qui ont écrit des données inutiles.

En conséquence, l’appareil est devenu inutilisable. On nous a dit qu’il s’agissait d’une plainte courante sur les forums d’assistance en ligne des appareils Surface au fil des ans, bien que nous n’ayons aucun moyen de déterminer si les échecs de démarrage signalés pour d’autres appareils Surface peuvent être attribués à ce problème spécifique.

De nombreux problèmes matériels Surface signalés publiquement semblent pouvoir être résolus grâce à diverses techniques de dépannage. Mais les appareils rendus inutilisables par l’accès SAM, insiste notre source, sont définitivement bloqués – une situation qui peut entraîner des centaines de dollars en réparations pour une nouvelle carte mère. Pas d’USB, pas de réinitialisation d’usine, pas d’accès au BIOS/UEFI, nous dit-on.

Darcy a dit que le bus SAM est terriblement conçu.

« Il n’y a aucun moyen de voir la valeur actuelle sans scanner le bus », a-t-il déclaré. « Mais scanner le bus tue l’unité. »

Le problème est que les CID, qui sont comme des API pour le SAM, ont été entrelacés de manière dangereuse.

« Si toutes les lectures étaient regroupées (par exemple, les CID 0x01 à 0x0F) et toutes les écritures étaient regroupées séparément (par exemple, les CID 0x10 à 0x1F), un script de sonde pourrait analyser en toute sécurité la plage de lecture sans jamais s’aventurer accidentellement dans le territoire d’écriture », a déclaré Darcy. « Vous pouvez même mettre une simple vérification des limites dans votre code : « sondez uniquement en dessous de 0x10 ». Terminé. Coffre-fort.

« Mais comme les lectures et les écritures sont entrelacées dans le même espace de numérotation, il n’y a pas de plage sûre à sonder. Vous ne pouvez littéralement pas analyser même deux CID consécutifs sans avoir la possibilité d’exécuter une commande d’écriture. Au moment où vous décidez d’énumérer ce qui est disponible, vous lancez déjà des écritures aveugles, car l’espace de commande ne vous donne aucune information structurelle sur les opérations qui sont sûres et celles qui sont destructrices. « 

Les appareils gérés ne courent aucun risque

Le registre a interrogé Microsoft sur les affirmations de notre source le 10 mars 2026. Un porte-parole de l’entreprise a réitéré une suggestion antérieure selon laquelle le chercheur contacterait le Microsoft Security Response Center (MSRC), un effort que notre source a trouvé trop fastidieux. Plutôt que de publier des détails sur ce qui aurait pu être une faille potentielle du jour zéro – nous n’étions pas sûrs à l’époque des exigences Secure Boot/Secure Core – Le registre contacté des sources internes de Microsoft dans le but d’attirer l’attention de quelqu’un.

Le 12 mars, avec l’aide des relations avec les médias de Microsoft, nous avons réussi à coordonner une conversation entre Darcy et Madeline Eckert, responsable principale du programme chez MSRC. Microsoft a par la suite reconnu la vulnérabilité et s’est engagé à publier un correctif. Le registre à son tour, il a accepté de retarder la publication de 90 jours le temps que les réparations soient effectuées. On nous dit que la plupart des appareils concernés ont été mis à jour (via Windows Update) ou recevront des mises à jour dans les semaines à venir. Le problème ne répondait pas aux critères d’un CVE, selon la société.

« Nous apprécions le travail de Jack Darcy et Le registre pour avoir signalé ce problème dans le cadre d’une divulgation coordonnée de vulnérabilité », a déclaré un porte-parole de Microsoft dans un communiqué. « Notre enquête a révélé qu’une interface UEFI obsolète pouvait déclencher une boucle de démarrage sur certains appareils. Pour déclencher cette boucle, l’utilisateur doit disposer des privilèges d’administrateur et avoir déjà désactivé la fonction de sécurité Secure Boot. Nous avons publié des mises à jour pour résoudre le problème sur les appareils les plus concernés. »

Cela signifie que les appareils gérés ne courent aucun risque.

Mais ceux qui utilisent Linux ou les utilisateurs Windows qui ont désactivé Secure Core et Secure Boot pour les jeux, ou qui utilisent des pilotes Windows personnalisés, ou qui ont activé le démarrage USB, peuvent toujours être vulnérables si leurs systèmes n’ont pas reçu la mise à jour.

Nous ne sommes pas certains de la gamme d’appareils Surface concernés. Notre source a déclaré qu’il semble que ce soit tous (Surface Laptops 3-6, Surface Book 1-3), à l’exception des modèles Surface Go. Les variantes ARM n’ont cependant pas été testées.

Microsoft déplace Surface vers Rust

L’une des choses que nous avons apprises de Darcy au cours de nos efforts pour corriger ce problème est que Microsoft envisage de déplacer la pile Surface vers Rust. Nous comprenons de David Abzarian, architecte en chef de Microsoft Surface, que des travaux sont en cours pour faire passer le futur matériel Surface for Business vers une architecture plus sécurisée basée sur le code Rust.

« Notre matériel Surface for Business le plus récent présente un changement architectural majeur en termes de fiabilité et de sécurité améliorées qui s’étend à notre contrôleur intégré, l’UEFI, mais également à certains de nos pilotes », a déclaré Abzarian dans un communiqué fourni à Le Registre. « Nous investissons dans la base la plus sécurisée pour un PC en créant notre micrologiciel de contrôleur intégré à partir de zéro dans Rust (dans le cadre de l’exploitation et de la contribution à l’Open Device Partnership (ODP)) en plus d’une réécriture du noyau UEFI DXE dans Rust ; ces projets sont respectivement connus sous le nom de Secure EC et Project Patina.

« Nous livrons non seulement certains de nos pilotes écrits en Rust, mais nous aidons également à co-développer le cadre Windows Drivers in Rust (WDR) pour permettre à un large éventail de partenaires de l’écosystème Windows de capitaliser sur ces avantages. Je noterai également que tous ces efforts sont open source et promeuvent l’un de nos principes de sécurité clés en matière de transparence.

Invité à commenter, Darcy a déclaré : « Le fait qu’un appareil puisse être détruit de manière irréparable depuis l’espace utilisateur est… certainement une décision de conception intéressante. Même si j’applaudis Microsoft pour sa belle et innovante série Surface, un peu plus d’innovation en matière de vérification des données entrantes au niveau du micrologiciel aurait été grandement appréciée.

On nous dit que Microsoft a fourni à Darcy un ordinateur portable Surface en guise de remerciement. ®