Peut-on obtenir les privilèges root avec un briquet ?

 (da.vidbuchanan.co.uk)
2 points par GN⁺ 2024-10-08 | 2 commentaires | Partager sur WhatsApp
  • Une expérience d’élévation locale de privilèges a réussi à provoquer, avec un simple briquet piézoélectrique, une faute électromagnétique sur le bus mémoire DDR3 d’un ordinateur portable, permettant de passer d’un utilisateur Linux non privilégié à un shell root
  • Sur un Samsung S3520, une résistance de 15 Ω et un fil servant d’antenne ont été soudés à une broche de données du SODIMM, puis un clic de briquet à proximité a permis de provoquer une erreur mémoire inversant un bit précis
  • Dans l’expérience CPython, une faute sur la ligne DQ7 inverse le bit 7 d’un pointeur d’objet, de sorte qu’il référence une fausse structure bytearray à l’intérieur d’un bytes, ce qui permet de construire des primitives de lecture/écriture mémoire arbitraires
  • L’élévation de privilèges Linux fonctionne en pulvérisant des tables de pages dans la mémoire physique, puis en provoquant une faute sur le bit 29 lors de la lecture d’une PTE, de façon à ce qu’un mapping accessible en espace utilisateur pointe vers une table de pages
  • Une fois l’accès obtenu, la première page de /usr/bin/su est localisée en mémoire physique puis remplacée par un petit ELF setuid root, ce qui empoisonne le page cache ; dans l’environnement de test, la fiabilité perçue était d’environ 50 % via SSH et d’environ 20 % dans un shell graphique

Point de départ de l’expérience EMFI au briquet

  • Même en l’absence de bug logiciel, on peut provoquer un comportement exceptionnel via de l’injection de faute (fault injection)
    • Parmi les techniques d’injection de faute figurent la corruption de données de contrôle logicielle, les glitches d’alimentation, les glitches d’horloge, les impulsions électromagnétiques et le laser
  • L’injection de faute matérielle exige généralement une grande précision de timing et de position, ce qui implique du matériel spécialisé et coûteux
  • Le point de départ était l’idée de coupler un allumeur piézoélectrique de barbecue à une inductance pour en faire un outil d’injection de faute électromagnétique (EMFI) à très bas budget
    • Cette approche avait déjà permis d’attaquer une implémentation logicielle d’AES sur Arduino via la DFA
  • Avec l’annonce de la Nintendo Switch 2 qui approchait, et l’hypothèse d’un logiciel système proche de celui de la Switch 1 mais avec peu de bugs logiciels exploitables, l’expérimentation EMFI low cost a repris

Système testé et fautes sur le bus DDR

  • Le système testé est un Samsung S3520 fabriqué en 2011, équipé d’un CPU Intel i3-2310M et de 1 Go de RAM DDR3
    • Il peut exécuter Arch, une distribution Linux de bureau légère, et a été choisi parce que sa détérioration éventuelle restait acceptable
  • L’objectif était d’écrire un exploit d’élévation locale de privilèges reposant sur une faute matérielle injectée
  • Le point le plus vulnérable physiquement retenu a été le bus DDR reliant la DRAM au reste du système
    • Le SODIMM comporte 64 broches DQ, de DQ0 à DQ63, qui transportent les bits de données en lecture et en écriture
  • Le montage expérimental consiste à souder une résistance de 15 Ω et un fil sur une broche supposée être DQ26
    • Le fil agit comme une antenne, capte les interférences électromagnétiques ambiantes et les transmet au bus de données
    • La résistance sert à limiter l’intensité de l’interférence pour ne pas perturber en permanence le fonctionnement mémoire normal, bien qu’elle ne soit peut-être pas indispensable en pratique
  • Le simple fait de cliquer un briquet piézoélectrique ordinaire près du fil-antenne suffit à faire apparaître de façon reproductible des erreurs mémoire dans memtest
    • Toutes les erreurs observées correspondaient à une inversion du bit 29
    • La broche soudée était supposée être DQ26, mais si c’est bien le bit 29 qui a été inversé, c’est peut-être parce que le comptage des broches était erroné ou que la carte mère a rerouté les lignes de données
  • Le contrôle du timing de l’injection n’est pas précis, puisqu’il dépend essentiellement de la vitesse de réaction d’un doigt
    • Lorsqu’une faute se produit, elle a néanmoins de fortes chances d’inverser le même bit sur une lecture ou écriture 64 bits donnée

Exploitation d’un bit flip dans CPython

  • La première expérience visait à créer un exploit de type échappement de sandbox dans CPython
    • CPython n’étant pas lui-même une sandbox, il ne s’agit pas d’un véritable franchissement de frontière de sécurité, mais d’une étape préparatoire fondée sur des structures internes familières
  • Dans cette expérience, le fil n’était pas soudé sur DQ26 comme sur la photo précédente, mais sur DQ7
  • Les objets CPython résident sur le tas du garbage collector, et l’en-tête d’objet contient un refcount et un pointeur vers l’objet de type, suivis des champs propres au type
    • Un objet bytes contient, après son champ de longueur, les données elles-mêmes dans la même allocation sur le tas
    • Un objet bytearray contient, après son champ de longueur, un pointeur vers le tampon où les données réelles sont stockées
  • La stratégie centrale consiste à placer une fausse structure bytearray dans les données internes d’un objet bytes
    • Si l’on parvient à faire en sorte que CPython donne une référence vers ce faux objet, alors les champs longueur et pointeur du bytearray choisis par l’attaquant permettent une lecture/écriture mémoire arbitraire
  • Une faute qui inverse le bit 7 revient à ajouter ou soustraire 128 à un pointeur dans un mot 64 bits
    • En plaçant le faux bytearray à un décalage de +128 octets à l’intérieur du bytes, le pointeur du bytes peut, sous l’effet de la faute, devenir un pointeur vers le faux bytearray
    • Cette transformation se fait dans le bon sens avec une probabilité de 50 %
  • Point important : c’est l’opération de lecture/écriture sur le bus mémoire qui est glitchée, et non le contenu mémoire lui-même
    • Contrairement à Rowhammer, on ne modifie pas les données stockées ; on corrompt l’accès en cours sur le bus
  • Pour que l’accès au pointeur ciblé représente la majorité de l’activité sur le bus, la même référence d’objet est répétée dans un grand tuple
    • Comme le cache CPU réduit les accès DRAM, une structure plus grande que le cache de 3 MiB est parcourue séquentiellement afin de forcer une lecture en DRAM à chaque fois
    • En Python, is se comporte comme une comparaison de pointeurs, ce qui permet de vérifier si le pointeur a changé
  • Le code source complet de l’exploit CPython est disponible dans ddr3_dq7.py
    • La variable TESTING permet de simuler en logiciel le bit flip sans matériel

Structures mémoire nécessaires à l’élévation de privilèges Linux

  • Pour l’élévation locale de privilèges sous Linux, les structures clés sont le cache, la mémoire virtuelle, les tables de pages et le TLB
  • La DRAM étant relativement lente, le CPU utilise des caches L1, L2 et L3
    • Sur l’ordinateur portable de test, le cache L3 fait 3 MiB
    • En cas de cache hit, il n’y a pas d’accès DRAM ; une lecture DRAM n’a lieu qu’en cas de cache miss
  • L’unité minimale du point de vue du cache est la ligne de cache, ici de 64 octets
    • Même si l’on lit un seul octet, si la donnée n’est pas déjà en cache, une lecture DRAM de 64 octets est déclenchée
    • Le bus de données DDR fait 64 bits de large, donc cette lecture est traitée sous forme de 8 accès burst séquentiels
  • La mémoire virtuelle x86-64 est implémentée avec des pages de 4 KiB et des tables de pages en arbre
    • Cette plateforme utilise des tables de pages à 4 niveaux
    • Chaque table de pages occupe une page de 4 KiB et contient 512 PTE de 64 bits
    • Les PTE des niveaux supérieurs pointent vers l’adresse physique de la table de pages du niveau suivant, tandis que les PTE de niveau 0 pointent vers la page physique cible
    • L’adresse physique de la table de pages racine est stockée dans le registre CPU CR3
  • Dans une PTE, la partie importante est le champ d’adresse physique
    • Une fois les bits de drapeau masqués, il reste une adresse de mémoire physique alignée sur une page
  • Le TLB est un mécanisme matériel interne au CPU qui met en cache les traductions d’adresses virtuelles en adresses physiques
    • La taille exacte du TLB sur l’ordinateur de test n’est pas connue, mais semble être de l’ordre de 1024 entrées

Faire remonter une table de pages en mémoire utilisateur

  • La stratégie de l’exploit Linux s’inspire en partie de l’exploit Rowhammer de Mark Seaborn
  • L’objectif est de mapper la table de pages du processus lui-même dans une mémoire accessible depuis l’espace utilisateur
    • Cela permet ensuite de modifier des PTE pour accéder à de la mémoire physique arbitraire
  • Plutôt que de contrôler finement la disposition de la mémoire physique, l’approche consiste à remplir exactement 50 % de la mémoire physique avec des tables de pages de niveau 0
  • Ensuite, des mappings R/W sont parcourus en boucle afin de contourner le TLB
    • Comme le nombre de mappings dépasse la taille du TLB, chaque accès force un page walk
    • Le but est de provoquer pendant ce parcours une faute sur le bit 29 lors de la lecture d’une PTE de niveau 0
  • Si le bit 29 est inversé, l’adresse physique pointée par la PTE est décalée de 512 MiB
    • Avec un peu de chance, la nouvelle adresse pointe vers l’une des tables de pages de niveau 0 pulvérisées précédemment
    • Dans ce cas, un mapping censé désigner une page R/W ordinaire expose en réalité une table de pages comme s’il s’agissait d’une page R/W normale
  • En théorie, n’importe quel bit inversé entre le bit 29 et le bit 12 pourrait fonctionner
    • Le bit 12 correspond à un décalage de 4 KiB
    • L’essentiel est que la PTE pointe vers « autre chose », alors qu’environ 50 % de la mémoire physique est occupée par des tables de pages exploitables
  • Il n’est pas certain que le fil-antenne soudé soit indispensable
    • Si l’on pouvait générer une interférence électromagnétique suffisamment forte, cela pourrait peut-être marcher, mais avec un risque bien supérieur de crash ou de détérioration du système

Méthode de pulvérisation des tables de pages de niveau 0

  • On crée d’abord un fichier en mémoire avec memfd_create
    • Il joue le même rôle que le fichier /dev/shm/ dans l’exploit de Mark Seaborn, mais sans toucher directement au système de fichiers
  • Le même tampon est ensuite mappé plusieurs fois avec mmap
    • L’option MAP_FIXED force chaque mapping à être aligné sur 2 MiB dans la mémoire virtuelle
    • Cet alignement garantit la création d’une nouvelle table de pages de niveau 0 à chaque fois
  • Linux limite à environ 2^16 le nombre de mappings par processus, c’est-à-dire le nombre de VMA
    • Chaque mapping fait donc 32 MiB pour qu’un seul mapping crée 16 tables de pages de niveau 0
  • Chaque mapping occupe 32 MiB dans l’espace d’adressage virtuel, mais toutes les PTE pointent vers la même page physique
    • Le coût en mémoire physique se limite donc aux tables de pages de niveau 0
    • Cette technique permet de pulvériser des tables de pages jusqu’à saturation de la mémoire

Lecture/écriture de mémoire physique et empoisonnement du page cache de su

  • En parcourant les mappings R/W en boucle dans l’attente d’une faute, si une valeur inattendue est renvoyée, cela indique qu’une faute a probablement eu lieu
    • Si les données retournées ressemblent à une PTE, cela signifie qu’un accès R/W à une table de pages a été obtenu
  • L’étape suivante consiste à identifier à quelle adresse virtuelle correspond cette table de pages
    • On modifie la PTE pour qu’elle pointe vers l’adresse physique 0
    • Puis on rescane les mappings R/W pour voir lequel a changé
  • Même après modification d’une PTE, la MMU ne s’en aperçoit pas immédiatement
    • En effet, les traductions virtuel-physique restent mises en cache dans le TLB
    • Faute de méthode connue pour flush le TLB directement depuis l’espace utilisateur, des milliers de mappings R/W sont parcourus en boucle afin de remplir le TLB avec de nouvelles valeurs et d’éjecter les anciennes
  • À ce stade, un accès en lecture/écriture à l’ensemble de la mémoire physique devient possible
  • On ouvre ensuite l’exécutable /usr/bin/su en lecture seule et on mappe sa première page avec mmap
    • /usr/bin/su est un exécutable setuid root
    • On scanne l’intégralité de la mémoire physique pour retrouver cette même page
    • Une fois la page physique trouvée, on écrit dessus pour la remplacer par un payload ELF de moins de 4 KiB lançant un shell root
  • La fois suivante où su est exécuté, Linux considère que sa première page est déjà en mémoire et ne la relit pas depuis le disque
    • Il réutilise le page cache empoisonné et exécute l’ELF injecté
    • L’ELF injecté vide ensuite le page cache avec echo 1 > /proc/sys/vm/drop_caches, de sorte que l’exécution suivante de su redevienne normale
  • Le code source complet de l’exploit Linux est disponible dans linux_x86_64_lpe.c

Fiabilité et contraintes d’environnement

  • Dans la démonstration, un glitch favorable s’est produit dès un seul clic de briquet
    • Lors de nombreuses tentatives précédentes, l’ensemble du système avait crashé
  • La fiabilité globale de l’exploit n’a pas été mesurée rigoureusement
    • Avec l’écran du portable éteint et une connexion SSH, elle semble être d’environ 50 %
    • Dans un shell graphique, elle est plutôt proche de 20 %
  • Le système expérimental utilise un circuit graphique intégré
    • Les accès mémoire du GPU peuvent interférer avec l’exploit
  • Des services d’arrière-plan liés à pipewire, sshd et systemd, ainsi que le swap, étaient également actifs
    • C’était un choix visant à conserver un environnement Linux de bureau réaliste ; les désactiver pourrait améliorer la fiabilité
  • Avec davantage de RAM installée, il serait possible de remplir une plus grande fraction de la mémoire avec des tables de pages, ce qui pourrait améliorer la fiabilité globale

Usages possibles et questions ouvertes

  • Si une élévation locale de privilèges EMFI fiable était possible sous Windows, cela pourrait avoir un impact dans des contextes où des anti-triches basés sur le TPM limitent les logiciels autorisés sur le système
  • Une réflexion similaire pourrait s’appliquer aux contrôles SafetyNet ou Play Integrity sur Android, même s’il est plus difficile d’intégrer un modchip de glitch dans un téléphone
  • Dans l’optimisation bas niveau des performances, la connaissance des tables de pages et du TLB n’est pas toujours directement cruciale, mais dans cet exploit, les structures qui maintiennent l’illusion de la mémoire virtuelle deviennent elles-mêmes la cible de l’attaque
  • Il reste encore de nombreuses questions sur le périmètre d’application
    • Est-ce que cela fonctionne aussi sur DDR4 et DDR5 ?
    • Est-ce que cela fonctionne aussi sur ARM ?
    • Dans quelle mesure différents types d’ECC, en particulier le Link-ECC de la DDR5, atténuent-ils le problème ?
    • Quelle serait la manière la plus simple de déclencher électroniquement une faute similaire avec un appareil comme un RP2040 ?
    • Peut-on l’utiliser pour sortir d’un hyperviseur ?
    • Peut-on en faire un exploit WebKit ou un exploit kernel pour Nintendo Switch ?

À lire aussi

2 commentaires

 
mammal 2024-10-08

Ça me fait penser au fait de retirer l’allumeur d’un briquet pour tricher avec les pièces dans les bornes d’arcade.
 
GN⁺ 2024-10-08
Commentaires sur Hacker News

  • L’inspiration ici était d’obtenir les droits root sur la Switch 2, et obtenir root sur Linux n’était qu’une preuve de concept
    Le but se rapproche davantage de la reprise de possession réelle de son propre matériel, sans casser le TPM ni les anti-cheats de jeux au niveau noyau, que de la démonstration d’une vulnérabilité de sécurité fondamentale exploitable en pratique

    • Je comprends l’intention, mais je ne suis pas sûr de bien saisir l’argument principal. Il y a 20 ans, quand les consoles étaient des ordinateurs puissants vendus à perte ou avec de faibles marges, ça avait davantage de sens, mais aujourd’hui Nintendo vend ses consoles avec profit, et la Switch 2 fera probablement de même
      C’est impressionnant, et je salue le travail pour défendre la liberté logicielle, mais je préférerais soutenir des alternatives. Pourquoi leur donner des chiffres d’installation et des bénéfices ? Autant acheter un Steam Deck ou un autre appareil portable où l’accès root est proposé comme fonctionnalité dès le départ

  • L’article est très bien écrit et le défi est remarquable, mais mon cerveau réagit surtout avec l’adage du hacking selon lequel « avec un accès physique, c’est déjà terminé »
    Ma première pensée a été qu’avec un accès physique, on peut reflasher le BIOS, installer une porte dérobée dans un pilote, démarrer sur un OS live et modifier /etc/{passwd,shadow,groups, etc}.
    Mais je me suis rappelé que si le disque est chiffré, la plupart des attaques par accès physique deviennent impossibles, et dans ce cas ce type d’attaque paraît extrêmement séduisant. L’idée de l’antenne pourrait être étendue à du matériel intégrant un dispositif d’interférence, capable de communiquer vers l’extérieur par un médium sans fil, ce qui permettrait à un attaquant de provoquer l’interférence à distance. Avec en plus un site web contrôlé par l’attaquant destiné à inciter la victime à le visiter, le scénario devient crédible

    • La motivation dans l’introduction est de rooter/jailbreaker une console de jeu portable. On a un accès physique, mais on veut quand même obtenir un accès « non autorisé » : comme situation, c’est tout à fait plausible
    • À mon avis, reflasher le BIOS ne rapporterait pas grand-chose. Le matériel CPU vérifie la bonne signature par clé privée avant même le début de l’exécution, donc il faudrait d’abord signer
      Cette technique d’interférence électromagnétique trompe directement le CPU lui-même, donc à moins d’un nouvel algorithme de pagination, je vois mal comment la corriger
    • Dire que « si le disque est chiffré, la plupart des piratages par accès physique deviennent impossibles » n’est vrai que si le PC est éteint et n’a pas encore été démarré avec les données déchiffrées par le fichier de clé ou la phrase de passe
      Mon PC utilise aussi le chiffrement complet du disque, mais une fois démarré, le fichier de clé servant au déchiffrement a été utilisé, et à partir de ce moment-là, le PC est physiquement accessible

  • J’aime bien. L’idée, c’est qu’un bit flip électrostatique se produit pendant une lecture ou écriture mémoire, et qu’avec en plus de la soudure, on peut transformer de manière déterministe un pointeur « sûr » en pointeur malveillant de son choix
    Historiquement, la vision de l’accès physique était : « si l’adversaire met la main sur l’appareil, la partie est finie ». Les TPM et les environnements d’exécution de confiance ont fait évoluer cela vers : « même si l’utilisateur a un accès physique, certaines opérations à l’intérieur de l’enclave restent dignes de confiance ».
    La suite est la plus intéressante. Peut-on obtenir des résultats raisonnablement fiables sans soudure ? Beaucoup de réflexion a déjà été consacrée à la gestion des interférences électriques, donc cela semble bien plus difficile, mais peut-être possible. Si chaque pression sur le briquet retourne un bit aléatoire dans une lecture 64 bits, et que l’exploit fonctionne par exemple avec un seul des 4 bit flips possibles, alors le nombre moyen d’essais pourrait ne pas être si élevé

    • Si l’on a un accès physique au point de pouvoir souder une antenne, on peut brancher « par l’arrière » une DIMM programmable sur mesure et percer le TPM ou n’importe quoi d’autre
      Il suffirait de modifier n’importe quelle partie de la mémoire à la valeur voulue au moment voulu, donc nul besoin de compter sur des bit flips aléatoires. Il suffit d’injecter tout le programme
    • Sans l’antenne, il me semble difficile de limiter le retournement à un seul bit. Du moins, c’est mon intuition

  • En voyant seulement le titre, j’ai cru que c’était un article sur quelqu’un qui avait obtenu les droits root sur un briquet, et j’étais tout à fait prêt à y croire
    Le four de mes parents reçoit régulièrement des mises à jour logicielles, donc je n’ai même pas remis en question l’idée qu’un briquet puisse être « intelligent »

    • En voyant juste le titre, je m’attendais à moitié à une version pyromane de la cryptanalyse au tuyau en caoutchouc
    • Je me dis qu’il pourrait exister un briquet avec un petit panneau solaire et une batterie, qui détecte une cigarette ou un cigare à proximité avec du lidar puis produit une étincelle comme un mini taser. Il ne réagirait ni aux doigts ni aux hot-dogs, n’aurait pas de bouton, et il ne faudrait jamais recharger le gaz du briquet
      Bien sûr, il faudrait aussi une puce pour faire tourner le lidar, ainsi qu’un flash LED intense avec fondu, un choc haptique et des effets sonores. J’aimerais bien que quelqu’un en fasse une démo. Ce serait bien qu’il ressemble à un petit revolver, mais pour la sécurité des doigts et des hot-dogs, il faudrait sans doute renforcer le contrôleur de mémoire virtuelle
    • Le fer à souder que j’utilise le plus souvent exécute lui aussi un firmware modifiable sur un SoC RISC-V. (https://pine64.com/product/pinecil-smart-mini-portable-solde...)
      Qui aurait cru que faire fondre de l’étain pouvait devenir aussi complexe ? Du coup, je pourrais tout à fait croire à un article sur le root d’un briquet
    • J’ai cru qu’il s’agissait de calculer des racines carrées avec la forme des flammes

  • Cela rappelle un exploit utilisé sur des bornes d’arcade à Sydney dans les années 80~90. Dans l’école, les chauffages au gaz avaient un allumeur piézoélectrique qu’on appelait un « clicker », et on pouvait le détacher du chauffage.
    On apportait ce clicker à la salle d’arcade du quartier, on le faisait claquer sur l’un des coins du CRT, et le système recevait un choc qui augmentait les crédits du jeu. J’imagine que c’était parce que la masse du CRT partageait physiquement la même ligne de terre que le mécanisme de validation des pièces.
    Avec le temps, les propriétaires s’en sont rendu compte et ont ajouté une sorte d’alarme, mais avant ça, c’était vraiment le bon vieux temps

    • On faisait exactement la même chose au début des années 80, sauf que nous utilisions le clicker d’un briquet jetable.
      Ça a duré quelques années, puis les propriétaires ont compris et ont commencé à recouvrir les bornes d’arcade de plastique transparent. En même temps, comme les bornes se retrouvaient scellées dans du plastique, ils ont percé des trous à l’arrière pour la ventilation, et on a découvert qu’on pouvait appuyer sur le levier qui enregistre l’insertion d’une pièce avec une tige de bambou.
      Ils ont alors déplacé les aérations vers le haut au lieu de l’arrière pour qu’on ne puisse plus atteindre le levier, mais cette fois on a découvert qu’en poussant une pièce vers le haut par la fente de retour, on pouvait toucher le levier d’enregistrement des pièces, et les parties gratuites ont continué. Finalement, ils ont planté des vis pointues dans le boîtier du retour de monnaie pour nous couper les doigts, et après ça, on a acheté une SEGA. C’était vraiment amusant
    • Ça me rappelle une borne où, si un ami rampait derrière et coupait puis rallumait l’alimentation, on obtenait un jeton gratuit.
      Je ne sais pas si c’était volontairement conçu ainsi pour que le personnel puisse tester gratuitement, mais mon ami se glissait derrière et jouait gratuitement en boucle
    • Ça marchait aussi aux États-Unis. Vers les années 1990, la plupart des salles d’arcade utilisaient des jetons propriétaires au lieu de pièces en argent, et il y avait aussi beaucoup de machines à sous d’adresse où les jetons s’empilaient en glissant en file.
      Sur la version « Jungle Jive », si on donnait un léger choc électrique à la fente métallique avec l’allumeur électrique d’un briquet, des jetons sortaient de l’autre côté de la machine. Si on cliquait trop vite ou trop souvent, elle passait en mode alerte. On pouvait le faire seul, mais la configuration optimale était une équipe de trois : un pour surveiller le personnel, un pour cliquer, un pour récupérer
    • J’ai un vague souvenir qu’en frappant précisément le côté d’un flipper, on pouvait obtenir une partie gratuite. C’était probablement le même principe
    • Je me souviens avoir lu dans ce livre que le hacker Pengo était connu pour ajouter des crédits sur des bornes d’arcade de la même manière.
      https://www.amazon.com/CYBERPUNK-Outlaws-Hackers-Computer-Fr...

  • En tant qu’Australien, on l’interprète autrement. Selon ses talents de négociateur, on peut obtenir le root avec un simple briquet

  • Ce n’est pas seulement un exploit amusant, c’est aussi une excellente mini-introduction qui explique comment le cache fonctionne dans un CPU.
    Je me souviens qu’il y a environ un an, quelqu’un avait posté un article expliquant comment les ordinateurs fonctionnent et sont fabriqués, en partant des plus petites briques, les portes logiques. Quelqu’un se souvient du site ?

  • « Il s’agit simplement d’une résistance de 15 ohms et d’un fil soudé sur DQ26. Le fil agit comme une antenne, capte les interférences électromagnétiques à proximité et les envoie directement sur le bus de données »
    C’est un hack vraiment génial. Fabriquer des interférences électromagnétiques avec un briquet, quand même. Il faudrait que j’essaie d’allumer quelque chose à côté d’un bus DDR pour voir ce qui se passe

  • Bien sûr, si ça n’est possible qu’après avoir soudé une antenne à la mémoire, alors oui :-)
    Cela dit, c’est un excellent article, très minutieux, sur la manière d’exploiter réellement ce genre de glitch. Un briquet peut aussi servir à traîner près de la porte arrière d’un datacenter en attendant qu’un administrateur sorte fumer

    • « En théorie, cela fonctionne si le bit flip se produit à n’importe quelle position entre le bit 29 et le bit 12. Donc, s’il est possible de produire des interférences électromagnétiques suffisamment fortes, souder le fil d’antenne n’est peut-être pas totalement indispensable »
    • L’un des usages de la section « usage pratique », c’est de contourner la protection contre la copie d’une console

  • En voyant le titre, j’ai d’abord cru que ce serait une histoire sur le piratage d’une voiture moderne avec un briquet USB-C