L'exploit utilizza una combinazione di tre vulnerabilità. Ogni vulnerabilità è un bug in un componente iOS che consente all'aggressore di fare cose che non dovrebbero essere possibili.
Lo stage 1 ( CVE-2016-4657 ) è un bug in WebKit , una libreria di codice utilizzata per il rendering di pagine Web. Il codice WebKit viene eseguito nel contesto del browser web Safari di iOS. Nessun dettaglio è stato ancora rilasciato, solo la descrizione come "problema di corruzione della memoria è stata affrontata attraverso una migliore gestione della memoria". Potrebbe trattarsi di un overflow del buffer , un use-after-free , o qualche altro tipo di bug simile. L'idea generale dei bug di corruzione della memoria è che l'utente malintenzionato trasmetta dati inconsistenti (qui, alcuni contenuti di pagine Web - potrebbe essere HTML, CSS, JavaScript, ecc.) E invece di rilevare l'incoerenza il programma si comporta in modo incoerente e finisce per sovrascrivere alcune delle sue istruzioni con i dati forniti dall'attaccante. Ciò consente all'autore dell'attacco di eseguire il codice di propria scelta in Safari.
Lo stage 3 ( CVE-2016-4656 ) è anch'esso un bug di corruzione della memoria su cui non sono stati rilasciati dettagli, ma questa volta nel kernel. Questo bug permette a un'applicazione iOS di corrompere alcune strutture dati nel kernel e di eseguire codice nel kernel o (presumo che abbia la descrizione) almeno elevare i privilegi dell'applicazione chiamante in modo che possa fare cose che le applicazioni non dovrebbero fare, come installare programmi che ignorano le normali autorizzazioni iOS e quindi consentire ad es installazione di spyware che non verranno mostrati nell'elenco delle applicazioni installate perché si mascherano come parte del sistema operativo di base.
Lo stage 2 ( CVE-2016-4655 ) è un abilitatore per lo stage 3. Normalmente non dovrebbe importare che il programma sappia come il kernel mappa la sua memoria. E se l'attaccante è in grado di far eseguire al kernel codice arbitrario, il gioco viene perso. Ma può succedere (e questo è probabilmente il caso qui) che l'attaccante non abbia molto spazio in cui giocare. Per esempio, forse c'è un controllo delle dimensioni che è presente ma leggermente fuori, quindi l'attaccante è in grado di sovrascrivere solo pochi byte dopo il luogo in cui si trovano i dati iniettati. In questi casi, l'utente malintenzionato potrebbe aver bisogno di sapere esattamente cosa mettere in quella posizione, altrimenti non sarà in grado di causare effetti interessanti. Se il percorso che possono sovrascrivere è un puntatore, devono sapere cosa mettere lì per far sì che il kernel usi dati validi ma sbagliati, piuttosto che un puntatore non valido che causerebbe solo un arresto anomalo. Ad esempio, modificare un puntatore a un elenco di funzionalità all'indirizzo di un luogo in memoria che è noto per contenere ciò che sembra un elenco contenente alcune funzionalità di sistema chiave. Per questo, sapere dove il kernel mappa i suoi dati permette all'aggressore di calcolare il giusto valore del puntatore.
Per essere chiari, sto solo dando esempi di metodi di attacco plausibili che si adattano alle descrizioni di una linea che sono state rilasciate in questo momento.
Il modo migliore per avere un'idea di come funziona è scrivere da sé qualche exploit. Ottieni alcune vecchie versioni del software (preferibilmente open-source) con vulnerabilità sfruttabili conosciute , e vai e scrivi un exploit. Potresti anche voler riprodurre alcuni CTF .