faizan-khanx/cve-2024-38063CVE-2024-38063 - Sfruttamento remoto del kernel tramite IPv6
C'era esattamente una modifica in tutto il file del driver, che a quanto pare era effettivamente il bug.
Una panoramica bindiff di tcpip.sys prima e dopo l'installazione della patch.
È stata modificata una sola funzione nell'intero driver. Di solito potrei passare un'intera giornata a esaminare oltre 20 modifiche di funzioni diverse solo per capire quale sia quella giusta, ma non questa volta.
Ipv6pProcessOptions() prima della patch.
Ipv6pProcessOptions() . Dopo la patch.
Non è stata cambiata solo una singola funzione, ma una singola riga di codice.
La funzione dal nome estremamente lungo Feature_2660322619__private_IsEnabledDeviceUsage_3() è qualcosa che Microsoft a volte aggiunge per consentire rollback parziali delle patch. La chiamata verifica la presenza di un flag globale o di un'impostazione di registro che, se impostata, fa sì che la funzione restituisca false, con il risultato che viene eseguito il codice originale invece della versione patchata.
Il motivo per cui Microsoft fa questo è che le patch di sicurezza a volte rompono accidentalmente delle cose, quindi questa impostazione consente a un amministratore di annullare la patch di una singola vulnerabilità, senza disinstallare l'intero pacchetto di aggiornamento mensile e indebolire drasticamente la sicurezza del sistema.
Tenendo questo in considerazione, è chiaro che tutta questa patch fa è sostituire una chiamata a IppSendErrorList() con IppSendError(), dandoci un indizio che il problema riguarda una sorta di lista. Il diff di patch più semplice di sempre (o così pensavo)
Fare reverse engineering della patch per trovare il codice modificato è solo metà della sfida (o in questo caso meno dello 0,1%). Il resto del processo consiste nel fare reverse engineering abbastanza della base di codice da capire cosa sta succedendo, capire che tipo di vulnerabilità è stata patchata, come costruire una richiesta per raggiungere il codice target e quale stato porta a una condizione sfruttabile.
La prima parte è abbastanza facile. La modifica è in Ipv6pProcessOptions(), il che ci dice che si tratta di IPv6 e che coinvolge l'elaborazione delle opzioni. Quindi, una rapida occhiata all'RFC ci dice esattamente cos'è un'opzione IPv6 e dove possiamo trovarne una.
Il layout dell'header delle opzioni di destinazione da Wikipedia.
Ok, bello. Quello che stiamo cercando sembra essere l'header delle opzioni di destinazione, che si trova subito dopo l'header IPv6 principale. Usiamo la libreria Python 'scapy' per creare un pacchetto IPv6 di test.
Nota: per mitigare gli attacchi DDoS che utilizzano indirizzi IP spoofati, Windows limita la possibilità di costruire pacchetti IP grezzi. Per questo motivo ho scelto di usare Linux per sviluppare la mia proof-of-concept. Sebbene Linux consenta agli utenti di costruire e inviare pacchetti grezzi di livello 2 e 3, richiede che lo script Python venga eseguito come root.
import sys
import struct
from scapy.all import *
def send_ipv6_option_packet(dest_ip):
ethernet_header = Ether()
ip_header = IPv6(dst=dest_ip)
options_header = IPv6ExtHdrDestOpt()
sendp(ethernet_header / ip_header / options_header)
if len(sys.argv) < 2:
print('Use: python3 script.py <target_ipv6_address>')
exit(-1)
send_ipv6_option_packet(sys.argv[1])
tcpip!Ipv6pProcessOptions e aver eseguito lo script, era chiaro che tutto ciò che serviva per raggiungere la funzione vulnerabile era inviare un pacchetto IPv6 con una struttura di opzioni vuota. Ho poi provato ad aggiungere alcune opzioni non valide alla struttura per vedere se potevo raggiungere la chiamata a IppSendErrorList().Una breve revisione del codice ha indicato che quasi qualsiasi formato di opzione non valido poteva innescare la chiamata a IppSendErrorList. Quindi, ho deciso di usare l'opzione Jumbo Packet con una lunghezza non valida (inferiore a 65535 byte).
options_header = IPv6ExtHdrDestOpt(options=[Jumbo(jumboplen=0x1337)])
Quindi, cosa fa effettivamente IppSendErrorList()? Beh, il codice è piuttosto semplice.
L'intera funzione IppSendErrorList.
Il codice itera una lista collegata e chiama IppSendError() su ogni elemento della lista. Ancora una volta le stelle si sono allineate e finora le cose sono state facili. Se IppSendErrorList chiama semplicemente IppSendError per ogni elemento di una lista, e la patch sostituisce la chiamata a IppSendErrorList con IppSendError, allora il problema si verifica quando IppSendError viene chiamata su un elemento della lista diverso dal primo.
Qui è dove le cose sono passate dall'ovvio all'eccezionalmente difficile, anche se penso che una buona parte sia dovuta al fatto che una delle mie due cellule cerebrali disponibili era impegnata a combattere una brutta infezione da covid. Ho perso un paio di giorni cercando di capire parti del codice, addormentandomi e poi dimenticando ciò che avevo capito. L'intero processo ha richiesto oltre una settimana di reverse engineering di parti di tcpip.sys per capire cosa stesse succedendo. Ma il post sul blog di Axel è stato estremamente utile.
Guardando le funzioni e la struttura che Axel ha fatto reverse engineering, e a quali altre funzioni vengono passate, è chiaro che l'unico e solo argomento passato a Ipv6pProcessOptions() è la stessa struttura packet_t definita nell'articolo. In sostanza, il puntatore passato a Ipv6pProcessOptions e iterato da IppSendErrorList è una lista concatenata di pacchetti.
Quindi, ho impostato un breakpoint su Ipv6pProcessOptions() e ho ispezionato la lista.
L'elemento list->Next è NULL.