[PS4] Les explications de CTurt sur son exploit kernel

Malgré le départ tragique de CTurt, tout espoir n'est pas encore perdu pour la scène du hack PS4. En effet, le développeur a partagé récemment des explications très détaillées de ses recherches sur le noyau de la console et sur son fameux exploit kernel pour firmwarae 1.76. Voilà les bases qu'il faut connaître avant d'aller lire les (longs) billets de notre cher camarade.

L'exploit kernel se repose en fait sur un accès au compilateur JIT (Just-in-time) pour exécuter du code via WebKit, puis utilise la vulnérabilité BadIRET (Linux)/FreeBSD afin de parvenir à ses fins : se frayer un passage vers le noyau. C'est un très court résumé de tout le processus bien plus complexe, qui implique en réalité des tas de manipulations issus de votre boîte à outils créée via rétro-ingénierie, incluant par exemple une corruption des pointeurs du kernel ou une luge sans opérations (plus communément appelée NOP sled).

Pour en revenir au compilateur JIT : il est utilisé par le noyau javascript de WebKit et c'est lui qui permet de compiler dynamiquement du code en javascript, par soucis de performance contrairement aux interpréteurs tels que le portage de l'émulateur GBA Cinoop sur PS4, que CTurt avait montré en septembre dernier. Pour ce faire, il faut donc une zone de mémoire à la fois accessible et écriture et en exécution.

Sony s'est chargé de cela en créant 2 fonctions d'appel système : sys_jitshm_create et sys_jitshm_alias. Il est possible de les utiliser directement, ou bien d'utiliser les enveloppes dans le libkernel (sceKernelJitCreateSharedMemory et al.). Pour identifier exactement la manière dont sont utilisées ces fonctions, il faudra charger, dumper et reverser le libSceJitBridge.sprx.

L'idée de base, c'est qu'il n'y a aucun moyen de cartographier directement une page virtuelle RWX (droits de lecture, écriture et exécution). Au lieu de faire cela, on va donc avoir besoin d'allouer de la mémoire et de créer un alias de cette cartographie. On va cartographier le premier handle comme un RX (droits de lecture et exécution), et l'alias comme un RW (droits de lecture et d'écriture). Résultat : on aura deux applications virtuelles séparées qui pointeront vers la même mémoire physique.

Le code peut maintenant être écrit par le biais du RW cartographié et exécuté à partir du RX cartographié de cette façon :

unsigned char loop[] = { 0xeb, 0xfe };
memcpy(writableAddress, loop, sizeof(loop));
((void (*)())executableAddress)();

La chaîne ROP liée à la mémoire de configuration (setup memory), copie le Wi-Fi Loader, et l'exécute. Vu que c'est un peu trop long pour être fait en une seule étape, on doit donc stocker l'étape dans un cookie, et recharger la page après chaque étape pour démarrer la suivante :

var codeExecutionStage = getCookie("codeExecutionStage");
if(codeExecutionStage == "1") {
	allocateSharedMemory();
	document.getElementById("codeExecutionStage").innerHTML = "Stage: Mapping shared memory...";
	setTimeout(function() { document.cookie = "codeExecutionStage=2"; location.reload(); }, 10);
}
else if(codeExecutionStage == "2") {
	mapSharedMemory();
	document.getElementById("codeExecutionStage").innerHTML = "Stage: Waiting for payload...";
	setTimeout(function() { document.cookie = "codeExecutionStage=3"; location.reload(); }, 10);
}
else if(codeExecutionStage == "3") {
	payload();
	document.getElementById("codeExecutionStage").innerHTML = "Stage: Executing...";
	setTimeout(function() { document.cookie = "codeExecutionStage=4"; location.reload(); }, 10);
}
else if(codeExecutionStage == "4") {
	copy();
	document.getElementById("codeExecutionStage").innerHTML = "Stage: Done!";
	setTimeout(function() { document.cookie = "codeExecutionStage=0"; location.reload(); }, 10);
}

Vu qu'on utilise simplement les appels système JIT vers leur destination définie, il s'agit davantage d'une astuce que d'un exploit. Malheureusement, très peu d'applications ont accès à ce fameux compilateur, Sony ayant ajouté des contrôles de privilèges dans le kernel. Ainsi, seuls les processus qui passent ces contrôles peuvent y avoir accès. Tant que l'on ne trouvera pas d'autre façon d'exécuter du code non-signé, nos exploits via des jeux ou des applis web resteront cantonnés au ROP...