__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;

Ecco cosa fa il codice:

1. Questa funzione è la routine di servizio Mach per i messaggi di eccezione `mach_exception_raise`: viene invocata direttamente dal sistema Mach quando launchd elabora un messaggio di eccezione Mach `mach_exception_raise`. Gli argomenti della routine di servizio vengono parsificati dal messaggio Mach e quindi sono controllati dal mittente del messaggio.
2. In (b), launchd verifica che il messaggio di eccezione Mach sia stato inviato dal kernel. Il token di audit del mittente contiene il PID del processo mittente nel campo 5, che sarà zero solo per il kernel. Se il messaggio non è stato inviato dal kernel, viene respinto.
3. I port di thread e task del messaggio vengono esplicitamente deallocati in (c) e (d).
4. In (e), launchd controlla se il tipo di eccezione è `EXC_CRASH` e restituisce `KERN_FAILURE` in caso affermativo. L'intento è di non gestire i messaggi `EXC_CRASH`, presumibilmente in modo che ReportCrash venga invocato come gestore del corpse. Tuttavia, restituire `KERN_FAILURE` a questo punto causerà la deallocazione dei port di task e thread quando il messaggio di eccezione verrà pulito successivamente. Ciò significa che quei due port verranno sovra-deallocati.

Affinché questa vulnerabilità sia utile, vorremo liberare il diritto di invio di launchd verso un servizio Mach che esso fornisce, in modo da poter poi impersonare quel servizio per il resto del sistema. Ciò significa che avremo bisogno che i port di task e thread nel messaggio di eccezione siano effettivamente diritti di invio verso il port del servizio Mach che vogliamo liberare in launchd. Poi, una volta inviato a launchd il messaggio di eccezione malevolo e liberato il port del servizio, cercheremo di far riutilizzare lo stesso nome di port, ma questa volta per un port Mach di cui possediamo il diritto di ricezione. In questo modo, quando un client chiede a launchd di dargli un diritto di invio verso il port Mach per il servizio, launchd gli darà invece un diritto di invio verso il nostro port, permettendoci di impersonare quel servizio verso il client. Dopo di ciò, ci sono molte strade diverse per ottenere privilegi di sistema.

### Attivazione della vulnerabilità

Per attivare effettivamente la vulnerabilità, dovremo bypassare il controllo che il messaggio sia stato inviato dal kernel. Questo perché se inviamo il messaggio di eccezione direttamente a launchd, verrà semplicemente scartato. In qualche modo, dobbiamo far sì che il kernel invii un messaggio di eccezione "malevolo" contenente un diritto di invio Mach per un servizio di sistema al posto dei veri port di thread e task.

Si scopre che esiste un trap Mach, `task_set_special_port`, che può essere utilizzato per impostare un diritto di invio personalizzato da usare al posto del vero port del task in determinate situazioni. Una di queste situazioni è quando il kernel genera un messaggio di eccezione per conto di un task: invece di inserire il vero diritto di invio del task nel messaggio di eccezione, il kernel userà il diritto di invio fornito da `task_set_special_port`. Più specificamente, se un task chiama `task_set_special_port` per impostare un valore personalizzato per il suo port speciale `TASK_KERNEL_PORT` e poi il task crasha, il messaggio di eccezione generato dal kernel avrà un diritto di invio verso il port personalizzato, non il vero port del task, nel campo "task". Un'API equivalente, `thread_set_special_port`, può essere utilizzata per impostare un port personalizzato nel campo "thread" del messaggio di eccezione generato.

A causa di questo comportamento, in realtà non è affatto difficile far generare al kernel un messaggio di eccezione "malevolo" contenente un port di servizio Mach al posto del port di task e thread. Tuttavia, dobbiamo ancora assicurarci che il messaggio di eccezione che generiamo venga consegnato a launchd.

Ancora una volta, assicurarsi che il kernel consegni il messaggio di eccezione "malevolo" a launchd non è difficile se si conosce l'API giusta. La funzione `thread_set_exception_ports` imposterà qualsiasi diritto di invio Mach come port a cui vengono consegnati i messaggi di eccezione su questo thread. Quindi, tutto ciò che dobbiamo fare è invocare `thread_set_exception_ports` con il bootstrap port, e qualsiasi eccezione che genereremo farà sì che il kernel invii un messaggio di eccezione a launchd.

L'ultimo pezzo del puzzle è ottenere il giusto tipo di eccezione. La vulnerabilità verrà attivata solo per eccezioni `EXC_CRASH`. Un po' di tentativi ed errori rivela che possiamo facilmente generare eccezioni `EXC_CRASH` chiamando la funzione standard `abort`.

Quindi, in sintesi, possiamo utilizzare API esistenti e ben documentate per far generare al kernel un messaggio di eccezione `EXC_CRASH` malevolo per nostro conto e consegnarlo a launchd, attivando la vulnerabilità e liberando il port del servizio Mach:

1. Usa `thread_set_exception_ports` per impostare launchd come gestore delle eccezioni per questo thread.
2. Chiama `bootstrap_look_up` per ottenere da launchd il port del servizio che vogliamo impersonare.
3. Chiama `task_set_special_port`/`thread_set_special_port` per utilizzare quel port di servizio al posto dei veri port di task e thread nei messaggi di eccezione.
4. Chiama `abort`. Il kernel invierà un messaggio di eccezione `EXC_CRASH` a launchd, ma i port di task e thread nel messaggio saranno il port del servizio target.
5. Launchd elaborerà il messaggio di eccezione e libererà il port del servizio.

### Esecuzione del codice dopo il crash

C'è un problema con la strategia sopra: chiamare `abort` ucciderà il nostro processo. Se vogliamo essere in grado di eseguire codice dopo aver attivato la vulnerabilità, abbiamo bisogno di un modo per eseguire il crash in un altro processo.

(Con altri tipi di eccezione un processo potrebbe effettivamente riprendersi dall'eccezione. Il modo in cui un processo si riprende è impostare il suo gestore di eccezioni di thread su launchd e il suo gestore di eccezioni di task su se stesso. Dopo che launchd elabora e non riesce a gestire l'eccezione, il kernel invierebbe l'eccezione al gestore del task, che ripristinerebbe lo stato del thread e informerebbe il kernel che l'eccezione è stata gestita. Tuttavia, un processo non può catturare le proprie eccezioni `EXC_CRASH`, quindi abbiamo bisogno di due processi.)

Una strategia è sfruttare prima una vulnerabilità in un altro processo su iOS e forzare quel processo a impostare i suoi port del kernel e crashare. Tuttavia, per un proof-of-concept, è più semplice creare un'app extension.

Le app extension, introdotte in iOS 8, forniscono un modo per impacchettare alcune funzionalità di un'applicazione in modo che siano disponibili al di fuori dell'applicazione. Il codice di un'app extension viene eseguito in un processo separato e in sandbox. Questo rende molto facile lanciare un processo che imposterà i suoi port speciali, registrerà launchd come suo gestore di eccezioni per `EXC_CRASH`, e poi chiamerà `abort`.

Non esiste un modo supportato per un'app di lanciare programmaticamente la propria app extension e comunicare con essa. Tuttavia, Ian McDowell ha scritto un [ottimo articolo][Multi-Process iOS App Using NSExtension] che descrive come utilizzare l'API privata `NSExtension` per lanciare e comunicare con un processo di app extension. Ho utilizzato una strategia quasi identica qui. L'unica differenza è che abbiamo bisogno di comunicare un port Mach al processo dell'app extension, il che comporta la registrazione di un servizio fittizio con launchd a cui l'app extension si connette.

[Multi-Process iOS App Using NSExtension]: https://ianmcdowell.net/blog/nsextension/

### Prevenire il riutilizzo del port in launchd

Una sfida che noteresti se eseguisse l'exploit come descritto è che occasionalmente non saresti in grado di riacquisire il port liberato. Il motivo è che il kernel tiene traccia delle voci IPC libere di un processo in una freelist, quindi un nome di port appena liberato verrà riutilizzato (con un numero di generazione diverso) quando un nuovo port viene allocato nella tabella IPC. Quindi, riallocherai il nome di port che desideri solo se launchd non riutilizza prima quella voce di slot IPC per un altro port.

Il modo per aggirare questo problema è seppellire lo slot IPC libero in fondo alla freelist, in modo che se launchd alloca nuovi port, quegli altri slot vengano usati per primi. Come facciamo? Possiamo registrare un mucchio di servizi Mach fittizi in launchd con port di cui possediamo il diritto di ricezione. Quando chiamiamo `abort`, il gestore di eccezioni scatterà per primo, e poi lo stato del processo, inclusi i port Mach, verrà ripulito. Quando launchd riceve l'eccezione `EXC_CRASH`, libererà involontariamente il port del servizio target, posizionando lo slot IPC corrispondente a quel nome di port in cima alla freelist. Poi, quando il resto dei port Mach della nostra app extension vengono distrutti, launchd riceverà notifiche e libererà i port dei servizi fittizi, seppellendo lo slot IPC target dietro gli slot dei port appena liberati. Quindi, fintanto che launchd alloca meno port del numero di servizi fittizi che abbiamo registrato, lo slot target sarà ancora nella freelist, il che significa che possiamo ancora far sì che launchd riallochi lo slot con lo stesso nome di port del servizio originale.

Il limite di questa strategia è che abbiamo bisogno dell'entitlement `com.apple.security.application-groups` per registrare servizi con launchd. Ci sono altri modi per nascondere port Mach in launchd, ma usare i gruppi di applicazioni è sicuramente il più semplice, e sufficiente per questo proof-of-concept.

### Impersonare il servizio liberato

Una volta che abbiamo generato l'app extension crashante e liberato un diritto di invio Mach in launchd, dobbiamo riallocare quel nome di port Mach con un diritto di invio di cui possediamo il diritto di ricezione. In questo modo, tutti i messaggi che launchd invia a quel nome di port verranno ricevuti da noi, e ogni volta che launchd condivide quel nome di port con un client, il client riceverà un diritto di invio verso il nostro port. In particolare, se riusciamo a liberare il diritto di invio di launchd verso un servizio Mach, allora qualsiasi processo che richiede quel servizio da launchd riceverà un diritto di invio verso il nostro port invece del vero port del servizio. Questo ci permette di impersonare il servizio o di effettuare un attacco man-in-the-middle, ispezionando tutti i messaggi che il client invia al servizio.

Ottenere il riutilizzo del nome di port liberato in modo che si riferisca a un port di nostra proprietà è anche abbastanza semplice, dato che abbiamo già deciso di utilizzare l'entitlement dei gruppi di applicazioni: basta registrare servizi Mach fittizi con launchd finché uno di essi non riutilizza il nome di port originale. Dovremo farlo in lotti, registrando un gran numero di servizi fittizi insieme, controllando se qualcuno ha riutilizzato con successo il nome di port liberato, e poi deregistrandoli. Il motivo è che dobbiamo essere sicuri che le nostre registrazioni vadano fino in fondo nella freelist dei port IPC per recuperare il nome di port sepolto che vogliamo.

Possiamo verificare se siamo riusciti a riutilizzare con successo il nome di port liberato cercando il servizio originale con `bootstrap_look_up`: se restituisce uno dei nostri port di servizio registrati, abbiamo finito.

Una volta che siamo riusciti a registrare un nuovo servizio che ottiene lo stesso nome di port dell'originale, qualsiasi client che cerca il servizio originale in launchd riceverà un diritto di invio verso il nostro port, non il vero port del servizio. Quindi, stiamo effettivamente impersonando il servizio originale per il resto del sistema (o almeno per quei processi che cercano il servizio dopo il nostro attacco).

Fase 1: Ottenere il port host-priv
---------------------------------------------------------------------------------------------------

Una volta che abbiamo la capacità di impersonare servizi di sistema arbitrari, il passo successivo è ottenere il port host-priv. Questo passaggio è semplice e non è influenzato dalle modifiche in iOS 11.3. L'idea generale di questo attacco è impersonare SafetyNet, crashare ReportCrash, e poi recuperare il port host-priv dal port del task di ReportCrash morente inviato nel messaggio di eccezione.

### Informazioni su ReportCrash e SafetyNet

ReportCrash è responsabile della generazione dei rapporti di crash su iOS. Questo singolo binario fornisce in realtà 4 servizi diversi (ciascuno in un processo diverso, anche se potrebbero non essere tutti in esecuzione in un dato momento):

1. `com.apple.ReportCrash` è responsabile della generazione di rapporti di crash per i processi che crashano. È il gestore di eccezioni a livello di host per le eccezioni `EXC_CRASH`, `EXC_GUARD` e `EXC_RESOURCE`.
2. `com.apple.ReportCrash.Jetsam` gestisce i rapporti Jetsam.
3. `com.apple.ReportCrash.SimulateCrash` crea rapporti per crash simulati.
4. `com.apple.ReportCrash.SafetyNet` è il gestore di eccezioni registrato per il servizio `com.apple.ReportCrash`.

Quelli di nostro interesse sono `com.apple.ReportCrash` e `com.apple.ReportCrash.SafetyNet`, d'ora in poi denominati semplicemente ReportCrash e SafetyNet. Entrambi sono servizi basati su MIG e eseguono essenzialmente lo stesso codice.

Quando ReportCrash si avvia, cerca il servizio SafetyNet in launchd e imposta il port restituito come gestore di eccezioni a livello di task. L'intento sembra essere che se ReportCrash stesso dovesse crashare, un processo separato genererebbe il rapporto di crash per esso. Tuttavia, questo percorso di codice sembra inutilizzato: ReportCrash registra SafetyNet per i messaggi `mach_exception_raise`, nonostante sia ReportCrash che SafetyNet gestiscano solo messaggi `mach_exception_raise_state_identity`. Ciononostante, entrambi i servizi sono ancora presenti e raggiungibili dall'interno del container sandbox di iOS.

### Primitiva di manipolazione di ReportCrash

Per eseguire l'attacco seguente, dobbiamo essere in grado di manipolare ReportCrash (o SafetyNet) per comportarsi come vogliamo. Nello specifico, abbiamo bisogno delle seguenti capacità: avviare ReportCrash su richiesta, forzare ReportCrash a uscire, crashare ReportCrash e assicurarci che ReportCrash non esca mentre lo stiamo usando. Qui descriverò come raggiungiamo ciascun obiettivo.

Per avviare ReportCrash, dobbiamo semplicemente inviargli un messaggio Mach: launchd lo avvierà su richiesta. Tuttavia, a causa del suo design peculiare, qualsiasi tipo di messaggio tranne `mach_exception_raise_state_identity` farà sì che ReportCrash smetta di rispondere a nuovi messaggi e alla fine esca. Quindi, dobbiamo inviare un messaggio `mach_exception_raise_state_identity` se vogliamo che rimanga vivo in seguito.

Per far uscire ReportCrash, possiamo semplicemente inviargli qualsiasi altro tipo di messaggio Mach.

Ci sono molti modi per crashare ReportCrash. Il più semplice è probabilmente inviare un messaggio `mach_exception_raise_state_identity` con il port del thread impostato a `MACH_PORT_NULL`.

Infine, dobbiamo assicurarci che ReportCrash non esca mentre lo stiamo usando. Ogni messaggio `mach_exception_raise_state_identity` che elabora fa sì che generi un altro thread per ascoltare il prossimo messaggio mentre il thread originale genera il rapporto di crash. ReportCrash uscirà una volta che tutti i thread in sospeso che generano un rapporto di crash saranno terminati. Quindi, se riusciamo a bloccare uno di quei thread mentre è nel processo di generazione di un rapporto di crash, possiamo impedirgli di uscire.

Il modo più semplice che ho trovato per farlo è stato inviare un messaggio `mach_exception_raise_state_identity` con un port personalizzato nei campi del task e del thread. Una volta che ReportCrash tenta di generare un rapporto di crash, chiamerà `task_policy_get` sul port "task", il che gli farà inviare un messaggio Mach al port che abbiamo inviato e attendere una risposta. Ma poiché il port "task" è solo un normale vecchio port Mach, possiamo semplicemente non rispondere al messaggio Mach, e ReportCrash attenderà indefinitamente che `task_policy_get` ritorni.

### Estrazione di host-priv da ReportCrash

Per la prima fase dell'exploit, il piano di attacco è relativamente semplice:

1. Avvia il servizio SafetyNet e forzalo a rimanere attivo per la durata del nostro attacco.
2. Usa la primitiva di impersonificazione del servizio launchd per impersonare SafetyNet. Questo ci dà un nuovo port su cui possiamo ricevere messaggi destinati al vero servizio SafetyNet.
3. Fai uscire qualsiasi istanza esistente di ReportCrash. In questo modo, possiamo assicurarci che ReportCrash cerchi il nostro port SafetyNet nel passaggio successivo.
4. Avvia ReportCrash. ReportCrash cercherà SafetyNet in launchd e imposterà il port risultante, che è il falso port SafetyNet di cui possediamo il diritto di ricezione, come destinazione per i messaggi `EXC_CRASH`.
5. Innesca un crash in ReportCrash. Dopo aver constatato che non ci sono gestori registrati per il tipo di eccezione originale, ReportCrash entrerà nella fase di morte del processo. A questo punto XNU vedrà che ReportCrash ha registrato il falso port SafetyNet per ricevere eccezioni `EXC_CRASH`, quindi genererà un messaggio di eccezione e lo invierà a quel port.
6. Quindi ascoltiamo sul falso port SafetyNet per il messaggio `EXC_CRASH`. Sarà di tipo `mach_exception_raise`, il che significa che conterrà il port del task di ReportCrash.
7. Infine, usiamo `task_get_special_port` sul port del task di ReportCrash per ottenere il port host di ReportCrash. Poiché ReportCrash è senza sandbox e viene eseguito come root, questo è il port host-priv.

Alla fine di questa fase dell'escape dalla sandbox, otteniamo un port host-priv utilizzabile. Questo da solo dimostra che si tratta di un grave problema di sicurezza.

Fase 2: Uscire dalla sandbox
---------------------------------------------------------------------------------------------------

Anche se abbiamo il port host-priv, il nostro obiettivo è uscire completamente dalla sandbox ed eseguire codice come root con l'entitlement `task_for_pid-allow`. Il primo passo per raggiungerlo è semplicemente uscire dalla sandbox.

Tecnicamente parlando, non c'è motivo di dover ottenere il port host-priv prima di uscire dalla sandbox: questi due passaggi sono indipendenti e possono avvenire in qualsiasi ordine. Tuttavia, questa fase lascerà il sistema instabile se essa o le fasi successive falliscono, quindi vale la pena metterla dopo.

L'attacco generale è utilizzare di nuovo la stessa vulnerabilità di launchd per impersonare un servizio di sistema. Tuttavia, questa volta il nostro obiettivo è impersonare un servizio a cui un client invierà il suo port del task in un messaggio Mach. È facile scoprire per esperimento su iOS 11.2.6 che se impersoniamo `com.apple.CARenderServer` (d'ora in poi CARenderServer) ospitato da backboardd e poi comunichiamo con `com.apple.DragUI.druid.source`, il demone druid senza sandbox invierà il suo port del task in un messaggio Mach al falso port del servizio.

Questo passaggio dell'exploit è rotto su iOS 11.3 perché druid non invia più il suo port del task nel messaggio Mach a CARenderServer. Nonostante ciò, sono fiducioso che questa vulnerabilità possa ancora essere utilizzata per uscire dalla sandbox. Un modo per affrontare questo problema è cercare servizi senza sandbox che si fidano dell'input di altri servizi. Questi tipi di "vulnerabilità" non sarebbero mai sfruttabili senza la capacità di sostituire i servizi di sistema, il che significa che sono probabilmente una superficie di attacco a bassa priorità, sia internamente che esternamente ad Apple.

### Crash di druid

Proprio come con ReportCrash, abbiamo bisogno di essere in grado di forzare il riavvio di druid nel caso sia già in esecuzione in modo che cerchi il nostro falso port CARenderServer in launchd. Ho deciso di utilizzare un bug in libxpc che era già programmato per essere risolto per questo scopo.

Esaminando libxpc, ho trovato una lettura out-of-bounds che potrebbe essere utilizzata per forzare il crash di qualsiasi servizio XPC:```C
void _xpc_dictionary_apply_wire_f
(
        OS_xpc_dictionary *xdict,
        OS_xpc_serializer *xserializer,
        const void *context,
        bool (*applier_fn)(const char *, OS_xpc_serializer *, const void *)
)
{
...
    uint64_t count = (unsigned int)*serialized_dict_count;
    if ( count )
    {
        uint64_t depth = xserializer->depth;
        uint64_t index = 0;
        do
        {
            const char *key = _xpc_serializer_read(xserializer, 0, 0, 0);
            size_t keylen = strlen(key);
            _xpc_serializer_advance(xserializer, keylen + 1);
            if ( !applier_fn(key, xserializer, context) )
                break;
            xserializer->depth = depth;
            ++index;
        }
        while ( index < count );
    }
...
}

if (caller == victim) {
	return KERN_SUCCESS;
}

/*
 * Only the kernel can can resolve the kernel's task port. We've established
 * by this point that the caller is not kernel_task.
 */
if (victim == kernel_task) {
	return KERN_INVALID_SECURITY;
}

return KERN_SUCCESS;

Le routine di conversione MIG che si basano su queste funzioni, incluse `convert_port_to_task` e
`convert_port_to_map`, falliranno quindi quando le chiameremo sul task di druid. Ad esempio,
`mach_vm_write` non ci permetterà di manipolare la memoria di druid.

Tuttavia, guardando il file MIG `osfmk/mach/task.defs` in XNU, ho notato qualcosa
di interessante:```C
/*
 *	Returns the set of threads belonging to the target task.
 */
routine task_threads(
		target_task	: task_inspect_t;
	out	act_list	: thread_act_array_t);

Di particolare interesse per gli sviluppatori di jailbreak è il parametro `is_apple`. Questo parametro non sembra essere utilizzato da amfid, ma se impostato, farà sì che il kernel imposti il flag di codesigning `CS_PLATFORM_BINARY`, che concede all'applicazione privilegi di binary di piattaforma. In particolare, ciò significa che l'applicazione può ora utilizzare i task port per modificare direttamente i binary di piattaforma.


Scappatoie utilizzate in questo attacco
---------------------------------------------------------------------------------------------------

Questo attacco sfrutta diverse scappatoie che non sono esse stesse vulnerabilità di sicurezza, ma riducono l'efficacia di varie mitigazioni degli exploit. Non tutte devono essere chiuse insieme, poiché alcune sono parzialmente ridondanti, ma vale comunque la pena elencarle tutte.

Nel kernel:

1. `task_threads` può promuovere un `task_inspect_t` di sola ispezione a un `thread_act_t` in grado di modificare.
2. Non esiste un `thread_conversion_eval` che svolga il ruolo di `task_conversion_eval` per i thread.
3. Un binary non di piattaforma può utilizzare un diritto `task_inspect_t` per un binary di piattaforma.
4. I messaggi di eccezione per processi non sandboxati possono essere inviati a processi sandboxati, anche se ciò fornisce un modo per uscire dalla sandbox. Non è chiaro se esista una soluzione pulita per questa scappatoia.
5. L'esecuzione di codice non sandboxato, il port host-priv e la capacità di far crashare un processo `task_for_pid-allow` possono essere combinati per creare un workaround per `task_for_pid`. (Il workaround è: chiamare `host_set_exception_ports` per impostare un nuovo gestore di eccezioni a livello di host, quindi far crashare il processo `task_for_pid-allow` per ricevere il suo task port ed eseguire codice con l'entitlement.)

Nelle estensioni delle app:

1. Le estensioni delle app che condividono un gruppo di applicazioni possono comunicare utilizzando messaggi Mach, nonostante la documentazione suggerisca che la comunicazione tra l'app host e l'estensione dell'app dovrebbe essere impossibile.


Correzioni e mitigazioni consigliate
---------------------------------------------------------------------------------------------------

Raccomando le seguenti correzioni, approssimativamente in ordine di importanza:

1. Deallocare i port Mach nelle routine di servizio di launchd solo quando si restituisce `KERN_SUCCESS`. Questo risolverà la vulnerabilità di sostituzione del port Mach.
2. Chiudere la scappatoia di `task_threads` che permette a un binary non di piattaforma di utilizzare il task port di un binary di piattaforma per ottenere l'esecuzione di codice.
3. Risolvere i problemi di crash in ReportCrash.
4. L'insieme dei servizi Mach raggiungibili dall'interno della sandbox del container dovrebbe essere minimizzato. Non vedo un motivo legittimo per cui la maggior parte delle app iOS debba comunicare con ReportCrash o SafetyNet.
5. Il maggior numero possibile di processi dovrebbe essere sandboxato. Non sono sicuro se druid debba essere non sandboxato per funzionare correttamente, ma in caso contrario, dovrebbe essere posto in una sandbox appropriata.
6. Il codice morto dovrebbe essere eliminato. SafetyNet non sembra svolgere la sua funzionalità prevista. Se non è più necessario, dovrebbe probabilmente essere rimosso.
7. Chiudere il workaround per `task_for_pid` basato su `host_set_exception_ports`. Ad esempio, valutare se vale la pena limitare `host_set_exception_ports` a root o limitare l'usabilità del port host-priv in alcune configurazioni. Questo viola l'elegante design basato sulle capabilities di Mach, ma `host_set_exception_ports` potrebbe essere un bersaglio promettente per abusi.
8. Valutare se vale la pena aggiungere `task_conversion_eval` a `task_inspect_t`.


Esecuzione di blanket
---------------------------------------------------------------------------------------------------

Blanket dovrebbe funzionare su qualsiasi dispositivo con iOS 11.2.6.

1. Scarica il progetto:   ```
   git clone https://github.com/bazad/blanket
   cd blanket