Comme promis, le développeur qui fait trembler la scène PlayStation 4 vient une nouvelle d'assurer ses dires. Après avoir promis il y a deux mois de porter l'exploit dévoilé par la Team fail0verflow sur le firmware 4.05 de la PlayStation 4, voilà qu'il détaille désormais son fonctionnement.
Le développeur Specter vient en effet cette nuit de dévoiler le code utilisé, assurant une nouvelle fois de ses connaissances importantes, mettant en avant l'écriture du code et les tables de matière qui ont été employées.
En plus de 5500 mots il explique toutes les procédures utilisées pour parvenir à l'exploit, commençant par le fait qu'il ne tolère ni ne cautionne le piratage, et que l'exploit n'a pas été créé pour cela. Dans cet article, il fourni une explication détaillée de la façon dont est mise en oeuvre l'exploit publique le décomposant étape par étape. Vous pouvez trouver la source complète de l'exploit, l'exploit userland n'est bien entendu pas décrit, mais il rappelle qu'il l'a déjà fait par le passé.
Les changements depuis le 1.76
Certaines choses notables ont changé depuis le firmware 1.76, Sony a corrigé le bug où nous pouvions allouer la mémoire RWX à partir d'un processus non privilégié. Le processus que nous détournons via l'exploit WebKit ne dispose plus d'autorisations de mappage de mémoire RWX, car JiT est désormais correctement géré par un processus séparé. L'appel de sys_mmap () avec l'indicateur d'exécution fonctionne, cependant, toute tentative d'exécution de cette mémoire de code entraînera une violation d'accès. Cela signifie que notre exploit noyau doit être entièrement implémentée dans les chaînes ROP, pas de payloads C ici.
Le kASLR et de nouveaux system calls
Un autre changement notable est le kernel ASLR (kASLR) qui est désormais activé après le firmware 1.76.
Certains nouveaux system calls ont également été mis en oeuvre depuis la version 1.76. Sur 1.76, il y avait 85 system calls personnalisés. Sur 4.05, nous pouvons voir qu'il y a 120 system calls personnalisés.
Sony a également supprimé le system call 0, de sorte que nous ne pouvons plus appeler un system call que nous souhaitions en spécifiant le numéro d'appel dans le registre rax. Nous devrons utiliser des wrappers du module libkernel.sprx qui nous est fourni pour accéder aux system calls.
On le voit Sony a tout mis à oeuvre pour protéger l'architecture interne de sa console mais cela n'a pa suffit.
Toutes les étapes
Le développeur détaille ensuite chaque étape, la première étape de l'exploit consiste à obtenir des informations importantes du noyau, pour cela il faut s'appuyer sur 3 informations, la divulgation / fuite d'informations sur le kernel. Cela se produit quand il est copié par l'userland mais sans que le tampon ne soit initialisé.
Cela signifie que si une fonction est appelée avant de stocker des pointeurs (ou des données d'ailleurs) dans cette mémoire, il y aura une fuite.
Les développeurs peuvent utiliser ceci à leur avantage, et utiliser une fonction de configuration pour leaker de la mémoire spécifique afin de créer des exploits. C'est sur cette théorie que l'exploit kernel est basé. Specter a pris le soin d'expliquer ensuite le fonctionnement des préfixes d'adresses FreeBSD car il est important de distinguer les pointers du kernel et de l'userland.
Le system calls 634
Il explique ensuite qu'on va utiliser le system calls 634 (Vector sys_thr_get_ucontext) qui permet d'obtenir des informations sur un thread donné. Le problème est que certaines zones de la mémoire copiées ne sont pas initialisées, et donc la fonction perd de la mémoire à certains endroits. Ce vecteur a été corrigé en 4.50, car maintenant, avant que le tampon soit utilisé, il est initialisé à 0 via bzero ().
Le plus gros problème avec cette fonction est qu'elle utilise beaucoup d'espace de pile, donc nous sommes très limités à ce que nous pouvons utiliser pour notre fonction d'installation.
C'est cette partie de l'exploit qui a pris le plus de temps et de recherches, car il est difficile de savoir ce que vous leakez sans débogueur, il faut faire quelques suppositions et des expérimentations pour trouver un objet approprié. Obtenir des résultats parfaits ne sera pas très utile non plus car les fonctions peuvent changer entre les firmwares, surtout quand c'est un saut du firmware 1.76 au firmware 4.05. Cette étape m'a pris environ 1-2 mois dans mon exploit original (il faut rappeler que Specter disait qu'il avait déjà l'exploit avant la publication de la Team fail0verflow qui lui a surtout permi de savoir quel objet était exploitable).
L'exploit se base sur la création d'un thread qui implique l'implémentation d'une fonction, cela est possible grâce à un appel dans le WebKit sur 4.05 par l'offset 0x11570 dans libkernel.
Ensuite, Specter explique qu'il faut faire sauter la protection de kASLR, pour cela il faut manipuler le registre cr0 pour désactiver la protection en écriture du kernel pour les correctifs du noyau. Pour le faire il va utiliser un pointeur de .text pour trouver l'adresse du kernel, pour ensuite injecter l'objet exploitable détaillant chaque étape (stage1, stage2, l'implémentation, stage3, stage4, stage5, la sortie vers l'userland, stage6 et stage7)
La sortie vers l'userland
La sortie vers l'userland a été difficile a mettre en oeuvre, le fait de quitter la chaîne kROP pouvait provoquer le crash du noyau. Pour éviter cela, nous devons restaurer RSP à sa valeur avant les modifications. Il donne les instructions a appliquer pour appliquer un correctif RSP en faisant apparaître la fuite de la pile + 0x3C0 dans le registre RSP, et lorsque le ret final du gadget reviendra à une exécution correcte. Bref un énorme travail là aussi.
Conclusion
Vous l'aurez compris le travail accompli est tout simplement énorme, alors encore une fois soyez patient, un exploit se doit d'être le plus stable possible, cela ne se trouve pas en 5 minutes, et même quand le moyen de lancer l'exploit kernel est trouvé, il faut ensuite un travail gigantesque derrière pour pouvoir l'utiliser (pour rappel il a fallu un an entre la sortie de l'exploit kernel 1.76 et les premières sorties publiques de dumps).
Cet exploit est un exploit assez intéressant pour Specter, mais il a fallu beaucoup de devinettes et il aurait été beaucoup plus amusant de travailler avec s'il avait entre les mains un débogueur de kernel approprié. Pour obtenir un objet exploitable cela a été assez long et épuisant, dans l'ensemble, cet exploit est incroyablement stable, en l'exécutant 30 fois, le kernel ne s'est écrasé qu'une fois. Specter conclue en disant qu'il a beaucoup appris de sa mise en oeuvre en espérant que certains développeurs apprendront de nouveaux éléments.
Remerciements à
- CTurt
- Flatz
- qwertyoruiopz
- d'autres contributeurs anonymes
Tout est là : Exploit-Writeups
