Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/st-rnd/desc_race-1
Sicurezza iOSAnalisi delle VulnerabilitàExploitSicurezza MobileBinary Exploitation
GitHubst-rnd/desc_race-1

desc_race-1

desc_race exploit per iOS 15.0 - 15.1.1 (con primitive stabili di lettura/scrittura del kernel) (CVE-2021-30955)

Vedi Repository
24 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

desc_race

Exploit "desc_race" (CVE-2021-30955) per iOS 15.0 - 15.1.1 (con primitive stabili di lettura/scrittura del kernel)

Metodo di Exploit

  1. Aumenta la capacità dell'array IOSurfaceClient a 0x2000, l'obiettivo è scrivere un puntatore il cui contenuto sia totalmente controllato e poi usare le interfacce IOSurfaceRootUserClient per ottenere lettura/scrittura del kernel. La dimensione dell'array è 0x2000 * 8 byte quindi risiede nella mappa grande di KHEAP_KEXT, che è la stessa di KHEAP_DEFAULT.

  2. Poi alloca un buffer del kernel di 0x4000 byte usando un kmsg assistente con un descrittore ool di 0x4000 byte che verrà sovrascritto dal retro. E poi innesca il bug con il messaggio allocato, chiamato kmsg a doppio copyin, posizionato subito dietro il buffer del kernel assistente. E questo messaggio contiene un descrittore di porte ool il cui conteggio è 0x2000 quindi sarà piuttosto vicino all'array IOSurfaceClient.

  3. Poi dovresti ricevere il messaggio assistente. Se la race ha successo, il descrittore di porte ool verrà divulgato e potremmo individuare l'indirizzo dell'array IOSurfaceClient.

  4. Poi alloca di nuovo un buffer del kernel di 0x4000 byte, questo occuperà il suddetto buffer del kernel. Questa volta costruisco un falso header kmsg con un body appropriato. Poi distruggo il kmsg a doppio copyin, il kernel inizierà con il nostro falso header. Uso un falso mach_msg_ool_descriotpor_t e innesco

vm_copy_discard() con una copia totalmente controllata. Durante la distruzione della copia, le righe più preziose sono in _vm_map_entry_unlink_ll:

root@kitploit:~
1
2
3
4
5
6
#define _vm_map_entry_unlink_ll(hdr, entry)                             \
	MACRO_BEGIN                                                     \
	(hdr)->nentries--;                                              \
	(entry)->vme_next->vme_prev = (entry)->vme_prev;                \
	(entry)->vme_prev->vme_next = (entry)->vme_next;                \
	MACRO_END

L'entry è sotto il nostro controllo, questo ci offre una perfetta primitiva di lettura/scrittura. La uso per scrivere un puntatore controllato nell'array IOSurfaceClient, e poi ottengo lettura/scrittura del kernel combinata con le interfacce IOSurfaceRootUserClient.

Ho letto il post di bazad "One byte to rule them all" più e più volte durante lo sviluppo di questo exploit, e ho usato la stessa tecnica, la falsificazione di vm_copy_t, nel suo exploit. Ma ci sono alcuni punti che differiscono.

  1. XNU firma il messaggio e non possiamo più ricevere un kmsg corrotto.

  2. Nella procedura di distruzione, imposto mapping_in_progress di vm_object per far girare il kernel in loop così non andrà in panic a causa del controllo della zona.

Un grande ringraziamento a bazad per il suo ottimo post, e a WangTielei per avermi fatto sapere che le interfacce IOSurfaceClient ora non sono valide per la primitiva di lettura/scrittura, e a pedantcoder per la sua gentilezza.

Scarica lo strumento