Georges Hotz a récemment publié son exploit permettant le hack de la PS3. La méthode d'application du hack est désormais connues, mais la méthode utilisée reste encore floue pour nombre de personnes. Voici une analyse plus poussée afin de mieux comprendre l'exploit.
La PS3, à l'image de la Xbox 360, dépend d'un hyperviseur qui augmenter la sécurité. Contrairement à la Xbox 360, la PS3 permet aux utilisateurs de lancer Linux s'ils le souhaitent, mais celui-ci reste sous le contrôle de l'hyperviseur. Ce dernier ne permet pas au kernel Linux d'accéder à différents périphériques, tel que le GPU. Si une méthode permettant de compromettre l'hyperviseur est trouvée, alors l'accès direct au hardware est possible, et d'autres bouts de code nécessitant des privilèges moindres peuvent être supervisés et contrôlés par le hacker.
Hacker l'hyperviseur n'est pas l'unique étape nécessaire au lancement de jeux pirates. Chaque jeu possède un clé de cryptage stockée dans une partie du disque nommée Rom Mark. Le firmware du lecteur vérifie cette clé et la soumet à l'hyperviseur afin de décrypter le jeu durant chaque chargement. L'hyperviseur doit donc être subverti afin de révéler la clé pour chaque jeu. Une autre approche serait de compromettre le firmware du lecteur Blu-Ray ou de passer l'extraction de la clé et juste attaché le code de décryptage afin de décrypter chaque jeu. Après cela, n'importe quelle mesure de protection dans le jeu devra être désactivée. Personne ne connait pour le moment quelles mesures d'auto-protection sont susceptibles de se dissimuler dans le cryptage d'un jeu. Certains auteurs peuvent croire uniquement dans le cryptage, d'autres peuvent implémenter des mesures telle que SecuROM.
Le code de l'hyperviseur se lance à la fois sur le CPU principal (PPE) et un de ses 7 co-processeurs Cell (SPE). Le thread SPE semble se lancer dans un mode isolé, où l'accès à son code privé et les données mémoires est bloqué, même pour l'hyperviseur. Les clés hardware ROOT utilisées pour décrypter le bootloader ainsi que l'hyperviseur sont présentes uniquement dans le hardware, probablement via l'utilisation d'Efuses. Cela peut également signifier que chaque processeur Cell possède ses propres clés uniques, et le décryptage ne dépend pas d'une seule clé unique ROOT (contrairement à certains articles qui laissaient entendre qu'il n'existait qu'une seule clé ROOT).
Le hack de Geohot a compris l'hyperviseur après le boot de Linux via la fonction "OtherOS". Il a utilisé l'exploit pour ajouter des fonctions de lecture/écriture dans la mémoire et effectuer un dump de l'hyperviseur. L'accès à lv1 est une 1ére étape nécessaire afin de préparer d'autres attaques vers le firmware ou les jeux.
Son approche est intelligente et répond au nom de "glitching attack". Ce genre d'attaque matérielle implique l'envoi d'une impulsion électrique à un moment précis afin de provoquer un comportement inattendu du hardware. Ce genre de procédé est utilisé depuis longtemps par les hackers de Smartcard afin de débloquer celles-ci. Typiquement, les hackers chronomètrent l'impulsion afin de cibler une boucle de terminaison, provoquant la continuité de cette boucle et dumper le contenu d'une ROM secrète vers un bus accessible. La zone contrôlant "l'horloge" est souvent faillible mais certaines zones transportant les données sont également des cibles intéressantes. Le temps de l'impulsion ne nécessite pas toujours d'être précis puisque le hardware est prévu pour tolérer certaines conditions n'entrant pas dans les spécifications habituelles et l'attaque peut facilement être répétée de nombreuses fois jusqu'à ce qu'elle aboutisse.
Geohot a connecté un FPGA à une zone du bus mémoire de la PS3. Il a ensuite programmé une puce avec une logique simple : envoyer une impulsion de 40ns via le pin de sortie via un bouton poussoir. Ce type de programme peut être réalisé grâce à quelques lignes de Verilog. Bien que le temps d’exécution de l’impulsion est très court (mais cela correspond tout de même à 100 cycles de l’horloge mémoire de la PS3) , le déclenchement reste extrêmement imprécis. Cependant, il a utilisé un logiciel pour paramétrer la RAM afin d’augmenter les chances de succès.
Son but était de compromettre la « hashed page table » (HTAB) afin d’obtenir un accès en lecture/écriture au segment principal qui cartographie toute la mémoire, y compris l’hyperviseur. L’exploit consiste en un module du kernel Linux qui cible diverses requêtes système de l’hyperviseur, requêtes traitant de la gestion mémoire. Il alloue, désalloue, puis essai d'employer la mémoire désallouée comme HTAB pour un segment virtuel. Si la faille arrive avec succès à désynchroniser l’hyperviseur de l’état actuelle de la RAM, cela permet à l’attaque de remplacer la HTAB active et de contrôler l’accès à n’importe partie de la mémoire. Voyons cela un peu plus en détails.
La 1ére étape consiste à allouer un buffer. L’exploit envoie ensuite une requête pour que l’hyperviseur duplique à de nombreuses reprises les cartographies de la HTAB pointant vers ce buffer. N’importe laquelle de ces cartographies peut être utilisée pour lire ou écrire dans ce buffer, ce qui est parfait puisque le kernel gère ce buffer. En terme Unix, voyez cela comme de multiples fichiers gérés dans un fichier mémoire temporaire. Chaque fichier peut être fermé, mais temps qu’il subsiste un fichier ouvert, les fichiers restent accessibles.
L’étape suivante consiste à désallouer le buffer sans pour autant libérer dans un 1er temps toutes les cartographies qu’il contient. Juste après avoir appeler la fonction « lv1_release_memory() », l’exploit affiche un message à l’intention de l’utilisateur pour que celui-ci appui sur le bouton poussoir. Du fait de la présence de nombreuses cartographies HTAB dans ce buffer, l’utilisateur a de grandes chances d’ouvrir la faille pendant que l’hyperviseur désalloue l’ensemble des cartographies. La faille évite probablement un ou plusieurs cycle d’écriture de l’hyperviseur sur la mémoire. Ces écritures ont pour but de désallouer chaque cartographie, mais si elles échouent, la cartographie reste intacte.
A ce moment précis, l’hyperviseur a une HTAB avec une ou plusieurs cartographies de lecture/écriture pointant vers un buffer qu’il a désalloué. Ainsi, le kernel n’a plus la main sur ce buffer et il ne devrait donc pas être capable d’écrire dessus. Cependant, le kernel possède toujours un ou plusieurs accès à ce buffer et peut en modifier le contenu. Mais ce n’est pas encore très utile puisqu’il s’agit juste d’un espace mémoire vide.
L’exploit crée alors un segment virtuel et vérifie si la HTAB associée se trouve dans une région couvrant l’adresse du fameux buffer. Si ce n’est pas le cas, il continue de créer des segments virtuels jusqu’à ce que la correspondance intervienne. Désormais, l’utilisateur a la possibilité d’écrire directement dans cette HTAB au lieu que l’hyperviseur possède l’unique contrôle de celle-ci. L’exploit écrit certaines entrées dans la HTAB lui donnant l’accès complet au segment principal, qui couvre toute la mémoire. Une fois que l’hyperviseur passe sur ce segment virtuel, l’attaque permet de contrôler toute la mémoire et l’hyperviseur lui-même. L’exploit met ensuite en place deux syscalls qui donnent un accès direct en lecture/écriture sur n’importe quelle adresse mémoire, puis retourne au kernel.
Il est fort possible que quelqu’un package cette attaque dans un modchip puisque la faille ne nécessite pas d’avoir un timing extrêmement précis. Avec un micro-contrôleur et un circuit analogue pour l’impulsion, cela peut être parfaitement réalisable. Cependant, il est vraisemblable qu’un bug software sera découvert après avoir effectuer un reverse-engineering du dump de l’hyperviseur et c’est ce qui sera surement le plus utilisé par la suite.
Sony semble avoir réalisé un excellent travail autour de la sécurité de la PS3. Tout est parfaitement maitrisé, sans réel points de faiblesse. Cependant, l’accès bas niveau offert aux kernels d’autres OS signifie que n’importe quel bug dans l’hyperviseur est possiblement accessible à un code d’attaque vu le nombre d’API qu’il offre. Une correction simple serait de relire l’état de chaque cartographie après une modification. Si l’écriture échoue pour n’importe quelle raison, l’hyperviseur le verrait et stopperait tout.
Il sera intéressant de voir comment Sony compte répondre avec de futures mises à jour pour prévenir ce type d’attaque.
Source :
rdist.root.org &
ps3.gx-mod.com
Mode linéaire
