Faille de sécurité dans l'hyperviseur Xbox 360

[Newserator]

Un bug permettant d'exécuter du code non signé malgrès la présence du fameux hyperviseur a été dévoilé sur la mailing list de Securityfocus.com.

Ce bug touche uniquement certaines versions du kernel et n'est plus présent depuis la dernière mise à jour. Cela explique les raisons de la publication de cette faille de sécurité dont voici les détails :

Xbox 360 Hypervisor Privilege Escalation Vulnerability

Date de publication: February 28, 2007

Auteur: Anonymous Hacker

Chronologie:

Oct 31, 2006 - publication du kernel 4532, qui est la première version à contenir le bug

Nov 16, 2006 - preuve de l'exploitation du bug effectuée; du code non signé est lancé malgrès la présence de l'hyperviseur

Nov 30, 2006 - publication du kernel 4548, le bug n'est toujours pas corrigé

Dec 15, 2006 - premier essai de contact du fabricant pour reporter le bug

Dec 30, 2006 - démonstration publique (Note de Gx : la fameuse vidéo au CCC)

Jan 03, 2007 - établissement d'un contact avec le fabricant, tous les détails sont fournis

Jan 09, 2007 - publication d'un patch par le fabricant

Feb 28, 2007 - mise à disposition des explications au public

Temps de développement du patch: 6 jours

Sévérité: Critique (Execution de code non signé en Mode Hypervisor)

Fabricant: Microsoft

Systèmes Affectés:

Tous les systèmes Xbox 360 avec une version de kernel 4532 (publiée en Oct 31 2006) et 4548 (publiée en Nov 30, 2006). Les versions précédentes au 4532 ne sont pas affectées. Bug corrigé dans la version 4552 (publiée en Jan 09, 2007 - en dehors des habituelles mise à jour du Mardi).

Vue d'ensemble:

Une vulnérabilité dans l'hyperviseur Xbox 360 a été découverte, permettant une escalade des privilèges dans le mode Hypervisor. Via une méthode injectant des données dans un espace mémoire non-privilégié, cette vulnérabilité permet à un personne ayant un accès physique à la Xbox 360 de lancer du code personnalisé tel qu'un système d'exploitation avec un accès total au niveau privilège et également matériel.

Détails techniques:

Le système de sécurité de la Xbox 360 est réalisé autour du concept d'hyperviseur. Tous les jeux et autres applications, qui doivent être signés avec une clé privée de Microsoft, fonctionnent en mode non-privilégié, pendant que seul un "petit" hyperviseur fonctionne en mode privilégie (hypervisor). L'hyperviseur contrôle les accès mémoire et fourni les services d'encryptage et décryptage.

La politique implémentée dans l'hyperviseur force tout code exécutable a été en mode lecture-seule et encrypté. Par conséquent, du code non-privilégié ne peut modifier du code exécutable. Une attaque physique de la mémoire pourrait modifier le code, cependant le code en mémoire est crypté avec une clé unique par session, rendant toute modification significative du code mémoire indistribuable. De plus, la stack (pile) et heap sont toujours marqués comme non exécutable, et donc les données chargées ici ne peuvent jamais être outrepassées par du code non-privilégié.

Le code non-privilégié interagit avec l'hyperviseur via l'instruction "sc" ("syscall"), qui fait passer la machine en mode hypervisor. La vulnérabilité est le résultat d'une vérification incomplète des paramètres passés par le dispatcher syscall comme illustré ci-dessous.

Preconditions (enregistrements effectués par du code non-privilégié):

%r0 syscall no.

%r3-%r12 syscall arguments

Code privilégié:

13D8: cmplwi %r0, 0x61

13DC: bge illegal_syscall

...

13F0: rldicr %r1, %r0, 2, 61

13F4: lwz %r4, syscall_table(%r1)

13F8: mtlr %r4

...

1414: blrl

Le problème est que l'instruction "cmplwi" compare seulement les 32 bits inférieurs du nombre syscall indiqué, les 32 bits supérieurs sont ignorés. L'instruction "rldicr", cependant, opère sur la totalité de la valeur du registre 64 bit.

L'adresse du gestionnaire (handler) syscall se trouve sur la table offset du gestionnaire syscall à 0x00000000.00001F68+%r0*4. En paramètrant les 32 bits supérieurs de %r0 à quelque chose autre que 0 changera les 30 bits supérieurs de l'adresse utilisée pour définir la table offset du gestionnaire syscall. Voici l'explication sur comment l'architecture de la sécurité Xbox 360 interprète et alias ces bits supérieurs.

Lors de l'utilisation du syscall, le processeur fonctionne en mode réel "hypervisor", avec la MMU désactivée. Cependant, lors de l'accès à des emplacements mémoire avec MSB cleared, un offset additionnel, le Hypervisor Real

Mode Offset (HRMO), sera appliqué à toutes les adresses mémoire.

A cause de l'architecture de la sécurité de la Xbox 360, la mémoire principal est "clonée/liée" (alias) vers différentes adresses avec des proriétés différents, afin de conditionner l'activation des fonctionnalités de sécurité (encryptage et hashing). L'hypervisor définit la valeur du registre spécial HRMO afin que le code hyperviseur, incluant le jump de la table syscall, réside dans la mémoire qui est hashée autant qu'elle est cryptée, même en utilisant des adresses zero-based.

En accédant aux espaces mémoire avec une adresse de bit le plus significatif possible, le paramètre HRMOR n'est pas appliqué. A cause du bug dans l'instruction "cmplwi", paramètrer les bits correspondant dans %r0 dans l'entrée syscall permet de paramètrer le MSB, de ce fait cela permet de dépasser le HRMOR en paramètrant et dupant l'adresse attendue du gestionnaire syscall pour chercher depuis la mémoire sans aucune fonctionnalités de sécurité.

Avec la table offset du gestionnaire syscal "liée" à la mémoire décryptée, la table du gestionnaire syscall peut désormais être modifiée pour indiquer à l'hyperviseur de sauter vers n'importe quel endroit dans un espace du code qui est désigné pour l'hyperviseur.

Dans la présentation du concept d'implémentation, un saut vers du code hyperviseur existant est utilisé avec une valeur enregistrée pré-chargée, comme un trampoline, pour forcer l'exécution du path vers un endroit de la mémoire non crypté et exécutable.

Détails du Proof of Concept (preuve du concept):

Comme il n'est pas possible de remplacer directement même du code non-privilégié, le code existant doit être "dupé" dans le but d'appeler le syscall hyperviseur avec la configuration souhaitée. Cela peut-être effactué en mettant un place un stack frame en forçant un switch annexe à ce stack frame. Le bug peut être exploité en utilisant la série d'écritures mémoires physiques suivantes:

Mise en place d'un switch "annexe" à la stack @80130AF0:

00130390: 00000000 00000000 00000000 FDFFD7FF MSR mask

00130360: 00000000 80130AF0 00000000 00000000 New stack pointer

Mise en place du stack:

00130BD0: 00000000 80070190 00000000 00000000 NIP to context restore

00130C90: 00000000 00000000 80070228 80070228 NIP, LR after context

restore point to syscall

instruction in kernel

00130CA0: 00000000 00009030 00000000 00000000 MSR

00130B40: 20000000 00000046 00000000 80130af0 r0 = syscall nr

r1 = stack

00130B60: 80000000 address1 r4 = address to jump to

00002080: 00000350 points to mtctr %r4,

bctr in hypervisor code

Le code qui doit être exécuté doit être placé à "address1", qui peut-être une adresse mémoire quelconque mais non utilisée.

Example de code pour sortir '!' sur le port série:

1:

li %r3, '!'

bl putc

b 1b

putc:

lis %r4, 0x8000

ori %r4, %r4, 0x200

rldicr %r4, %r4, 32, 31

oris %r4, %r4, 0xea00

slwi %r3, %r3, 24

stw %r3, 0x1014(%r4)

1:

lwz %r3, 0x1018(%r4)

rlwinm. %r3, %r3, 0, 6, 6

beq 1b

blr

Vous l'aurez compris, l'exploitation de ce bug est très technique, et même si celui-ci est corrigé depuis les dernières mise à jour du kernel, peut-être qu'un éventuel downgrade façon PSP permettrait de remettre au goût du jour ce genre de faille de sécurité.Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=1250

[Oasis]

Petit sondage :

- Combien de temps avez-vous mis pour lire cet article ?

- Combien de temps avez-vous mis pour comprendre cet article ? Si vous l'avez compris xD

[Malakill]

c'est quand meme assez technique comme écris dans la new, moi en fait j'y ai rien compris, mais ya une chose que je sais sa montre que la xbox n'est pas "inhackable" et que j'estime dans pas tres long nous pourons lancer nos propres homebrew sans avoir a player par mois pour le super XNA.....

Merci legueux pour la traduction qui a tu te prende beaucoups de temp

[legueux]

Petit sondage :

- Combien de temps avez-vous mis pour lire cet article ?

- Combien de temps avez-vous mis pour comprendre cet article ? Si vous l'avez compris xD

Réponse : trop

[cristou]

ON LE TIENT !

[zouzzz]

Merci pour la traduction, c'était bien chaud à faire.

[TPretender]

coucou,

Chapeau Le Gueux....

Je sais pas pour vous mais moi, J'ai fais direct le raprochement avec cette news: Downgrade kernel Xbox 360 : oui mais...

Imaginez un futur TRéS Proche ou une Team X sortira une puce permettant de repassé la 360 en Kermel 4548 ou 4532, et donc de pouvoir lancé du code non-signez...

Voir mieu un soft PC permettan de revenir sur une version antérieur du Kermel...

Wait And See....

Le bout du tunel est proche.... (n'enpéche qu'il etait long ce foutu Tunel )

@+ Les Gueux

[zouzzz]

Ca doit bosser raide depuis hier du coté de Robinsod.

[Pierrinator]

Omg, enfin...

J'ai tout lu, c'est tres intéressant en plus ^_^

[JSR]

Malheureusement, le downgrade de kernel est impossible depuis la version 4552 car le bootloader a été physiquement reecrit depuis cette version et on ne peut pas le remplacer meme physiquement (present dans le cpu).

Je me demande combien de temps il faudra avant qu'un exploit correct (cad qui charge un .xex non encrypte/non signé depuis le HDD et pas qu'un simple helloworld) sorte. Personnellement beaucoup de temps et malheureusement pas une methode qui puisse etre utile pour nous. Je pense que ce sera à l'aide d'une version modifié de King Kong (Les Shaders seront modifié) + Lecteur dvd reflashé pour permettre le boot de la version modifié.

On peut esperer que ca permette aux vrai hacker de pouvoir s'entrainer enfin et d'etre pret au cas ou une nouvelle faille apparait (mais bon, il leur faut de l'argent car il faut se procurer une xbox 360 avec le kernel < à 4552).

Mais je trouve que le hacker est quand meme un sacré ***** de ne pas avoir divulgué la faille avant que microsoft ne la corrige depuis ses mails. Cela aurait pu permettre les homebrew pour tous car une majorité n'aurait jamais mis à jour ! Combien de temps avant la prochaine faille :s ? Car la je peux vous dire que le gars possede vraiment un enorme niveau en assembleur...

Comme quoi on peut etre intelligent et con à la fois !

Modifié 1 mars 2007 par JSR

[Soja_raider]

premier vrai exploit !!!! après 1ans et 3 mois !

[zouzzz]

Malheureusement, le downgrade de kernel est impossible depuis la version 4552 car le bootloader a été physiquement reecrit depuis cette version et on ne peut pas le remplacer meme physiquement (present dans le cpu).

Comment casser tous nos espoirs en une phrase. Merci de ces précisions/informations.

[cobra333]

salut a tous moi je n est jamais mis a jour ma 360( elle date de aout 2006) aurai je bien fait?

[bonx]

Malheureusement, le downgrade de kernel est impossible depuis la version 4552 car le bootloader a été physiquement reecrit depuis cette version et on ne peut pas le remplacer meme physiquement (present dans le cpu).

Bonjour,

es tu certain de cela? il me semble que les mises à jours sont écrites sous formes de patches dans la mémoire flash et que c'est au début de

la mémoire flash qu'est écrit le numéro de la dernière version. le retour à une version précédente est donc possible sauf si des efuses ont été consommés entre temps.

Comment fait on pour mettre les instructions en mémoire de la console ? quel compilateur faut il utiliser ?

@+

[JSR]

Salut Bonx,

Oui effectivement, des efuses sont consommés durant la mise à jour vers la 4552. C'est la premiere fois dans une update. On comprend bien pourquoi maintenant.

Pour envoyer les instructions en memoire, on ne sait pas encore vraiment comment, mais on sait qu'il y a moyen en modifiant les shaders du jeu King Kong car ils ne sont pas signés/encryptés. Il y a des instructions pour les shaders qui permettent d'ecrire precisement dans la ram avec le GPU (rappel : memoire partagé CPU/GPU).

Pour le compilateur, il n'y en a pas de public pour la xbox360 mais je suppose qu'une version bidouillé de gcc fera l'affaire.

Modifié 1 mars 2007 par JSR

[skaazi]

'Lut les gueux!

Moi ce que j'ai retenu c'est qu'il y a un traitre qui à trouvé la faille et qui l'à ensuite dénoncée à Kro$oft, peut être qu'il s'est dit que ça la pistonerai direct à une place d'ingénieur en sécurité chez Billou où il pourrait avoir plein de $$$...

Perso, moi j'attends l'arrivée du code non signé juste pour pouvoir béneficier pleinement du contenu multimedia en HD sur la 360 avec un XBMC, peut être aussi les emulateurs (je ne me sert plus que des emus et XBMC sur la Xbox1, mais elle est pas assez puissante pour gerer la HD en x264 ou en .ts, et de toujours tout convertir en wmv pour pouvoir lire sur la 360, ça me gave).

Le bout du tunel est proche.... (n'enpéche qu'il etait long ce foutu Tunel )

Il à déjà été plus loin, mais pour l'instant la lumière est encore assez bien loin...

Je sais pas si j'ai bien compris, mais si quelqu'un arrive à "hacker" sa console, ça ne sera que pour lui...:

Une attaque physique de la mémoire pourrait modifier le code, cependant le code en mémoire est crypté avec une clé unique par session, rendant toute modification significative du code mémoire indistribuable

Ensuite je suis pas sur de capter le tout, mais ça doit vouloir dire que c'est encore plus mort...:

De plus, la stack (pile) et heap sont toujours marqués comme non exécutable, et donc les données chargées ici ne peuvent jamais être outrepassées par du code non-privilégié.

M'allez, l'espoir fait vivre, et de toute façon, Kro$oft ne fait que retarder l'inévitable, un jour elle sera désossée comme la première...

++

Modifié 1 mars 2007 par skaazi

[bonx]

Salut Bonx,

Oui effectivement, des efuses sont consommés durant la mise à jour vers la 4552. C'est la premiere fois dans une update. On comprend bien pourquoi maintenant.

Pour envoyer les instructions en memoire, on ne sait pas encore vraiment comment, mais on sait qu'il y a moyen en modifiant les shaders du jeu King Kong car ils ne sont pas signés/encryptés. Il y a des instructions pour les shaders qui permettent d'ecrire precisement dans la ram avec le GPU (rappel : memoire partagé CPU/GPU).

Pour le compilateur, il n'y en a pas de public pour la xbox360 mais je suppose qu'une version bidouillé de gcc fera l'affaire.

re,

@#*! d'efuses ! les mécanismes sont vraiment de plus en plus balaises.

J'avais tenté la reprogrammation de la mémoire flash de la console avec l'extraction d'une autre mais cela ne marchait pas pour cette raison.

Si jamais tu as plus d'infos sur la méthode pour l'envoi des instructions, je suis intéressé.

En attendant merci pour ces réponses.

@+

[Yelrac]

Yop, juste pour info c'est quoi une efuse?

Merci A+

[Jlz]

Lo,

sur le site t'as un bon moteur de recherche:

http://x360.gx-mod.com/modules/news/article.php?storyid=622

http://x360.gx-mod.com/modules/news/article.php?storyid=1211

++

[Yelrac]

OK merci beaucoup j'ai cherché sur google mais étant tombé sur ibm je ne voyé pas le rapport... dsl

[Koss]

Sa approche, lentement, mais sa approche.

[pizzaman]

le langage utilisé pour la faille est de l'assembleur. je m'y connais pour avoir pas mal touché a ce langage sur differents µprocesseurs, et quand on sait a quoi correspondent les instructions, c'est tellement bien trouvé. le gars en effet maitrise l'assembleur, mais ca m'etonne qu'une telle faille n'ai pas ete trouve avant, car perso c'est une des premieres que j'arrive a comprendre sans probleme.