Lycosa.sys, Razer: due vulnerabilità del kernel raggiungibili da qualsiasi utente locale

Scoperte tramite https://github.com/416rehman/DeepZero

Vendor: Razer Inc. Componente: Lycosa.sys, il driver filtro della tastiera Razer Lycosa, x64 SHA-256: a120a6184ab16864e8a5f1dfd0cd178fca541de463b5cef946e18c34b9b6f716 Riferimento del segnalante: a120a6184ab16864 Stato: non ancora segnalato al vendor.

Questa directory documenta due difetti distinti nella stessa routine dello stesso driver. Hanno cause prime separate e correzioni separate, quindi ciascuno ha la propria cartella autonoma e può essere tracciato e assegnato con un proprio identificativo:

CVE	Difetto	Tipo	Esito
CVE-01	La lunghezza dell'output non viene verificata rispetto al buffer, quindi il driver restituisce memoria dello stack del kernel	CWE-125 lettura fuori dai limiti	Divulgazione di memoria del kernel, vanifica la randomizzazione del layout dello spazio degli indirizzi
CVE-02	La lunghezza dell'input non viene verificata rispetto al buffer, quindi il driver sovrascrive il proprio indirizzo di ritorno	CWE-121 stack buffer overflow	Esecuzione arbitraria di codice nel kernel

Entrambe sono raggiungibili da qualsiasi account in grado di effettuare l'accesso ed eseguire un programma. Nessun diritto amministrativo, nessuna elevazione, nessun privilegio speciale. Entrambe sono state confermate su Windows 11 25H2 (build 26200.8875) con integrità del codice applicata e test signing disattivato.

La sezione 3 descrive cosa comportano le due vulnerabilità quando vengono usate insieme, ed è il motivo per cui vengono segnalate contemporaneamente e per cui la proof of concept concatenata si trova in questa directory radice.

---

1. Dove si trovano i difetti

Entrambi risiedono nel gestore IRP_MJ_DEVICE_CONTROL a RVA 0x1270, ed entrambi agiscono sullo stesso buffer da 0x400 byte sullo stack del kernel. Il prologo, letto dal binario distribuito, fissa la geometria per entrambi:

Lycosa+0x1270  48 89 54 24 10           mov   [rsp+10h], rdx   ; Irp
Lycosa+0x1275  48 89 4c 24 08           mov   [rsp+8], rcx     ; DeviceObject
Lycosa+0x127a  48 81 ec 98 04 00 00     sub   rsp, 498h        ; the frame
Lycosa+0x1291  ba 00 04 00 00           mov   edx, 400h        ; the buffer size
Lycosa+0x1296  48 8d 8c 24 80 00 00 00  lea   rcx, [rsp+80h]   ; the buffer

Un buffer da 0x400 byte a rsp+0x80, all'interno di un frame da 0x498 byte, senza registri non volatili salvati. Contando dall'inizio del buffer:

0x000 .. 0x3FF   il buffer, entro il quale entrambi i difetti dovrebbero rimanere
0x418            l'indirizzo di ritorno della routine di dispatch
0x420            l'argomento DeviceObject salvato
0x428            l'argomento Irp salvato

0x418 è 0x498 - 0x80. La divulgazione (CVE-01) legge oltre 0x3FF e restituisce ciò che trova; l'overflow (CVE-02) scrive oltre 0x3FF e lo sostituisce.

2. Raggiungibilità, e chi può farlo

DriverEntry crea il dispositivo senza security descriptor e pubblica un symbolic link per esso, quindi è raggiungibile su \\.\Lycosa:

IoCreateDevice(param_1, 0x20, L"\\Device\\Lycosa", 0x22, 0, 0, &device);
IoCreateSymbolicLink(L"\\DosDevices\\Lycosa", L"\\Device\\Lycosa");

Ogni control code interessato si decodifica come FILE_DEVICE_UNKNOWN, METHOD_BUFFERED, FILE_ANY_ACCESS. FILE_ANY_ACCESS significa che non deve essere detenuto alcun diritto di accesso particolare sull'handle, quindi il security descriptor dell'oggetto dispositivo è l'unico controllo, e concede l'accesso a tutti.

Tutti i risultati in questi report sono stati prodotti da un account utente standard la cui unica appartenenza a gruppi è il gruppo predefinito Users. L'account non aveva diritti amministrativi, non era elevato e non deteneva privilegi oltre quelli predefiniti.

Il driver si carica anche su macchine a cui non è mai stato collegato hardware Razer, poiché il pacchetto è validamente firmato con catalogo. Questo è il pattern usato negli attacchi bring-your-own-vulnerable-driver.

3. I due difetti si combinano

Segnalati separatamente perché sono difetti separati, ma un vendor che li analizza dovrebbe sapere che ciascuno peggiora l'altro.

Windows moderno carica il kernel a un indirizzo randomizzato. Un attaccante che può sovrascrivere un indirizzo di ritorno deve comunque sapere con cosa sovrascriverlo, e questo è normalmente l'ostacolo. Questo driver risponde da solo a entrambe le domande:

1. CVE-01 elimina la randomizzazione. La divulgazione restituisce l'indirizzo di ritorno della routine di dispatch stessa, un indirizzo di codice all'interno di ntoskrnl.exe. Sottraendo il suo offset noto all'interno dell'immagine si ottiene la base a cui il kernel è caricato, e da lì ogni indirizzo all'interno del kernel è noto. Questo non costa nulla e non disturba nulla.

2. CVE-01 fornisce anche il valore di cui CVE-02 ha bisogno per non andare in fault. Come descritto in CVE-02 sezione 4.4, il driver ricarica l'Irp dall'offset 0x428 sulla via d'uscita e vi scrive attraverso. Un overflow ingenuo che raggiunge l'indirizzo di ritorno distrugge anche quel puntatore e va in fault prima che la routine ritorni. L'exploit affidabile invece ferma la copia esattamente a 0x428, lasciando in posizione l'Irp attivo della richiesta corrente, così il driver completa normalmente.

3. CVE-02 reindirizza quindi l'esecuzione, con la base del kernel già nota.

Da un account non privilegiato, la proof of concept concatenata legge il frame, calcola la base del kernel e l'indirizzo kernel del buffer stesso, e invia una catena return-oriented:

step 1, read what is above the buffer on the kernel stack:
   +0x418 return address  0xFFFFF807D565CABB
   +0x498 frame pointer   0xFFFFFD042D313750  (read twice, must match)

step 2, turn those into the two addresses the payload needs:
   kernel base     = 0xFFFFF807D565CABB - 0x25CABB = 0xFFFFF807D5400000
   buffer on stack = 0xFFFFFD042D313750 - 0x500    = 0xFFFFFD042D313250

step 4, overflow with a chain that:
   pivots the stack onto the buffer, calls nt!ZwCreateFile, and
   resumes nt!IopfCallDriver+0x5b

sending 0x428 bytes
call returned: accepted=true error=0

PROOF: C:\Windows\System32\dz_lycosa_kernel_exec.txt now exists.

Questa è la catena completa, verificata end to end. L'account non privilegiato ha creato un file sotto C:\Windows\System32, una directory a cui altrimenti gli viene negato l'accesso in scrittura, eseguendo nt!ZwCreateFile in modalità kernel. accepted=true significa che la chiamata di sistema è ritornata normalmente: la catena riprende l'indirizzo esatto a cui il driver stava per ritornare (nt!IopfCallDriver+0x5b, che è add rsp,0x38 ; ret), quindi il thread termina e la macchina continua a funzionare. Il file creato è stato confermato in modo indipendente da una shell amministrativa. La trascrizione completa è in logs/exec_create_file.log, e il metodo è in METHODOLOGY.md.