Named pipes Windows : un canal local qui peut devenir une voie d’escalade

La communication interprocessus n’est pas automatiquement fiable

Le 22 août 2026, l’attention a été attirée sur un risque souvent sous-estimé dans les architectures Windows : les named pipes ne doivent pas être considérées comme des canaux privés sous prétexte qu’elles relient des processus sur le même ordinateur.

Ces objets permettent à des services, des applications de bureau, des utilitaires en ligne de commande, des processus exécutés dans la zone de notification et des agents en arrière-plan d’échanger des données. Dans de nombreux cas, le serveur de la pipe est un service exécuté avec des privilèges élevés, tandis que le client fonctionne sous le compte de l’utilisateur.

Le système peut toutefois héberger simultanément des processus appartenant à LocalSystem, à des administrateurs, à des utilisateurs standard et à des comptes de service. On y trouve également des logiciels tiers, des scripts, des outils de diagnostic et des malwares lancés à l’aide d’identifiants compromis.

Un processus qui connaît le nom de la pipe et dispose des droits nécessaires peut tenter de s’y connecter. Windows ne vérifie pas automatiquement que le client est bien l’exécutable prévu par le développeur. Une connexion réussie prouve uniquement que le jeton du processus possédait les autorisations requises.

Elle ne prouve ni que le processus est digne de confiance, ni que l’utilisateur est autorisé, ni que l’opération demandée est sûre.

Quand la pipe devient une frontière de sécurité

Le risque augmente lorsque les deux extrémités de la communication disposent de niveaux de privilèges différents. Le cas le plus sensible est celui d’un service Windows exécuté sous LocalSystem qui accepte des requêtes provenant d’une application lancée par un utilisateur standard.

Un tel service peut modifier des fichiers protégés, écrire dans le Registre, lancer des processus, modifier la configuration globale, accéder aux données d’autres utilisateurs ou communiquer avec des pilotes du noyau.

La named pipe devient donc, de fait, une API locale permettant d’effectuer des opérations privilégiées. Une erreur dans la DACL, l’identification du client, la validation des commandes ou la logique d’autorisation peut permettre à un processus local d’exploiter les droits du service.

Ce problème relève du modèle confused deputy : le client choisit l’action à demander, mais l’opération est exécutée par le service avec des privilèges supérieurs.

Les messages peuvent contenir des chemins de fichiers, des clés du Registre, des arguments de ligne de commande, des noms d’exécutables, des instructions pour lancer ou terminer des processus et des demandes d’installation. Un service qui accepte une commande générique telle que « écrire une valeur dans n’importe quelle clé » expose une surface bien plus large qu’un service autorisant uniquement la mise à jour d’un paramètre applicatif précis.

Une syntaxe correcte ne suffit pas. Le serveur doit déterminer si cette identité précise est autorisée à effectuer cette opération précise sur la ressource indiquée.

Les ACL, les jetons et les autorisations doivent fonctionner ensemble

La protection doit commencer par un security descriptor explicite, avec une DACL accordant l’accès uniquement aux identités nécessaires : un SID spécifique, un compte de service, un groupe d’administrateurs ou une session déterminée.

Se fier aux paramètres par défaut peut accorder des droits trop étendus. Il convient d’éviter les autorisations générales accordées à :

• Everyone ;
• Authenticated Users ;
• l’ensemble des utilisateurs interactifs.

L’authentification et l’autorisation sont deux notions distinctes. Un client peut être autorisé à lire l’état du service sans pouvoir l’arrêter, modifier des paramètres protégés, lancer des processus ou lire des fichiers arbitraires.

Les opérations sensibles doivent donc être évaluées séparément.

L’impersonation exige elle aussi de la prudence. Elle peut permettre au service d’effectuer une action dans le contexte de sécurité du client, mais le serveur doit vérifier que l’opération a réellement réussi, limiter autant que possible le code exécuté pendant cette phase et rétablir systématiquement son identité d’origine.

La règle opérationnelle est simple : avant de traiter un message, le serveur doit vérifier l’identité, les privilèges et l’autorisation spécifique.

Identifier le processus connecté

Pour les communications locales, le serveur peut obtenir le PID du client à l’aide de GetNamedPipeClientProcessId. De son côté, le client peut utiliser GetNamedPipeServerProcessId pour identifier le processus serveur.

Ces fonctions appartiennent aux API natives de kernel32.dll et doivent être appelées après l’établissement de la connexion. Le PID permet ensuite d’ouvrir un handle avec PROCESS_QUERY_INFORMATION ou PROCESS_QUERY_LIMITED_INFORMATION, puis d’utiliser QueryFullProcessImageName pour récupérer le chemin de l’exécutable.

Le contrôle doit être effectué immédiatement après l’acceptation de la connexion, avant de lire ou d’appliquer des commandes. Le chemin obtenu doit être comparé à celui attendu, mais l’exécutable doit se trouver dans un répertoire non modifiable par les utilisateurs standard. Dans le cas contraire, un attaquant pourrait remplacer le fichier tout en conservant le même chemin.

Pour renforcer la vérification, il est possible de contrôler la signature Authenticode ou de comparer une empreinte cryptographique à une référence approuvée.

Le nom de la pipe n’est pas un secret. Un attaquant peut le connaître, tenter de créer une pipe portant le même nom avant le démarrage du serveur légitime et inciter le client à se connecter au mauvais processus. L’option first-pipe-instance peut aider à détecter que le nom a déjà été revendiqué, mais elle ne remplace ni des ACL correctes ni l’identification du processus.

Chaque message doit être traité comme une entrée hostile

Même un client légitime peut envoyer des données corrompues, excessivement volumineuses ou conçues pour provoquer des erreurs. Le protocole devrait prévoir un framing strict, des limites de taille, un schéma vérifiable et une allowlist des commandes prises en charge.

Les mesures suivantes sont également nécessaires :

• normalisation des chemins ;
• rejet des opérations ambiguës ;
• gestion sécurisée des erreurs ;
• autorisation pour chaque opération ;
• séparation entre fonctions d’information et actions privilégiées ;
• limitation des fonctionnalités au strict nécessaire.

Le service ne devrait pas accepter de chemins arbitraires lorsqu’il peut fonctionner avec des identifiants prédéfinis. Par exemple, il est plus sûr d’autoriser la mise à jour d’un paramètre de configuration précis que de recevoir du client le chemin complet d’une clé du Registre.

Il en va de même pour les processus : une commande limitée au lancement d’un composant connu est moins risquée qu’une interface capable d’exécuter n’importe quel programme avec des arguments choisis par le client.

Disponibilité et accès à distance

La menace ne concerne pas uniquement la confidentialité ou l’escalade de privilèges. Un processus malveillant peut ouvrir de nombreuses connexions, les maintenir actives, envoyer des messages incomplets ou consommer de la mémoire, du CPU et des ressources du noyau.

Les délais d’expiration, l’annulation des requêtes, le nombre maximal de connexions, la concurrence contrôlée et la taille maximale des messages réduisent le risque d’abus.

Par ailleurs, toutes les named pipes ne sont pas nécessairement limitées à l’ordinateur local. Dans certaines configurations, Windows peut autoriser l’accès à distance. Les pipes destinées exclusivement à l’IPC local devraient bloquer explicitement les identités réseau telles que NT AUTHORITY\NETWORK, ou utiliser un mécanisme garantissant un fonctionnement strictement local.

Aucun CVE n’est connu pour ce problème, et aucune version précise de Windows ni aucun produit vulnérable n’est indiqué. Il s’agit d’un modèle de sécurité applicable aux implémentations utilisant des named pipes, et non de la description d’une vulnérabilité spécifique identifiée.

Une vérification correcte doit prendre en compte cinq éléments conjointement : l’identité du processus, les permissions effectives, l’autorisation de l’action, la sécurité des données et les limites de ressources. Une connexion acceptée ne constitue jamais une autorisation générale.