bazad/blanketCVE-2018-4280 : vulnérabilité de remplacement de port Mach dans launchd sur iOS 11.2.6 conduisant à une évasion du bac à sable, une escalade de privilèges et un contournement de la validation de code.
Blanket est une évasion de sandbox ciblant iOS 11.2.6, bien que la vulnérabilité principale n'ait été corrigée que dans iOS 11.4.1. Elle exploite une vulnérabilité de remplacement de port Mach dans launchd (CVE-2018-4280), ainsi que plusieurs vulnérabilités mineures dans d'autres services, pour exécuter du code dans le processus ReportCrash, qui n'est pas confiné dans un sandbox, s'exécute en tant que root et possède l'entitlement task_for_pid-allow. Cela donne à blanket le contrôle sur tous les processus en cours d'exécution sur le téléphone, y compris ceux critiques pour la sécurité comme amfid.
L'exploit se compose de plusieurs étapes. Ce README expliquera la vulnérabilité principale et les étapes de l'évasion de sandbox pas à pas.
En étudiant le signalement de crash sur iOS, j'ai découvert une vulnérabilité de remplacement de port Mach dans launchd. En crashent d'une manière particulière, un processus peut amener le noyau à envoyer un message Mach à launchd, ce qui pousse launchd à sur-désallouer un droit d'envoi vers un port Mach dans son espace de noms IPC. Cela permet à un attaquant d'usurper n'importe quel service launchd qu'il peut rechercher vis-à-vis du reste du système, ouvrant de nombreuses voies d'escalade de privilèges.
Cette vulnérabilité est également présente sur macOS, mais déclencher la vulnérabilité sur iOS est plus difficile en raison des vérifications dans launchd qui garantissent que le message d'exception Mach provient du noyau.
Launchd multiplexe plusieurs gestionnaires de messages Mach sur son port principal, y compris un gestionnaire MIG pour les messages d'exception. Si un processus envoie un message mach_exception_raise ou mach_exception_raise_state_identity à son propre port bootstrap, launchd recevra et traitera ce message comme une exception au niveau de l'hôte.
Malheureusement, la gestion de ces messages par launchd est buggée. Si le type d'exception est EXC_CRASH, alors launchd désallouera les ports thread et task envoyés dans le message, puis renverra KERN_FAILURE depuis la routine de service, ce qui amène le système MIG à désallouer à nouveau les ports thread et task. (L'hypothèse est que si une routine de service renvoie un succès, alors elle a pris possession de toutes les ressources du message Mach, tandis que si la routine de service renvoie une erreur, alors elle n'a pris possession d'aucune des ressources.)
Voici le code de la routine de service de launchd pour les messages mach_exception_raise, décompilé avec IDA/Hex-Rays et légèrement édité pour la lisibilité :```C
kern_return_t __fastcall
catch_mach_exception_raise( // (a) The service routine is
mach_port_t exception_port, // called with values directly
mach_port_t thread, // from the Mach message
mach_port_t task, // sent by the client. The
exception_type_t exception, // thread and task ports could
mach_exception_data_t code, // be arbitrary send rights.
mach_msg_type_number_t codeCnt)
{
__int64 __stack_guard; // ST28_8@1
kern_return_t kr; // w0@1 MAPDST
kern_return_t result; // w0@4
__int64 codes_left; // x25@6
mach_exception_data_type_t code_value; // t1@7
int pid; // [xsp+34h] [xbp-44Ch]@1
char codes_str[1024]; // [xsp+38h] [xbp-448h]@7
__stack_guard = *__stack_chk_guard_ptr;
pid = -1;
kr = pid_for_task(task, &pid);
if ( kr )
{
_os_assumes_log(kr);
_os_avoid_tail_call();
}
if ( current_audit_token.val[5] ) // (b) If the message was sent by
{ // a process with a nonzero PID
result = KERN_FAILURE; // (any non-kernel process),
} // the message is rejected.
else
{
if ( codeCnt )
{
codes_left = codeCnt;
do
{
code_value = *code;
++code;
__snprintf_chk(codes_str, 0x400uLL, 0, 0x400uLL, "0x%llx", code_value);
--codes_left;
}
while ( codes_left );
}
launchd_log_2(
0LL,
3LL,
"Host-level exception raised: pid = %d, thread = 0x%x, "
"exception type = 0x%x, codes = { %s }",
pid,
thread,
exception,
codes_str);
kr = deallocate_port(thread); // (c) The "thread" port sent in
if ( kr ) // the message is deallocated.
{
_os_assumes_log(kr);
_os_avoid_tail_call();
}
kr = deallocate_port(task); // (d) The "task" port sent in the
if ( kr ) // message is deallocated.
{
_os_assumes_log(kr);
_os_avoid_tail_call();
}
if ( exception == EXC_CRASH ) // (e) If the exception type is
result = KERN_FAILURE; // EXC_CRASH, then KERN_FAILURE
else // is returned. MIG will
result = 0; // deallocate the ports again.
}
*__stack_chk_guard_ptr;
return result;
}
Voici ce que fait le code :
1. Cette fonction est la routine de service Mach pour les messages d'exception `mach_exception_raise` : elle est invoquée directement par le système Mach lorsque launchd traite un message d'exception Mach `mach_exception_raise`. Les arguments de la routine de service sont extraits du message Mach et sont donc contrôlés par l'expéditeur du message.
2. En (b), launchd vérifie que le message d'exception Mach a été envoyé par le noyau. Le jeton d'audit de l'expéditeur contient le PID du processus émetteur dans le champ 5, qui ne sera nul que pour le noyau. Si le message n'a pas été envoyé par le noyau, il est rejeté.
3. Les ports thread et task du message sont explicitement désalloués en (c) et (d).
4. En (e), launchd vérifie si le type d'exception est `EXC_CRASH`, et renvoie `KERN_FAILURE` si c'est le cas. L'intention est de ne pas traiter les messages `EXC_CRASH`, probablement pour que ReportCrash soit invoqué en tant que gestionnaire de cadavres. Cependant, renvoyer `KERN_FAILURE` à ce stade entraînera une nouvelle désallocation des ports task et thread lors du nettoyage ultérieur du message d'exception. Cela signifie que ces deux ports seront sur-désalloués.