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:

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.

La lettura pratica è che questo singolo driver fornisce, a qualsiasi utente della macchina, entrambe le metà di ciò che normalmente serve per trasformare un difetto di memory safety in esecuzione di codice nel kernel: la divulgazione di indirizzi che elimina la randomizzazione, e il dirottamento del control-flow che la utilizza. Insieme è stato dimostrato che producono un'azione privilegiata concreta con la macchina lasciata in funzione.

4. Correggerli

Le due correzioni sono indipendenti ed entrambe piccole, indicate per intero in ciascun report:

• Remediation CVE-01: limitare OutputBufferLength, e impostare IoStatus.Information a ciò che è stato effettivamente prodotto.
• Remediation CVE-02: limitare InputBufferLength.

Entrambi i report raccomandano inoltre di creare il dispositivo di controllo con IoCreateDeviceSecure e una stringa SDDL che lo limiti agli amministratori e al sistema. Solo questo non correggerebbe nessuno dei due difetti, ma rimuoverebbe la raggiungibilità non privilegiata che conferisce a entrambi la loro gravità.

5. Prior art

Verificato prima di redigere il report, perché un report duplicato fa perdere tempo a un vendor:

• LOLDrivers, 660 voci, cercate per SHA-256, per MD5 e per nome file. Nessuna voce per questo driver.
• Microsoft vulnerable driver blocklist, scaricata da https://aka.ms/VulnerableDriverBlockList e cercata tra le sue 1.713 regole di deny. Questo file non compare. L'unico driver Razer in quella lista è Rzpnk.sys, un componente diverso.
• Non è stata trovata alcuna CVE che descriva questo driver.

Riteniamo che entrambi i difetti siano precedentemente non segnalati e accoglieremmo con favore eventuali correzioni.

Diversi altri driver distribuiti nella stessa directory del pacchetto condividono la forma generale di questo driver e sono esaminati separatamente. Nulla di quanto qui riportato è un'affermazione su di essi.

6. Riprodurre

pnputil /add-driver Flter2K.inf /install
sc create lycosa_test type= kernel binPath= C:\path\to\Lycosa.sys start= demand
sc start lycosa_test

Ogni difetto ha la propria proof of concept monoscopo nella propria cartella, e questa radice contiene quella concatenata che li combina:

# CVE-01, reads only, safe to run anywhere, quickest confirmation of the report
rustc -O CVE-01-kernel-memory-disclosure/poc/lycosa_disclosure.rs -o disc.exe
disc.exe

# CVE-02, stops the machine by design
rustc -O CVE-02-kernel-stack-overflow/poc/lycosa_overflow.rs -o ovf.exe
ovf.exe --yes-crash-this-machine

# the chain: CVE-01 + CVE-02 into a file created in System32, machine left running
rustc -O poc/lycosa_chain.rs -o chain.exe
chain.exe --exec                              # default target under System32
chain.exe --exec C:\Users\Public\proof.txt    # or any path you choose

Eseguire tutto da un account utente standard. La PoC concatenata dichiara le due costanti del driver da cui dipende (FRAME e BUF_AT) all'inizio del suo sorgente, quindi può essere puntata a una build diversa del driver cambiando quei due numeri. Gli offset del kernel usati dalla sua modalità --exec sono specifici di una build di Windows; il programma verifica la base del kernel derivata a run time e la sua modalità --calibrate riporta l'unico valore che cambia tra le build.

7. Contenuto di questa directory

README.md                              this overview and the chaining analysis
METHODOLOGY.md                         how both were found and confirmed, in order
poc/lycosa_chain.rs                    the CHAINED proof of concept (both defects)
evidence/                              the binary, its package, decompiled sources, dumps
logs/exec_create_file.log              transcript of the chained run in section 3

CVE-01-kernel-memory-disclosure/       standalone disclosure for the out-of-bounds read
  README.md, poc/lycosa_disclosure.rs, evidence/, logs/
CVE-02-kernel-stack-overflow/          standalone disclosure for the stack overflow
  README.md, poc/lycosa_overflow.rs, evidence/, logs/