Diamo un'occhiata alla funzione prima della patch (ho cercato di etichettare le righe pertinenti):

• Il ciclo in [1] conta il numero di IOHIDElementValue nel buffer e memorizza questo conteggio in cookieCount.
• Il controllo in [2] (combinato con la condizione del ciclo while) si assicurerà che il campo length di ogni intestazione non si estenda oltre i limiti del buffer elementData (né possa essere inferiore alla fine del buffer, anche se questo è meno rilevante).
• Una volta che tutti gli elementi sono stati contati e verificati da questo ciclo, un buffer cookies viene allocato nell'heap in [3] con una dimensione di cookieCount * 4 (oppure viene usato un buffer nello stack se cookieCount è sufficientemente piccolo).
• Un secondo ciclo in [4] effettua quindi una seconda scansione del buffer, analizzando nuovamente gli IOHIDElementValue.
• Gli oggetti OSData vengono creati per contenere il valore di ogni elemento in [5], utilizzando il campo length che è stato validato nel primo ciclo.
• In [6], il cookie di ogni elemento viene scritto nell'array cookies allocato in [3].

Qual è il problema? Questa funzione si comporta correttamente quando elementData è non volatile; il problema si presenta quando il metodo viene chiamato con memoria condivisa. Entra in gioco il metodo IOHIDInterface::SetElementValues_Impl di DriverKit:

Qui, postElementTransaction viene chiamato con md->getBytesNoCopy(), memoria condivisa con lo spazio utente, violando l'assunzione che elementData sia non volatile. Il contenuto del buffer elementData può cambiare dopo il ciclo in [1], ma prima del ciclo in [4], quindi cosa significa questo per un attaccante?

Ci sono due modi in cui un attaccante può abusarne:

• Il primo è scambiare la length di un piccolo IOHIDElementValueHeader alla fine del buffer con un valore molto più grande. Ciò significa che quando l'OSData in [5] viene creato, si estenderà ben oltre i limiti del buffer elementData, consentendo a un attaccante di leggere dati fuori dai limiti usando IOHIDInterface::GetElementValues_Impl.
• Il secondo è scambiare la length di un grande IOHIDElementValueHeader all'inizio del buffer con un valore molto più piccolo. Ciò farà sì che il ciclo in [4] analizzi molte più intestazioni di quelle originariamente contate nel ciclo in [1], quindi quando i cookie vengono scritti nell'array cookies in [6], questi traboccheranno dall'array poiché index non viene mai validato rispetto a cookieCount.

In pratica, ciò consente a un attaccante di leggere dati fuori dai limiti dell'heap del kernel di dimensione arbitraria e di scrivere dati arbitrari (ancora di dimensione arbitraria) fuori dai limiti nell'heap del kernel. Si tratta di due primitive potenti.

Vincere la race condition

Con le race condition, cerchiamo sempre modi per determinare se la race è stata vinta con successo, in modo da poter continuare a provare fino a riuscirci, rendendo il nostro trigger deterministico. Fortunatamente, nel caso di questa race condition, possiamo farlo esattamente.

Per la variante di lettura OOB, posiziono un altro IOHIDElementValueHeader dopo l'intestazione di cui sto cambiando la length, con il suo value impostato sulla costante riconoscibile 0xD1AB011CAC1DF00D. Quindi, quando leggo il valore dell'elemento, so di aver vinto la race se vedo l'intestazione familiare 0xD1AB011CAC1DF00D all'inizio dei dati restituiti.

Per la variante di scrittura OOB, posiziono un IOHIDElementValueHeader dopo l'intestazione di cui sto cambiando la length, ma prima delle intestazioni i cui cookie saranno sovrascritti, questa volta con il value riconoscibile 0xD15EA5ED. Questa intestazione sarà incapsulata all'interno del value dell'elemento più grande nel caso in cui non vinciamo la race, quindi l'intestazione verrà analizzata e il valore dell'elemento verrà impostato su 0xD15EA5ED solo se vinciamo la race. Leggendo il valore dell'elemento, so se ho avuto successo.

La correzione di Apple

Per risolvere il problema, Apple ha scelto di aggiungere un terzo ciclo tra il ciclo [1] e il ciclo [4], validando ogni campo length e poi memorizzandolo in un nuovo array dataLengths, assicurando al contempo che il numero di elementi non fosse cambiato. Il ciclo finale utilizza quindi le lunghezze memorizzate nella cache per i suoi calcoli, evitando di leggere dal buffer un'altra volta.

Problemi con l'exploitation

L'ostacolo principale da superare nello sfruttamento di questo problema è che il buffer da cui stiamo traboccando appartiene a KHEAP_DATA_BUFFERS, quindi gli obiettivi di sfruttamento sono limitati. In questa proof-of-concept ho scelto di prendere di mira le intestazioni kmsg, poiché sono una delle poche strutture in KHEAP_DATA_BUFFERS che contengono puntatori al kernel. La primitiva "arbitrary kfree" che ho ottenuto usando questo approccio è la stessa primitiva usata nell'exploit multicast_bytecopy, tuttavia l'array IOSurfaceClient è ora protetto da PAC e i client contraffatti devono avere un puntatore valido all'IOSurfaceRootUserClient che li ha creati, rendendo questo non più un bersaglio desiderabile per lettura/scrittura del kernel.

Compilazione e installazione

Apple non ha reso molto semplice la compilazione e l'installazione di estensioni DriverKit personalizzate, specialmente senza un account sviluppatore Apple a pagamento, ma è possibile.

Prima di iniziare, raccomando:

• Disabilitare SIP
• Impostare i boot-args amfi_get_out_of_my_way=1 cs_enforcement_disable=1
• Eseguire systemextensionsctl developer on
• Riavviare il computer

Dopo di che, dovresti essere in grado di selezionare il tuo team di sviluppo nelle impostazioni del progetto Xcode e il progetto verrà compilato con successo. Puoi quindi eseguire HIDDriverLoader, usare "Install Dext" per installare l'estensione DriverKit e "Trigger Exploit" per, hai indovinato, attivare l'exploit.

Se questo fallisce, puoi anche provare a compilare senza firmare usando:

E poi firmare manualmente usando:

Sostituendo self-sign-cert con il nome di un certificato auto-firmato nel tuo portachiavi.

Grazie per aver letto :)