1 points par GN⁺ 2024-08-08 | 1 commentaires | Partager sur WhatsApp
  • Le buffer overflow strcpy dans le traitement du gap name des sauvegardes Create-A-Park a mené à des exploits via fichiers de sauvegarde et réseau sur plusieurs plateformes, dont la Xbox originale, la Xbox 360, la PS2 et la GameCube
  • Sur la version Xbox originale de THPS4, une chaîne limitée à 31 caractères était copiée sans vérification de limites dans un buffer de pile de 32 octets, ce qui permettait d’écraser la return address ; le shellcode était ensuite exécuté en s’appuyant sur l’en-tête de la sauvegarde et un segment de données exécutable
  • Dans THPS3, la même entrée corrompait le tas plutôt que la pile, ce qui imposait une chaîne ROP passant par un allocator personnalisé et une vtable ; sur les versions Xbox de THUG 1 et 2, le stack cookie bloquait le chemin du gap name
  • En multijoueur sur THPS4, un hôte malveillant pouvait envoyer un fichier park aux clients pour obtenir une exécution de code à distance et effectuer des transferts de fichiers asynchrones ; une fuite mémoire réseau révélée pendant le transfert était contournée dans l’exploit via un hot patch
  • Sur Xbox 360, Tony Hawk’s American Wasteland permet aussi une exécution ROP via le débordement du gap name, mais l’exécution complète de code hyperviseur n’est possible qu’en la combinant avec un bug du system call handler du kernel 4548 ; les sources et les fichiers de sauvegarde patchés sont publiés sur GitHub

Point de départ : gap name et strcpy

  • En 2016, alors qu’une recherche visait un nouveau bug de hack via sauvegarde sur Xbox originale, les sauvegardes de custom park de Tony Hawk’s Pro Skater 4 sont devenues la cible de l’analyse
  • La fonctionnalité Create-A-Park de THPS4 permet aux joueurs de créer eux-mêmes un skate park et de donner un nom aux gaps, c’est-à-dire aux sections de saut
    • le gap name est une chaîne définie par l’utilisateur, composée d’au maximum 31 caractères plus un terminateur nul
    • si cette chaîne est traitée par une fonction comme strcpy, elle peut devenir un primitive de corruption mémoire
  • Après avoir remplacé le gap name par une longue chaîne malveillante répétant 0x41, puis copié et chargé la sauvegarde sur une Xbox, la console a crashé et l’instruction pointer a été fixé à 0x41414141
    • c’était le signe que le gap name avait été copié sur la pile et avait écrasé jusqu’à la return address
  • L’analyse dans IDA a montré qu’en parcourant la liste des gaps de la sauvegarde, le jeu copiait le gap_name de save_file_gap_data vers le gap_description gapDesc situé sur la pile via strcpy
    • sans vérification de limites, la copie continuait jusqu’à rencontrer le terminateur nul
    • cette version du jeu avait été compilée sans stack cookie, ce qui permettait d’écraser les données de pile et la return address

THPS4 sur Xbox originale : déplacer le shellcode vers une zone exécutable

  • La Xbox originale ne disposait pas de DEP matériel empêchant l’exécution de données arbitraires comme sur les appareils récents, mais les kernels tardifs et les jeux embarquaient une certaine forme de soft DEP
    • cela fonctionnait en modifiant l’adresse du sélecteur de segment de code afin de n’autoriser l’exécution qu’en dessous d’une certaine adresse
    • la pile et les allocations de tas contenant la sauvegarde se trouvaient hors de la zone exécutable
  • Le segment de données en lecture-écriture de l’exécutable du jeu se trouvait, lui, dans la zone exécutable ; la stratégie consistait donc à y copier le code avant de l’exécuter
  • Le nom du park se trouve dans l’en-tête de la sauvegarde, et lorsque le joueur sélectionne la sauvegarde, les 136 premiers octets de cet en-tête sont copiés dans une structure du segment de données de l’exécutable pour l’affichage dans l’interface
    • il n’est pas possible de modifier librement tout l’en-tête, mais l’espace disponible suffit pour y placer un petit stub memcpy
  • Déroulé de l’exploit THPS4 sur Xbox originale
    • après le chargement de la sauvegarde, et avant d’appuyer sur « Start Game », les 136 premiers octets sont copiés dans le segment de données exécutable
    • quand on appuie sur « Start Game », le gap name malveillant est copié sur la pile et la return address est remplacée par l’adresse du stub de copie du shellcode
    • au retour de la fonction, l’exécution saute vers le stub de copie, qui recopie le gros payload du buffer de sauvegarde vers le segment de données exécutable
    • après la copie, l’exécution saute vers le payload, ce qui donne une exécution de code arbitraire

Contournement de signature et habibi key

  • Une fois l’exécution de code obtenue sur Xbox originale, il faut désactiver la vérification de signature et lancer un exécutable non signé
  • Le payload est construit à partir de celui de l’ancien installateur softmod de sauvegarde pour 007 Agent Under Fire
    • il localise les fonctions et adresses de données du kernel, puis l’adresse de la clé publique RSA utilisée pour la vérification de signature des exécutables
    • il désactive la protection en écriture du machine state register et patche la clé publique RSA avec la habibi key
    • il exécute ensuite un exécutable auxiliaire inclus dans la sauvegarde ; pendant les tests, un exécutable nyan cat a été utilisé
  • La paire de habibi keys serait une clé RSA créée au début des années 2000 par un groupe de hacking Linux sur Xbox originale
    • au lieu de faire en sorte que la vérification de signature RSA du kernel réussisse systématiquement, leur méthode consistait à remplacer la clé publique par la leur afin de lancer un chargeur Linux
    • ce choix visait à empêcher l’utilisation de ce fichier de sauvegarde pour lancer du contenu piraté, mais d’autres groupes ont ensuite publié des fichiers d’exploit permettant d’installer des hacks persistants
  • Le modulus de la habibi public key a la particularité de ne différer que de 4 octets de la clé publique RSA de Microsoft
    • on pourrait penser que l’exposant devrait être changé à 3, mais les payloads shellcode existants ne modifient pas l’exposant
    • le fonctionnement exact n’est pas totalement clair
  • La méthode habibi key a été choisie pour sa compatibilité avec plusieurs versions du kernel Xbox
    • patcher la fonction de vérification de signature pour qu’elle renvoie toujours true exigerait un repérage de patterns d’instructions différent selon les versions du kernel
    • avec la habibi key, un simple patch de 4 octets dans une zone mémoire facile à trouver suffit

Analyse des variantes : THPS3, THUG, THAW

  • Tony Hawk’s Pro Skater 3

    • THPS3 avait aussi Create-A-Park et le gap name, mais le jeu ne plantait pas immédiatement après le chargement du fichier de sauvegarde malveillant
    • Il était possible de skater dans le jeu, et la console plantait lorsqu’on sélectionnait « quit game »
    • Le gap name était copié non pas sur la pile, mais dans le tas, et le débordement écrasait l’allocation header de l’allocation suivante
    • Quand l’allocation suivante était libérée, les pointeurs du header menaient à la vtable contenant le pointeur de fonction de la routine de nettoyage
    • THPS3, contrairement à THPS4, ne copiait pas l’en-tête du fichier de sauvegarde dans un segment de données exécutable, et les données du fichier de sauvegarde se trouvaient elles aussi dans une mémoire du tas non exécutable
    • En écrasant le pointeur pAllocOwner, il était possible de contrôler l’emplacement de chargement du pointeur de fonction de nettoyage et d’utiliser la chaîne ROP de la mémoire du fichier de sauvegarde via un stack pivot
    • La chaîne ROP, avec seulement quelques gadgets, copiait le shellcode du tas vers un segment de données exécutable puis sautait vers celui-ci
    • Ensuite, comme avec le payload générique « hack xbox kernel » pour THPS4, il appliquait le patch de la habibi key et lançait un exécutable non signé
  • Tony Hawk’s Underground 1 & 2

    • En fuzzant le gap name dans THUG, on obtenait non pas une access violation, mais un bug check complet avec le message Buffer overrun detected!
    • L’exécutable contenait une vérification de stack cookie
    • Le stack cookie est une valeur aléatoire placée avant l’adresse de retour, et le programme vérifie avant le retour de la fonction si cette valeur a été modifiée
    • Pour écraser l’adresse de retour, il faut connaître la valeur du cookie, mais il n’existe aucun moyen de la divulguer dans le chemin du gap name
    • Il y avait bien des variables corruptibles entre le buffer du gap name et le stack cookie, mais elles étaient aussitôt écrasées par le code du jeu et n’étaient donc pas utiles à l’exploit
    • L’exploitation via SEH a aussi été étudiée, mais il n’y avait aucun moyen de provoquer une exception dans le code restant avant la vérification du stack cookie, et aucun exception handler parcourant la chaîne SEH n’était enregistré à ce moment-là
    • THUG2, sur Xbox, ne permet pas non plus d’exploit fondé sur le gap name pour les mêmes raisons
    • En revanche, il existe d’autres bugs strcpy ainsi que des bugs exploitables fondés sur le tas
    • Les versions PlayStation 2, PC et probablement GameCube ont été compilées sans stack cookie, ce qui permet une exploitation via le buffer du gap name
  • Tony Hawk’s American Wasteland

    • THAW étant un jeu postérieur à THUG 1·2, on s’attendait à la présence d’un stack cookie, mais la version Xbox a été compilée sans
    • Il était vulnérable au buffer overflow du gap name, et l’exploit était construit presque à l’identique de celui de THPS4

RCE réseau dans THPS4 : pirater le client sans fichier de sauvegarde

  • Comme l’exploit par fichier de sauvegarde nécessitait une carte mémoire, le choix s’est porté sur les parties LAN multijoueur comme surface d’attaque avec une barrière d’entrée plus faible
    • Lorsqu’un park créé avec Create-A-Park est utilisé en LAN multiplayer, l’hôte envoie le fichier de sauvegarde sur le réseau et le client le charge
    • L’hypothèse a donc été posée qu’il serait possible de pirater la console cliente en lui envoyant un fichier de park malveillant
  • Pour éviter que l’hôte ne se pirate lui-même, l’exécutable du jeu a été modifié afin de bloquer le bug strcpy, et un code segment a aussi été ajouté pour des fonctions supplémentaires
  • Au départ, le client pouvait se connecter à l’hôte et skater normalement, mais le payload ne s’exécutait pas et le buffer overflow ne se déclenchait pas
    • Les données du fichier de park dans la mémoire du client avaient été modifiées et différaient du fichier d’exploit
    • Après avoir chargé le fichier de park, l’hôte le resauvegardait depuis la mémoire puis envoyait ce résultat au client, ce qui corrompait les données d’exploit
  • Une fois cet appel de fonction remplacé par des NOP, le client recevait le fichier de park malveillant, était compromis et la couleur de la LED changeait
  • Sur le chemin réseau, l’en-tête du fichier de sauvegarde n’est pas copié dans le segment de données, il n’était donc pas possible d’utiliser le stub de copie de shellcode de l’exploit local THPS4
    • Une chaîne ROP similaire à celle de THPS3 permettait de copier le shellcode dans une mémoire exécutable

Découverte du code source de THUG et réutilisation du code réseau

  • Il fallait transmettre un exécutable de payload auxiliaire au client par le réseau, mais il n’était pas possible de le placer dans le dossier de sauvegarde comme avec l’exploit local par fichier de sauvegarde
  • Des méthodes de chargement de l’exécutable depuis un CD gravé ou une adresse réseau locale ont aussi été étudiées, mais n’ont pas été retenues
    • L’implémentation winsock de la Xbox utilisait par défaut une connexion socket sécurisée, ce qui imposait de reproduire la couche de sécurité Xbox avec un script Python
  • En cherchant des ressources liées au fichier de sauvegarde de park, une recherche de la chaîne Sk4Ed_Dead a conduit au dépôt GitHub thug
    • Il s’est avéré qu’il ne s’agissait pas d’un outil homebrew, mais du code source complet de Tony Hawk’s Underground
    • Ce n’était pas exactement THPS4, mais la base de code était suffisamment proche pour réutiliser le code réseau et écrire des hooks
  • Le code source contenait le code de chargement du fichier de park ainsi que la ligne exacte où se trouvait le bug strcpy
    • En reconstruisant les fichiers de projet Visual Studio et en corrigeant quelques compiler errors, il a été possible d’obtenir un build exécutable avec les assets finaux du jeu
    • Il ne correspond pas parfaitement à la version finale, mais le code semble extrêmement proche
  • L’objectif a alors évolué au-delà d’une simple RCE : obtenir discrètement une RCE sur la console qui rejoint la partie, permettre l’exécution de code non signé, puis transférer un exécutable auxiliaire pendant la partie

Restauration de l’exécution et transfert de fichiers asynchrone

  • Pour transmettre le payload pendant que le client continuait à jouer, il fallait restaurer le flux d’exécution du jeu après l’exécution du shellcode
  • La chaîne ROP a été modifiée pour sauvegarder le pointeur de pile existant avant le stack pivot, afin de pouvoir le restaurer plus tard après l’exécution du shellcode
    • Elle copiait ensuite le shellcode dans une mémoire exécutable puis sautait vers celui-ci
  • Le système réseau du jeu reposait sur l’enregistrement d’un ID de message et d’une fonction handler, puis appelait le handler correspondant à l’ID du message reçu
  • En enregistrant un ID de message inutilisé, un protocole de transfert de fichier simple a pu être implémenté
    • Quand le client se connecte, il envoie MSG_ID_PAYLOAD_REQUEST à l’hôte pour démarrer le transfert
    • L’hôte envoie ensuite les données du payload dans des messages MSG_ID_PAYLOAD_DATA
    • Quand le client reçoit PAYLOAD_MSG_ID_END, le transfert est terminé

Fuite mémoire vieille de 15 ans et hot patch

  • Pendant le transfert du fichier, la console cliente plantait à cause d’un null pointer dereference
  • L’allocator de données réseau renvoyait NULL, et le nombre d’octets libres du networking memory pool tombait à 0
  • Le code source de THUG contenait bien le code libérant le buffer de données des messages, mais ce correctif n’était pas présent dans la build commercialisée de THPS4
    • Le buffer p_data de stream_desc n’était pas libéré à chaque message, ce qui épuisait le networking memory pool
    • En multijoueur classique, cela pouvait passer inaperçu tant qu’on ne restait pas longtemps dans la partie
  • L’exploit appliquait un hot patch en hookant le code client afin de libérer le buffer p_desc->p_data avec la bonne fonction de libération
  • Après ce hot patch, le transfert de fichier a réussi entre les consoles hôte et cliente, et le client a exécuté l’exécutable nyan-cat
    • Le même exploit a aussi été testé à distance sur la console d’un ami dans une autre région via une application de tunneling

Flux final de l’exploit réseau sur l’original Xbox

  • le client se connecte à une console hôte malveillante et reçoit par le réseau un fichier de park « Hack Xbox »
  • pendant que le client analyse le fichier de park, un buffer overflow se produit, l’adresse de retour de la pile est écrasée et la chaîne ROP démarre
  • la chaîne ROP copie le payload complet de shellcode vers une zone mémoire exécutable puis saute dessus
  • le shellcode met en place les hooks et patchs nécessaires avant de revenir à l’exécution du jeu, puis fait apparaître le joueur dans la partie
  • pendant que le joueur skatte dans le jeu, l’hôte envoie un fichier exécutable au client, qui l’enregistre sur le disque dur du client
  • une fois le transfert de fichier terminé, le shellcode patche le kernel du client pour activer l’utilisation de la clé habibi et démarre l’exécutable secondaire transféré
  • si la couleur de la LED ne change pas, l’utilisateur a du mal à remarquer la progression avant qu’une autre application ne démarre soudainement

Xbox 360 : THAW et le kernel 4548

  • Tony Hawk’s American Wasteland sur Xbox 360 est lui aussi vulnérable au buffer overflow du nom de gap
  • l’objectif était d’exploiter la console sur une nouvelle version du kernel, mais cela était impossible sans nouveau bug d’hyperviseur
  • à la place, il a été possible de créer le premier exploit software-only sur Xbox 360 en combinant le bug strcpy de THAW et le bug du gestionnaire d’appels système du kernel 4548
  • le hack King Kong existant sur Xbox 360 utilisait un fichier shader modifié pour effectuer une écriture arbitraire dans la mémoire du kernel et exploiter le bug du gestionnaire d’appels système
    • cette méthode imposait d’ouvrir la console et de modifier le firmware du lecteur DVD pour utiliser un disque King Kong modifié
    • le bug de sauvegarde de jeu pouvait servir d’autre point d’entrée pour lancer la chaîne ROP

Signature des fichiers de sauvegarde Xbox 360 et rôle des consoles de développement

  • les fichiers de sauvegarde de jeu sur Xbox 360 sont signés avec une paire de clés RSA propre à chaque console
    • le magasin de clés de chaque console contient la clé cryptographique utilisée pour signer les sauvegardes de jeu
  • si une autre console peut vérifier le fichier de sauvegarde, c’est parce que la clé publique RSA est incluse dans l’en-tête du fichier de sauvegarde
    • cette clé publique est elle-même signée avec une autre paire de clés RSA que seul Microsoft possède
    • on ne peut pas simplement mettre n’importe quelle clé publique dans l’en-tête et passer la vérification
  • pour utiliser sur une autre console un fichier de sauvegarde modifié arbitrairement, il faut disposer du magasin de clés déchiffré d’au moins une Xbox 360
  • le point de départ du hacking Xbox 360 a été la fuite d’une console de développement et du SDK
    • comme le code exécutable était chiffré, il était impossible de trouver des bugs sans pouvoir inspecter le code depuis l’extérieur
    • la console de développement et le SDK fournissaient les informations nécessaires pour déchiffrer le code exécutable et pour le reverse engineering de la chaîne de démarrage, de l’hyperviseur et du code du jeu

Bug du gestionnaire d’appels système 4548

  • la Xbox 360 dispose d’un mode réel hyperviseur et d’un mode kernel
    • le mode réel hyperviseur est le mode le plus privilégié
    • en mode kernel, l’OS et le jeu s’exécutent
  • le CPU possède à côté du cache L2 une unité cryptographique chargée du chiffrement et du hachage de la mémoire
    • en mode kernel, les pages de l’hyperviseur apparaissent chiffrées + hachées, et si on les écrase arbitrairement, la console s’arrête lors de l’accès à l’hyperviseur
  • en mode réel, les 32 bits de poids fort de l’adresse physique 64 bits servent à contrôler le chiffrement et le hachage
    • l’application du masque 0x80000000.00000000 permet d’accéder à la mémoire en ignorant le chiffrement et le hachage
    • partout où le mode kernel peut fournir une adresse physique à l’hyperviseur, il faut impérativement effacer les 32 bits de poids fort
  • le gestionnaire d’appels système normal utilise l’instruction slwi pour décaler à gauche de 2 bits l’ordinal de l’appel système, puis ignore les 32 bits de poids fort du résultat afin de n’utiliser qu’un offset 32 bits
  • le gestionnaire d’appels système du kernel 4548 utilise sldi à la place de slwi
    • sldi fonctionne en 64 bits, donc les 32 bits de poids fort de r0 entrent aussi dans le calcul de l’offset d’index de table
    • la vérification de plage de l’ordinal ne s’applique qu’aux 32 bits de poids faible de r0
    • par exemple, 0x20000000.0000003F passe la vérification de plage tout en produisant un offset 0x80000000.000000FC, ce qui provoque un accès mémoire non protégé
  • ce changement est jugé plus probablement dû à un bug du compilateur qu’à une modification intentionnelle du développeur

Construction de l’exploit Xbox 360

  • si l’on écrase la vue mémoire chiffrée de l’hyperviseur en kernel mode, la console s’arrête généralement, mais si l’on fait en sorte que le gestionnaire d’appels système lise un pointeur de fonction à une adresse dont les bits de protection supérieurs sont définis, il peut lire la valeur écrasée sans provoquer de fault
  • étapes de l’exploit
    • charger le shell code en mémoire et obtenir son adresse physique
    • modifier une variable du gestionnaire mémoire du kernel pour exposer la vue mémoire chiffrée de l’hyperviseur dans une plage d’adresses accessible en écriture
    • écraser le pointeur de fonction de l’appel système de l’hyperviseur avec l’adresse de la séquence d’instructions mtctr r4; bctr
    • placer un ordinal malveillant dans r0, et dans r4 la valeur obtenue en appliquant un OU avec le masque 0x80000000.00000000 à l’adresse physique du shell code
    • exécuter l’instruction d’appel système pour que l’hyperviseur lise le pointeur de fonction écrasé et saute vers le shell code via mtctr r4; bctr
  • l’exploit de fichier de sauvegarde THAW utilise une chaîne ROP PowerPC
    • le plugin IDA Ida-Sploiter a été modifié pour prendre en charge la recherche de gadgets PowerPC
    • l’exploit complet est composé de 24 gadgets ROP
  • flux complet sur THAW Xbox 360
    • le dépassement de tampon du nom de gap écrase l’adresse de retour avec celle du premier gadget ROP
    • le pointeur de pile est pivoté vers la chaîne ROP dans le tampon de sauvegarde
    • MmAllocatePhysicalMemoryEx alloue la mémoire physique pour le shell code de l’hyperviseur
    • memcpy copie le shell code et MmGetPhysicalAddress récupère son adresse physique
    • la vue mémoire chiffrée de l’hyperviseur est mappée en écriture
    • l’adresse de fonction de l’appel système est écrasée avec la séquence mtctr r4; bctr
    • syscall est exécuté avec l’ordinal d’appel système malveillant et l’adresse physique du shell code
    • après avoir obtenu l’exécution de code dans l’hyperviseur, l’exploit change la couleur des LED et patche la vérification de signature RSA des exécutables
    • il revient ensuite à la chaîne ROP en kernel mode, mappe un dossier du HDD avec ObCreateSymbolicLink, puis exécute une charge utile secondaire non signée avec XLaunchNewImage
  • cette méthode permet d’obtenir l’exécution ROP via le bug strcpy de THAW sur n’importe quelle version d’OS Xbox 360, mais l’exécution complète de code dans l’hyperviseur n’est possible que sur le kernel 4548
    • si un nouveau bug de l’hyperviseur est découvert, on peut le combiner avec ce point d’entrée pour l’appliquer à des versions de kernel plus récentes

Publication en 2024 et portage vers d’autres plateformes

  • en 2024, les exploits Tony Hawk ont été compilés puis publiés
  • le même bug strcpy est présent dans 5 itérations de la série Tony Hawk ainsi que sur plusieurs plateformes console et handheld
  • PlayStation 2

    • l’exploit RCE réseau de THPS4 a été porté sur la version PlayStation 2
    • avec PCSX2 ou une autre console et simplement le disque de THPS4, il est possible de hacker la console via le réseau
    • l’exploit envoie uLaunchElf par le réseau, puis l’exécute une fois le transfert terminé
    • il est ensuite possible de charger l’installateur de FreeMcBoot ou FreeHDBoot depuis un autre support, comme une clé USB
    • l’exploit par fichier de sauvegarde sur PS2 présente peu d’intérêt pratique
    • si l’on a déjà un moyen de copier des fichiers sur la memory card, on peut directement installer FreeMcBoot
    • il est possible d’acheter une memory card FreeMcBoot sur Amazon pour 15 dollars, ou d’utiliser FreeHDBoot sur une console phat avec un adaptateur réseau
  • GameCube

    • l’exploit par fichier de sauvegarde de THPS4 a été porté sur la version GameCube
    • la version RCE réseau et les autres variantes d’exploit par sauvegarde n’ont pas été portées
    • copier des fichiers sur une memory card GameCube n’est pas simple, et des memory cards contenant une sauvegarde pré-hackée se sont vendues plus de 50 dollars sur eBay
    • les jeux Tony Hawk sur GameCube n’ont pas de support réseau, donc il est impossible d’utiliser l’exploit réseau même avec un adaptateur réseau
    • comme il existe déjà plusieurs exploits via sauvegarde de jeu et qu’il n’y a pas de hack logiciel persistant, beaucoup d’utilisateurs choisissent un modchip
  • Windows

    • un exploit par fichier de sauvegarde pour THUG PRO a également été créé, et un rapport de bug a été transmis il y a 7 ans, mais il n’y avait alors aucun intérêt à le corriger
    • il n’est pas publié car il n’apporte aucune valeur sur Windows
    • les jeux Tony Hawk sur PC contiennent le même bug strcpy et sont exploitables
    • il existe aussi un autre bug strcpy exploitable en jeu en réseau
    • il est recommandé de forcer l’ASLR et de ne pas exécuter le jeu en tant qu’Administrator

Ressources publiées

  • le code source complet et les fichiers de sauvegarde patchés sont publiés sur GitHub
  • un seul bug strcpy a mené à des exploits par sauvegarde, à une RCE réseau et à un point d’entrée d’exploit 100 % logiciel sur Xbox 360 sur plusieurs plateformes

1 commentaires

 
GN⁺ 2024-08-08
Commentaires sur Hacker News
  • Ce qui est le plus intéressant avec la clé Habibi, c’est que le modulus de la clé publique ne diffère de la clé publique RSA de Microsoft que de 4 octets
    Un entier aléatoire de 2048 bits a une probabilité non négligeable d’être factorisable de façon triviale, et même si je ne connais pas la probabilité exacte, on peut l’estimer grossièrement à environ 2^-32
    Ils ont probablement écrit du code qui modifie ou incrémente aléatoirement 4 octets du modulus public, essaie de le factoriser pendant environ 1 milliseconde, puis s’arrête en cas de succès
    En conséquence, il est probable que le modulus public contienne beaucoup de petits facteurs ; un modulus RSA est en général le produit de exactement deux nombres premiers, mais tant que les facteurs sont premiers avec e, les maths continuent de fonctionner même s’il y en a davantage

    • Il suffit de partir d’un entier aléatoire de 2048 bits et de modifier les octets de poids faible pour qu’il soit divisible par 3. Comme on ne manipule qu’une clé publique, c’est facile, et si la clé publique est divisible par 3, on peut utiliser le petit théorème de Fermat pour éliminer la plupart des candidats possibles à la clé privée, ce qui réduit la quantité de calcul nécessaire de plusieurs ordres de grandeur
      Si, avec un peu de chance, l’implémentation RSA suppose exactement deux facteurs premiers, alors on sait déjà que l’un des facteurs vaut 3 ; il suffit donc de diviser la clé publique par 3 pour obtenir l’autre facteur premier
      D’après Wikipedia, la structure d’une clé publique RSA exige que N soit un grand semi-premier et que e soit premier avec φ(N), et quiconque factorise N peut retrouver la clé privée. Dans le contexte du hack Xbox, si on force N à être divisible par le nombre premier 3, alors l’autre premier est N/3, donc la factorisation est réussie
      Le code qui signe avec la clé Habibi se trouve ici : https://github.com/XboxDev/xbedump/blob/b8cd5cd0f8b1cbc4e64f.... Il remplace les 4 derniers octets par 0x89, 0x9c, 0x90, 0x6b, puis divise par 3 et génère à partir de là une clé privée appropriée
    • Un article dont j’étais co-auteur traitait de ce problème. La question était de savoir s’il est possible de générer la clé privée correspondant à une clé publique réelle corrompue, qui ici aussi faisait 2048 bits
      L’application consistait à corrompre une clé publique via rowhammer, puis à exploiter sa factorisation pour fabriquer une nouvelle clé privée correspondante. Cela fonctionnait avec des clés SSH et GPG, avec pour hypothèses pratiques qu’on connaissait par exemple le contenu de la page mémoire contenant la clé
      Le taux de réussite empirique selon le temps de calcul disponible figure en Figure 7, l’analyse théorique est au chapitre 3, et la méthode concrète est décrite en section 4.4
      https://www.usenix.org/system/files/conference/usenixsecurit...
    • La probabilité est bien, bien, bien plus grande que 2^-32. Il suffit de continuer à diviser par autant de petits nombres premiers que possible, puis de lancer un test de primalité rapide comme Miller–Rabin sur la valeur restante
      Par exemple, avec du code qui essaie de diviser par les nombres premiers de 2 à 499, considère que c’est réussi si la valeur tombe à 1, et sinon exécute 20 tours de Miller–Rabin, il m’a fallu environ 100 essais dans mon environnement pour factoriser complètement un entier aléatoire de 2048 bits
    • Une implémentation du théorème des restes chinois échoue s’il y a des facteurs en double
  • Il est difficile d’exprimer à quel point cet exploit est absurde
    Softmodder une Xbox 360 avec le nom d’un parc dans un jeu Tony Hawk, en allant jusqu’à une chaîne ROP de 24 étapes, c’est impressionnant
    Avec la brève oraison funèbre pour l’hyperviseur, l’analyse concise et pragmatique, et l’idée immédiate d’un botnet x360, on a l’impression d’un tir direct en pleine nostalgie Xbox 360 de très haut niveau

  • Le passage « avec un peu de chance, ce sera strcpy » est amusant. À l’origine, cela aurait dû être strncpy, mais un Tony Hawk connu pour défendre les équipements de sécurité aurait sans doute préféré être associé à une copie de chaîne plus sûre

    • La bonne approche est d’utiliser memcpy et de connaître à la fois la taille du tampon de destination et celle du tampon source
      Si la source ne tient pas dans la destination, il faut un traitement spécifique à l’application : faut-il tronquer, abandonner complètement l’opération, ou réallouer le tampon de destination ? strncpy fait presque toujours la mauvaise chose
    • strncpy n’est pas plus sûr. Il peut produire une chaîne non terminée s’il atteint n
      En pratique, il ne faut presque jamais utiliser strncpy, sauf pour des champs de taille fixe comme struct dirent { unsigned short inode; char name[14]; };
      Même dans ce cas, les octets de remplissage devraient souvent être des espaces plutôt que des nul, et strncpy n’aurait jamais dû entrer dans la bibliothèque standard
    • Si vous développez en C/C++ sous Windows, vous pouvez utiliser les fonctions de strsafe.h (https://learn.microsoft.com/en-us/windows/win32/api/strsafe/)
      Quand j’utilisais du C/C++, je trouvais cela plus simple que les fonctions standard du C, car elles géraient les échecs courants comme un tampon trop petit ou un dépassement d’entier, et toutes les fonctions renvoyaient un code d’erreur, ce qui facilitait aussi la vérification
      Ici, StringCchCopyW() ou StringCbCopyW() sont de meilleurs choix que strcpy
    • J’ai lu qu’autrefois, Tony Hawk se promenait en voiture et, quand il voyait des skateurs, il leur criait « fais un ollie » ; s’ils réussissaient, il leur donnait un casque neuf
  • C’est un peu dommage que cet exploit s’applique aussi à THUG PRO
    La scène compétitive de la série Tony Hawk est quasiment morte depuis près de 20 ans, à la brève exception du remake THPS1+2, et ce mod est encore joué aujourd’hui
    Le mod lui-même a maintenant plus de 10 ans et les développeurs d’origine semblent être partis, ce qui explique pourquoi, lorsque Ryan l’a signalé, personne n’a cherché à le corriger. Mais désormais, ce mod devient difficile à utiliser à cause du risque de compromission complète du PC
    J’espère que ce billet atteindra quelqu’un qui a la volonté de patcher le mod

    • Ça avait l’air suffisamment amusant pour que j’aie voulu m’y essayer si j’avais eu le temps. À l’époque où j’en avais, j’avais même réussi à rendre le code source de THUG1 presque jouable sous Windows
      Ce code n’était destiné qu’aux versions console, et l’hypothèse qu’il soit compilé pour Windows signifiait non pas Xbox Windows, mais l’environnement des outils, donc beaucoup de choses fonctionnaient d’une manière complètement différente
  • Ce qui ressemble à l’icône d’en-tête de section devant le texte « So what's the habibi key? » est en réalité une zone HTML details dépliable sur laquelle il faut cliquer si cela vous intéresse
    La question, c’est que si l’histoire selon laquelle la clé Habibi était utilisée exclusivement dans le groupe Linux Console pour empêcher l’usage de contenus piratés est vraie, alors où, quand et comment la clé privée correspondante a-t-elle été rendue publique ou divulguée ?
    L’auteur a patché les 4 octets de différence entre la clé Microsoft et la clé Habibi pour exécuter un binaire « non signé », en réalité un binaire signé avec la clé privée Habibi ; il semble donc clair qu’il avait mis la main sur la clé privée

    • La clé Habibi est créée en patchant la clé Microsoft pour qu’elle soit divisible par 3, ce qui la rend en pratique très facile à factoriser
      La clé privée pouvait être retrouvée trivialement à partir de la clé publique, donc il n’y avait pas vraiment quoi que ce soit à publier ou à faire fuiter
      En gros, c’était un petit CTF de crypto enfoui dans l’exploit de sauvegarde original de 007: Agent Under Fire, et cet exploit de sauvegarde lui-même ressemblait déjà beaucoup à un CTF assez obfusqué. Il y avait sans doute à la fois l’intention d’emmerder les utilisateurs de versions piratées et un défi lancé aux autres spécialistes du reverse engineering
  • Vraiment excellent. J’ai fait un peu de décompilation PSX, et on y voit aussi beaucoup de choses du même genre
    Fait intéressant, quelque chose comme memmove est lié depuis la bibliothèque SDK[0], mais strcpy est une fonction fournie par le BIOS
    Dans des versions ultérieures du SDK, cela a pu être patché vers une version en bibliothèque, mais en 1997 ce n’était toujours pas le cas
    0 - https://github.com/Xeeynamo/sotn-decomp/blob/master/src/main...

    • J’aimerais voir des réimplémentations d’anciens jeux console en C+SDL2 et OpenGL 2.1
      Maintenant que des jeux N64 sont portés sur PC via des décompilateurs, ça donne de l’espoir
      On pourrait répondre « ces jeux ont déjà une version PC », mais si l’on recompile un jeu N64 et qu’on remplace ses effets par des textures pures ou des effets plus simples au lieu de shaders, il pourrait tourner presque partout, même sur des machines lentes comme des netbooks d’entrée de gamme de 2009
      Il existe aussi un portage de Super Mario 64 vers l’API 3DFX. Les jeux qui accèdent de façon complexe au framebuffer N64 exigeraient sans doute OpenGL 3.3 pour émuler leur microcode, mais si le moteur tourne déjà très vite sur du matériel postérieur au Pentium III, il ne serait pas difficile de faire tourner le reste avec l’accélération GL 2.1 et d’émuler uniquement certaines parties en logiciel
  • J’ai lu énormément d’analyses d’exploits de ce genre sous diverses formes, et si je pouvais en lire 100 de plus, j’en serais ravi

  • Cela ressemble à un bon exemple de mauvaise mentalité de sécurité dans le développement console
    L’idée selon laquelle « seules nos données de sauvegarde peuvent être utilisées, donc il suffit de parser ce que nous écrivons » est courante côté consoles, mais elle est fondamentalement erronée puisque des gens peuvent préparer des sauvegardes artificielles
    Indépendamment de cela, une console ne devrait pas traiter l’utilisateur comme un ennemi, mais si elle le fait malgré tout, alors le jeu devrait lui aussi adopter une approche sécurité cohérente avec cette posture

    • C’est devenu en partie la réalité aujourd’hui. Les consoles actuelles chiffrent et signent toutes les sauvegardes en les liant au compte, et la plupart, même si je ne sais pas pour Xbox, empêchent de copier les sauvegardes ailleurs que sur la console elle-même et dans un stockage cloud payant
    • Sur un ordinateur classique, je serais 100 % d’accord avec l’idée qu’« une console ne devrait pas traiter l’utilisateur comme un ennemi », mais pour les consoles cela me paraît un peu différent
      Je ne vois pas comment empêcher la triche dans les jeux en ligne si l’on ne limite pas ce que l’utilisateur peut faire
  • Pour défendre Tony Hawk, c’est un skateur professionnel, pas un analyste sécurité
    Le peu de temps qu’il a passé devant un clavier à la fin des années 1990 et au début des années 2000 a sans doute servi non pas à auditer des buffer overflows, mais à faire en sorte qu’un 900 McTwist paraisse naturel dans ce qui allait devenir une série emblématique

  • J’ai enfin l’occasion de vérifier une légende entendue dans mon enfance. Est-ce que la première personne à avoir réussi un 720 était Tony Hawk ?

    • D’après https://en.wikipedia.org/wiki/Aerial_(skateboarding), « le 720, un trick consistant à faire deux rotations complètes en l’air, est l’un des tricks les plus rares du skateboard ; Tony Hawk l’a réussi le premier en 1985, et ce n’était pas prémédité »
      Cela veut sans doute dire « le premier cas documenté », mais si quelqu’un l’avait déjà fait, il y a de fortes chances qu’il s’en serait vanté, et la personne capable d’y arriver aurait de toute façon probablement été un skateur professionnel