Questa è una PoC (piuttosto instabile) per CVE-2024-38063, una RCE in tcpip.sys corretta il 13 agosto 2024. Non ho trovato e segnalato questa vulnerabilità, quello è stato Wei.

requisiti

pip3 install scapy

utilizzo

Modifica i campi nello script:

• iface <- Se hai più adattatori, devi scegliere quale usare per inviare i pacchetti. es. "eth0" su linux o "Hyper-V Virtual Ethernet Adapter" su windows. Se intendi usare la tua interfaccia predefinita, lascialo vuoto.
• ip_addr <- Indirizzo IP del sistema di destinazione (IPv6)
• num_tries e num_batches <- Quanti diversi batch di pacchetti inviare. Più sono = più corruzioni dell'heap causate + maggiore probabilità di innescare la vulnerabilità.
• mac_addr <- Lascia vuoto, a meno che scapy non segnali che non riesce a trovare l'indirizzo MAC. Vedi sotto nella risoluzione dei problemi.

Esegui lo script:

python3 cve-2024-38063.py

Il modo più semplice per riprodurre la vulnerabilità è usando bcdedit /set debug on sul sistema di destinazione e riavviando la macchina/VM. Questo fa sì che il driver dell'adattatore di rete predefinito diventi kdnic.sys, che è molto propenso a coalescere i pacchetti. Se stai cercando di riprodurre la vulnerabilità su una configurazione diversa, dovrai portare il sistema in una posizione in cui coalesce i pacchetti che hai inviato. Puoi leggere la sezione di risoluzione dei problemi qui sotto per maggiori dettagli.

dimostrazione

cve-2024-38063.webm

rca approssimativa

Puoi leggere questa ottima analisi della vulnerabilità di Marcus se sei interessato ai dettagli tecnici. I dettagli che ho scritto qui sotto hanno lo scopo di servire come riassunto, piuttosto che come analisi tecnica seria.

• In certe situazioni, Windows unisce più pacchetti IP insieme e li elabora in batch. Prima elabora gli header di estensione in ogni pacchetto, e solo dopo passa a elaborare i dati in ogni pacchetto.
• Durante l'elaborazione degli header di estensione, gli oggetti pacchetto di questi pacchetti uniti sono collegati in una lista collegata. Ogni oggetto pacchetto contiene un oggetto NET_BUFFER che contiene i dati del pacchetto bufferizzato. All'offset 0x30 abbiamo anche un campo current-offset che indica quanto è stato analizzato il pacchetto. In questa fase, il valore dell'offset sarà generalmente 0x28, indicando che l'header IPv6 è stato analizzato ma nient'altro.
• Quando si elabora l'header di estensione 'destination options' in tcpip!Ipv6pReceiveDestinationOptions, un errore di parsing causerà la chiamata di tcpip!IppSendErrorList. Questa funzione chiama tcpip!IppSendError su ogni oggetto pacchetto nella lista collegata (partendo da quello corrente).
• Sotto certe condizioni (ad es. se il pacchetto è unicast), tcpip!IppSendError ha effetti collaterali. 'Riporta' i dati del pacchetto bufferizzato all'inizio e resetta il campo current-offset a zero.
• Tuttavia, in tutta questa catena di eventi, solo il primo pacchetto è marcato come avente un errore (offset 0x8C). Ciò significa che il driver continuerà a elaborare gli header di estensione di altri pacchetti nella lista collegata, anche se sono stati 'riportati' in IppSendError.
• L'elaborazione di quei pacchetti che sono stati riportati viene quindi eseguita con dati inaspettati: i dati del pacchetto bufferizzato puntano all'inizio del pacchetto (cioè l'header IPv6) invece che agli header di estensione, e il valore del campo offset è zero invece di 0x28.

strategia

• Per abusare della vulnerabilità, utilizziamo Ipv6pReceiveFragment. La funzione analizza l'header di estensione del frammento e assume che il campo offset del pacchetto sarà almeno 0x28 quando calcola la lunghezza dei dati non-header nel pacchetto sottraendo 0x30 dal valore corrente dell'offset. Questo valore viene poi memorizzato nell'oggetto di riassemblaggio il cui scopo è riassemblare il pacchetto frammentato.
• Nel nostro caso, la funzione verrà chiamata su un pacchetto che è stato riportato da IppSendError. Il valore dell'offset sarà zero e aumentato a 8 da qualche parte prima in Ipv6pReceiveFragment. Quando si calcola la dimensione dei dati non-header, il valore andrà in underflow e sarà uguale a 0xffd8 (la sottrazione è fatta in 16 bit).
• Il valore della lunghezza è utilizzato solo in due punti successivamente:
  • Ipv6pReassembleDatagram, dove viene usato per calcolare la lunghezza di un buffer di output del pacchetto riassemblato. Tuttavia, tutti i calcoli sono fatti in 32 bit e c'è un controllo di integrità che la lunghezza totale non superi 0xFFFF, cosa che in questo caso accade.
  • Ipv6pReassemblyTimeout, dove viene usato allo stesso modo. Tuttavia, i calcoli qui sono fatti in 16 bit e si verifica un overflow di interi. Questo porta a un buffer overflow quando si copiano i dati nel buffer successivamente.

Per innescare Ipv6pReassemblyTimeout, il mittente del frammento deve rimanere inattivo per 1 minuto. La nostra strategia è quindi:

• Inviare opzioni di destinazione malformate per innescare IppSendError, seguite da un pacchetto frammento
• Sperare che i due pacchetti siano coalesciuti e che l'oggetto del secondo pacchetto veda i suoi dati e offset resettati
• Causare l'underflow in Ipv6pReceiveFragment e creare un nuovo oggetto di riassemblaggio con una lunghezza dei dati del frammento che sia un valore alto a 16 bit
• Attendere 1 minuto senza inviare altri pacchetti in modo che Ipv6pReassemblyTimeout venga innescato.
• Causare un overflow di interi nel calcolo della dimensione del buffer in Ipv6pReassemblyTimeout e innescare un heap-based buffer overflow.

I pacchetti nello script sono inviati a raffica in modo che ci sia una maggiore probabilità che vengano coalesciuti. Il payload principale è piuttosto semplice:

• Pacchetto IPv6 con un header di estensione 'destination options' con dati di opzioni malformati che innescheranno un errore di parsing
• Frammento IPv6 #1, che speriamo venga concatenato al primo pacchetto
• Frammento IPv6 #2 (stesso id), che potrebbe anche essere concatenato ai primi due, ma il suo scopo principale è completare il secondo frammento in modo che non vengano generati errori nel caso in cui l'elaborazione normale avvenga

Impostiamo anche manualmente i campi hop limit e flow label nell'header IPv6. Ricordiamo che i dati del pacchetto bufferizzato vengono resettati a causa della vulnerabilità. Ciò significa che, quando si elabora il pacchetto frammento, l'header IPv6 verrà interpretato come dati dell'header del frammento. Il campo hop limit nell'header IPv6 verrà interpretato come uno dei bit del campo id nell'header del frammento. Cambiandolo, ci assicuriamo di innescare la vulnerabilità per diversi frammenti diversi e causare diverse corruzioni, aumentando la probabilità di un crash (dato che questa è una PoC, dopotutto). Il campo flow label dell'header IP verrà interpretato come i campi offset e 'more indicator' dell'header del frammento. Impostandolo a 1, indichiamo che ci sono altri header in arrivo (quindi essere in grado di innescare Ipv6pReassemblyTimeout in seguito) e che l'offset è zero (poiché questo è il primo pacchetto con tale id in arrivo).