Piratage de la Xbox : leçons sur la sécurité matérielle

Microsoft a conçu l'architecture de sécurité de la Xbox One pour être impénétrable. Une racine de confiance matérielle. Un hyperviseur sur mesure. Un stockage chiffré avec des clés propres à chaque console. Une chaîne de démarrage signée, où chaque étape vérifie la suivante. Ce n'était pas de la sécurité de façade : il s'agissait d'une défense multicouche réellement sophistiquée, conçue par l'une des meilleures équipes d'ingénierie de sécurité du secteur. Ils l'ont qualifiée d'inviolable.

Elle vient pourtant d'être piratée. Un groupe se faisant appeler « Bliss » a obtenu une exécution de code complète sur la Xbox One, en contournant l'hyperviseur, la vérification de la chaîne de démarrage et le processeur de sécurité matériel. Les détails de l'exploit sont fascinants, mais ce qui l'est encore plus, c'est ce qu'il révèle des limites fondamentales de la sécurité matérielle, et pourquoi le mot « inviolable » est toujours dangereux.

L'architecture de sécurité de la Xbox

Pour comprendre pourquoi ce piratage est important, il faut savoir ce qu'il a mis à mal. Le modèle de sécurité de la Xbox One est l'une des implémentations de sécurité matérielle grand public les plus complètes jamais livrées.

Le démarrage commence par une racine de confiance matérielle : du code gravé dans le SoC, impossible à modifier. Ce code vérifie et charge le bootloader de l'étape suivante, qui vérifie et charge l'hyperviseur, lequel vérifie et charge à son tour le système d'exploitation. Chaque étape est signée avec les clés de Microsoft. Si une vérification échoue, la console ne démarre pas. C'est une chaîne de démarrage sécurisé classique, comparable à ce qu'offrent ARM TrustZone et Boot Guard d'Intel.

L'hyperviseur, un logiciel sur mesure s'exécutant à un niveau de privilège supérieur à celui du système d'exploitation, impose l'isolation de la mémoire, contrôle l'accès au matériel et empêche le système de modifier l'état critique du système. Les jeux et applications tournent dans des machines virtuelles qui ne peuvent ni voir ni modifier la mémoire des autres. Même si vous trouvez une faille noyau dans le système de la Xbox, vous restez enfermé dans le bac à sable de l'hyperviseur.

En plus de cela, le stockage de la console est chiffré avec des clés dérivées du processeur de sécurité matériel. Impossible de retirer le disque, de le lire sur une autre machine et d'en extraire quoi que ce soit d'utile. Les clés de chiffrement sont liées au matériel spécifique : c'est le principe du scellement propre à l'appareil, également utilisé dans les TPM et l'Secure Enclave d'Apple.

Là où l'armure a craqué

Tout système de sécurité repose sur des hypothèses. Celles de la Xbox étaient raisonnables : la racine de confiance matérielle est immuable, la chaîne de démarrage est incassable parce que la cryptographie est solide, l'hyperviseur ne contient pas de bug exploitable parce que c'est une base de code petite et auditée. Chaque hypothèse se défend prise isolément. Le problème, c'est qu'une chaîne de sécurité cède toujours sur son maillon le plus faible, et que trouver ce maillon demande de la créativité, pas seulement de la force brute.

L'exploit Bliss n'a attaqué ni la cryptographie (AES et RSA vont très bien), ni le ROM de la racine de confiance (il est minuscule et bien audité), et n'a forcé aucune clé. Il a exploité l'interface entre les domaines de sécurité, ce canal étroit par lequel les mondes de confiance et non fiable communiquent.

Les modèles de sécurité matérielle sont les plus solides lorsque la surface d'attaque entre les niveaux de confiance est minimale. Mais « minimale » ne veut pas dire « nulle ». L'hyperviseur doit exposer une interface au système invité : appels système pour la gestion de la mémoire, accès aux périphériques, communication entre machines virtuelles. Chacune de ces interfaces est un vecteur d'attaque potentiel. L'équipe Bliss a trouvé une séquence d'appels à l'hyperviseur qui, invoqués avec des paramètres précis dans un ordre précis, ont corrompu l'état interne de l'hyperviseur au point de rediriger l'exécution du code.

Le schéma plus large

Le piratage de la Xbox suit un schéma qui se répète dans toute la sécurité matérielle : la conception initiale est saine, l'implémentation est soignée, mais l'interface entre les domaines de sécurité contient des bugs subtils qui n'apparaissent que sous une utilisation malveillante.

• Le piratage de la PS3 (2010) a exploité une erreur d'implémentation catastrophique dans la génération de signatures ECDSA de Sony : un nombre aléatoire fixe était utilisé au lieu d'un nombre frais pour chaque signature, ce qui divulguait la clé privée. Les mathématiques étaient correctes. L'implémentation, non.
• Le piratage de la Nintendo Switch (2018) a exploité un bug dans le ROM de démarrage du Tegra de NVIDIA : le mode de récupération USB acceptait des charges utiles provoquant un dépassement de tampon, ce qui donnait une exécution de code avant même que la moindre vérification logicielle ne s'exécute. La chaîne de démarrage était bien conçue. Le mode de récupération ne faisait tout simplement pas partie du modèle de menaces.
• Les attaques contre Intel SGX ont montré à plusieurs reprises que les canaux auxiliaires (Spectre, Meltdown et leurs nombreuses variantes) peuvent faire fuiter des données depuis les enclaves sécurisées, alors même que le modèle d'isolation est architecturalement correct. La logique est saine. La microarchitecture, elle, divulgue des informations.

Le constat : les concepteurs raisonnent sur le modèle de sécurité à un certain niveau d'abstraction (protocoles cryptographiques, frontières d'isolation, hiérarchies de confiance), tandis que les attaquants opèrent à un autre niveau (particularités d'implémentation, effets secondaires microarchitecturaux, cas limites d'interface). Le modèle est correct. L'implémentation présente des failles que le modèle n'avait pas prévues.

Pourquoi « inviolable » est toujours faux

Qualifier quelque chose d'inviolable est un signal d'alarme, pas un gage de confiance. Cela signifie que les concepteurs pensent avoir recensé toutes les attaques possibles et s'être défendus contre chacune. Mais l'histoire de la sécurité est celle de catégories d'attaques qui n'existaient pas au moment où la défense a été conçue.

Quand la Xbox One est sortie en 2013, Spectre et Meltdown n'avaient pas encore été découverts. Rowhammer était théorique. Les attaques par glitch de tension sur les SoC modernes étaient mal comprises. Les concepteurs ne pouvaient pas se défendre contre des attaques qui n'avaient pas encore été inventées. Et certaines de celles qu'ils avaient anticipées étaient peut-être peu réalistes à l'époque, mais sont devenues faisables à mesure que les outils et les techniques se sont améliorés.

Une bonne ingénierie de sécurité ne prétend pas à l'imperméabilité. Elle admet que des failles surviendront et conçoit pour la détection, le confinement et la reprise. La différence entre une pensée sécuritaire mature et immature tient à la question posée : « comment rendre ceci incassable ? » ou « que se passe-t-il quand ceci casse ? ».

Implications pour les développeurs

La plupart des développeurs ne conçoivent pas d'architectures de sécurité pour consoles, mais les leçons s'appliquent largement.

Les interfaces entre frontières de confiance sont le code le plus risqué. La frontière entre votre backend et l'internet public, entre votre application et les plugins tiers, entre votre base de données et les requêtes fournies par les utilisateurs. C'est là que vivent les bugs qui comptent. Une injection SQL n'est pas un bug du SQL ni de votre base de données : c'est un bug à l'interface entre le domaine de confiance (votre logique de requête) et le domaine non fiable (les saisies utilisateur). Concentrez votre effort de sécurité sur ces frontières.

La défense en profondeur n'est pas optionnelle. La Xbox avait plusieurs couches : racine de confiance matérielle, démarrage sécurisé, isolation par hyperviseur, chiffrement du stockage. Briser une couche ne suffisait pas. Les attaquants ont dû enchaîner plusieurs exploits pour obtenir le contrôle total. Si le système n'avait reposé que sur une seule frontière de sécurité, le premier exploit aurait été la fin de partie.

Votre modèle de menaces sera faux. Pas parce qu'il est mal construit, mais parce que le paysage des menaces évolue. L'histoire de l'escalade de privilèges regorge d'attaques jugées inconcevables au moment où les défenses ont été conçues. Concevez des systèmes capables d'être mis à jour, corrigés et durcis sans être repensés. Partez du principe que l'attaque « impossible » d'aujourd'hui sera la CVE de demain.

Le paradoxe de la sécurité ouverte

La sécurité des consoles repose sur le secret : matériel propriétaire, hyperviseurs à code fermé, firmwares chiffrés. C'est de la sécurité par l'obscurité, que la communauté sécurité considère généralement comme une approche faible. Mais l'alternative, du matériel de sécurité open source, a ses propres problèmes : les attaquants peuvent étudier l'implémentation exacte et chercher des vulnérabilités à loisir.

La réponse pratique, c'est que les deux approches finissent par échouer. Les systèmes fermés sont rétro-ingéniés (le piratage de la Xbox en est la preuve). Les systèmes ouverts sont étudiés et attaqués (le flot constant de CVE du noyau Linux en est la preuve). La différence, c'est que les systèmes ouverts se corrigent plus vite, car la défense a la même visibilité que l'attaque. La faille de la Xbox, quels que soient ses détails exacts, sera plus difficile à corriger, parce que le modèle de sécurité est gravé dans du matériel qui ne peut pas être modifié sur le terrain.

Pour les systèmes logiciels, où les mises à jour sont possibles, cela plaide fortement en faveur d'implémentations de sécurité ouvertes et bien auditées plutôt que propriétaires. Non pas parce que les systèmes ouverts sont plus difficiles à attaquer, mais parce qu'ils sont plus faciles à réparer quand l'attaque inévitable réussit.

La suite

Le piratage de la Xbox ne mettra pas fin à la sécurité des consoles. Microsoft étudiera l'exploit, corrigera ce qui peut l'être logiciellement et concevra le matériel de la prochaine génération pour fermer cette classe de vulnérabilités. Les attaquants trouveront autre chose. C'est le cycle : défense et attaque coévoluent, la sécurité de chaque génération intégrant les leçons des échecs de la précédente.

Le message utile n'est pas que la sécurité matérielle est vaine. Elle est un spectre, pas un interrupteur. La sécurité de la Xbox a rendu le piratage nettement plus difficile : il a fallu plus de dix ans. C'est un succès considérable, même si ce n'est pas la perfection. L'objectif n'est pas un système inviolable, mais un système où le coût de l'attaque dépasse la valeur de la cible pendant toute la durée où il doit être protégé. Selon cette mesure, la sécurité de la Xbox One était remarquablement efficace. Elle n'était simplement pas infinie.