Que se passe-t-il si un périphérique sécurisé a un format crashdump visible ? Et si ce même périphérique permettait de mettre de la mémoire arbitraire dans le crashdump ? Étonnamment, la PlayStation 4 prend en charge ces deux fonctionnalités, et c'est la Team fail0verflow qui nous en informe !
Deux parties, le crashdump et le lancement de code arbitraire dans la mémoire !
Crashdumps sur PS4
L'infrastructure de gestion dr crash dans le kernel ps4 est intéressante pour 2 raisons :
- C'est un code spécifique à la PS4 (susceptible d'être bogué)
- Si le crashdump peut être décodé, nous obtiendrons des informations très utiles pour trouver des bogues et créer des exploits fiables
Sur un système FreeBSD normal, une panique du kernel créera une sauvegarde en appelant kern_reboot avec l'indicateur RB_DUMP. Cela conduit alors à l'appel de doadump, qui va déverser une quantité plutôt minime d'informations sur l'image du kernel elle-même sur un périphérique de stockage.
Sur la PlayStation 4, le remplacement de doadump est mdbg_run_dump, qui peut être appelé dès la panique ou directement depuis trap_fatal. La quantité d'informations stockées dans la sauvegarde est gigantesque - l'état du kernel pour tous les objets process, thread et vm sont inclus, ainsi que des métadonnées sur les bibliothèques chargées.
D'autres changements évidents de la méthode FreeBSD à la vanille sont que le mdbg_run_dump code les données enregistrées dans la sauvegarde, champ par champ, et crypte en plus le tampon résultant avant de le stocker sur le disque.
Dumper n'importe quoi
La Team fail0verflow explique qu'il est possible d'utiliser sur une partie spéciale de mdbg_run_dump où sont gérés tous les threads du processus et essaie de vider l'état de pthread.
dumpstate est un tampon temporaire qui finira par arriver dans le crashdump. Pour résumer, sysdump__internal_call_readuser peut être configuré pour fonctionner comme un oracle accessible en lecture. Ceci est dû au fait que fsbase pointera vers l'espace d'adresse usermode de notre processus webkit.
Ainsi, même sans changer la valeur fsbase réelle, nous pouvons changer librement la valeur de tcb_thread, qui est stockée à fsbase + 0x10.
De plus, sysdump__internal_call_readuser lira heureusement à partir d'une adresse de kernel et placera le résultat dans la sauvegarde.
Nous pouvons maintenant placer n'importe quel emplacement du kernel dans le dump, mais nous devons encore le déchiffrer et le décoder...
En dehors de cela, il y a aussi le problème que nous pouvons seulement ajouter 0x10 octets par thread de cette manière ...
La Team explique après ce que sont le Crypto Crashdump, Crashdump Décodage et le Crashdump Automation en disant que les clés sont les mêmes depuis le firmware 1.01, et que la limité de 0x10 octets n'a qu'une limite de 600 threads ! 600 threads en même temps avant que le processus du navigateur ne se bloque, ou refuse de faire plus de threads.
Avec une telle capacité, l'automatisation des processus est simplifiée, il est alors possible avec une modification matérielle de la commutation d'alimentation de la ps4 au réseau et simuler l'entrée de la ps4 avec l'API gadget usb de Linux, d'aller lire les processus.
Ces problèmes sécuritaires liés aux clés ont été corrigés avec le firmware 4.50, la méthode de génération des clés crashdumps a été modifiée par une reconnaissance d'une clé asymétrique afin de déchiffrer le contenu du dump.
Le processus reste long, juste pour dumper via cette méthode il faut pas moins de 6 jours, cette analyse est une nouvelle fois très intéressante, peut être un moyen de faire une nouvelle fois progresser les recherches sur des firmwares plus récent que le 4.05 par exemple.
Tout est là : ps4-crashdump-dump
