athenasec16/cve-2026-29923Exploit de preuve de concept pour CVE-2026-29923, une escalade de privilèges BYOVD dans pstrip64.sys. Démontre la lecture/écriture de la mémoire physique via IOCTL pour voler le token SYSTEM et générer un shell élevé.
Avertissement : Ce code est fourni à des fins éducatives et de recherche défensive uniquement. Il a été écrit pour approfondir la compréhension de l'exploitation du noyau et aider les défenseurs à se protéger contre des vulnérabilités similaires. Toute utilisation non autorisée, illégale ou malveillante de ce projet est strictement interdite.
Hash : ab01485bb7c8bc1a9c86096eeea6d31d8fad557bf4d44072b46373d2203faa6e
Nom du pilote : pstrip64.sys
CVE : CVE-2026-29923
Une attaque "Bring Your Own Vulnerable Driver" (BYOVD) est une méthode ancienne mais toujours très efficace pour contourner les protections de sécurité modernes de Windows en utilisant un pilote hérité que le système d'exploitation considère encore officiellement comme fiable. Une fois le pilote chargé, l'attaquant exploite ses failles pour combler le fossé entre un processus standard non privilégié et un contrôle total au niveau système.
Plus tôt cette semaine, une nouvelle vulnérabilité a été divulguée dans le pilote pstrip64.sys, suivie sous la référence CVE-2026-29923. Cet article de blog décompose l'ensemble du cycle de vie de l'exploit : de mes recherches initiales sur la vulnérabilité et du développement de la preuve de concept (PoC) aux stratégies d'atténuation concrètes pour les défenseurs sécurisant leurs environnements.
Le pilote pstrip64.sys est un composant en mode noyau hérité lié à EnTech Taiwan PowerStrip (jusqu'à la version 3.90.736). Bien que son objectif légitime soit de permettre des réglages avancés des cartes graphiques, ses privilèges système profonds en font une cible très attractive pour les attaquants.
Lorsque la vulnérabilité a été divulguée pour la première fois, j'ai commencé par analyser sa fonction DriverEntry. Celle-ci sert de routine d'initialisation principale pour le pilote du noyau, créant l'objet de périphérique \Device\PSTRIP64 et l'exposant aux applications en mode utilisateur via le lien symbolique \DosDevices\PSTRIP64. Plus important encore, elle configure la table de dispatch du pilote. L'entrée qui a immédiatement attiré mon attention était l'index 14 (IRP_MJ_DEVICE_CONTROL), qui achemine toutes les requêtes IOCTL fournies par l'utilisateur directement dans la fonction de gestion sub_11340, notre zone d'intérêt principale.
La fonction sub_11340 sert de répartiteur principal des IOCTL, interprétant les requêtes provenant du mode utilisateur.
Parmi tous les IOCTL exposés, 0x80002008 est sans aucun doute le plus intéressant. Alors que les cas par défaut gèrent des interactions mineures avec les ports d'E/S, 0x80002008 agit comme une passerelle vers sub_11000 en passant directement le SystemBuffer à cette fonction.
Cette routine sub_11000 est la preuve irréfutable. Tout d'abord, elle utilise HalTranslateBusAddress pour prendre notre adresse fournie par l'utilisateur et la traduire en une adresse physique système valide. Ensuite, elle ouvre \Device\PhysicalMemory et le mappe en utilisant ZwMapViewOfSection. En codant en dur le handle du processus cible à (HANDLE)0xFFFFFFFFFFFFFFFFLL (qui représente ZwCurrentProcess()), le pilote mappe cette mémoire physique directement dans l'espace d'adressage virtuel de notre processus appelant. Il écrit ensuite cette adresse virtuelle nouvellement mappée dans le SystemBuffer pour la retourner à l'utilisateur, remettant officiellement à notre application un pointeur direct pour lire et écrire dans la mémoire physique.
Avec la vulnérabilité parfaitement comprise et une primitive de lecture/écriture physique établie, j'ai toutes les pièces du puzzle nécessaires. Il est maintenant temps de commencer à écrire la preuve de concept.
Remarque : Cette PoC a été spécifiquement développée et testée sur un environnement Windows 10 22H2. Étant donné que l'exploit repose sur la manipulation brute de la mémoire physique, les décalages de structure du noyau et les limites de la mémoire physique sont actuellement codés en dur pour ma configuration. Pour tester cela sur votre propre machine, vous devez mettre à jour les décalages du noyau Windows et ajuster les plages de numérisation des adresses physiques en fonction de votre version spécifique du système d'exploitation et de votre configuration de RAM.
La première étape de mon exploit consiste à établir une communication avec le pilote. Pour cela, j'ai appelé CreateFileA sur le lien symbolique du pilote (\\.\PSTRIP64). Une fois que j'ai eu un handle valide, j'avais besoin d'une manière propre d'abuser de l'IOCTL 0x80002008 que j'avais analysé précédemment. J'ai créé une fonction wrapper appelée MapPhysicalMemory(). Cette fonction remplit ma structure personnalisée PSTRIP_MAP_REQUEST avec l'adresse physique cible et la longueur du bloc mémoire que je souhaite lire.
J'envoie ensuite cette structure directement au pilote via DeviceIoControl. En cas de succès, le pilote mappe cette mémoire physique directement dans mon application en mode utilisateur et retourne l'adresse de base virtuelle dans le champ OutputResult. Je peux maintenant convertir cette adresse retournée en un pointeur C++ standard, me donnant un accès brut et non privilégié à la RAM physique du système.
Avec ma primitive de lecture/écriture physique pleinement opérationnelle, mon objectif était de trouver les structures de données du noyau qui contiennent les privilèges des processus. Dans Windows, chaque processus en cours d'exécution est représenté par une structure EPROCESS.
Windows alloue les structures EPROCESS dans le pool du noyau en utilisant un identifiant spécifique de 4 octets appelé une étiquette de pool (Pool Tag). Pour les processus, cette étiquette est la chaîne Proc (qui se traduit par 0x636F7250 en hexadécimal). En scannant la RAM physique du système, je pouvais rechercher cette chaîne exacte.
Mon exploit parcourt l'espace mémoire physique de 0x10000000 à 0x140000000, en mappant la mémoire par blocs de 2 Mo (STEP_SIZE = 0x200000). Je convertis chaque bloc mappé en un tableau d'octets bruts et le scanne par morceaux de 16 octets (sizeof(_POOL_HEADER)).
Cependant, trouver simplement l'étiquette Proc dans la mémoire physique ne suffit pas. La mémoire est désordonnée ; cette étiquette pourrait être un artefact résiduel d'un processus terminé, ou simplement des données aléatoires qui correspondent à la valeur hexadécimale. Si je supposais aveuglément que chaque étiquette Proc était une structure EPROCESS valide et que je commençais à modifier la mémoire, je provoquerais immédiatement un écran bleu (BSOD).
Pour garantir la stabilité, j'ai dû valider la structure à l'aide d'heuristiques. Tout d'abord, je calcule le début de la structure EPROCESS (qui se trouve légèrement décalé par rapport à l'étiquette du pool). À partir de là, je vérifie quelques constantes connues pour un processus en cours d'exécution :
0x2 (Priorité normale).0x0.