Named pipe di Windows: il canale locale che può diventare una porta per l’escalation

La comunicazione tra processi non è automaticamente affidabile

Il 22 agosto 2026 è stata richiamata l’attenzione su un rischio spesso sottovalutato nelle architetture Windows: le named pipe non devono essere considerate canali privati solo perché collegano processi sullo stesso computer.

Questi oggetti permettono a servizi, applicazioni desktop, utility da riga di comando, processi nella tray e agenti in background di scambiarsi dati. In molti casi il server della pipe è un servizio eseguito con privilegi elevati, mentre il client gira con l’account dell’utente.

Sul sistema possono però convivere processi appartenenti a LocalSystem, amministratori, utenti standard e account di servizio. Sono inoltre presenti software di terze parti, script, strumenti diagnostici e malware avviati tramite credenziali compromesse.

Un processo che conosce il nome della pipe e dispone dei diritti necessari può tentare di collegarsi. Windows non verifica automaticamente che il client sia proprio l’eseguibile previsto dallo sviluppatore. La connessione riuscita dimostra soltanto che il token del processo possedeva i permessi richiesti.

Non dimostra invece che il processo fosse attendibile, che l’utente fosse autorizzato o che l’operazione richiesta fosse sicura.

Quando la pipe diventa un confine di sicurezza

Il rischio cresce quando i due estremi della comunicazione hanno livelli di privilegio differenti. L’esempio più delicato è un servizio Windows eseguito come LocalSystem che accetta richieste da un’applicazione avviata da un utente standard.

Un servizio di questo tipo può modificare file protetti, scrivere nel Registro, avviare processi, cambiare la configurazione globale, accedere ai dati di altri utenti o comunicare con driver kernel.

La named pipe diventa quindi, di fatto, un’API locale per operazioni privilegiate. Un errore nella DACL, nell’identificazione del client, nella validazione dei comandi o nella logica di autorizzazione può consentire a un processo locale di sfruttare i diritti del servizio.

Il problema è tipico del modello confused deputy: il client decide quale azione chiedere, ma l’operazione viene eseguita dal servizio con privilegi più elevati.

I messaggi possono contenere percorsi di file, chiavi del Registro, argomenti della riga di comando, nomi di eseguibili, istruzioni per avviare o terminare processi e richieste di installazione. Un servizio che accetta un comando generico come “scrivi un valore in qualsiasi chiave” espone una superficie molto più ampia rispetto a uno che consente soltanto di aggiornare una specifica impostazione applicativa.

La sintassi corretta non basta. Il server deve stabilire se quella precisa identità può eseguire quella precisa operazione sulla risorsa indicata.

ACL, token e autorizzazioni devono lavorare insieme

La protezione deve iniziare da un security descriptor esplicito, con una DACL che conceda l’accesso soltanto alle identità necessarie: uno specifico SID, un account di servizio, un gruppo amministrativo o una determinata sessione.

Affidarsi alle impostazioni predefinite può concedere diritti troppo estesi. È opportuno evitare autorizzazioni generalizzate a:

• Everyone;
• Authenticated Users;
• tutti gli utenti interattivi.

Autenticazione e autorizzazione non sono la stessa cosa. Un client può essere autorizzato a leggere lo stato del servizio, ma non ad arrestarlo, modificare impostazioni protette, avviare processi o leggere file arbitrari.

Le operazioni sensibili devono quindi essere valutate singolarmente.

Anche l’impersonation richiede cautela. Può permettere al servizio di svolgere un’azione nel contesto di sicurezza del client, ma il server deve verificare che l’operazione sia realmente riuscita, ridurre al minimo il codice eseguito durante quella fase e ripristinare sempre la propria identità originale.

La regola operativa è semplice: prima di elaborare un messaggio, il server deve verificare identità, privilegi e autorizzazione specifica.

Identificare il processo collegato

Per le comunicazioni locali, il server può ottenere il PID del client tramite GetNamedPipeClientProcessId. Dal lato opposto, il client può usare GetNamedPipeServerProcessId per identificare il processo server.

Le funzioni appartengono alle API native di kernel32.dll e devono essere chiamate dopo l’instaurazione della connessione. Il PID consente poi di aprire un handle con PROCESS_QUERY_INFORMATION o PROCESS_QUERY_LIMITED_INFORMATION e usare QueryFullProcessImageName per recuperare il percorso dell’eseguibile.

Il controllo deve avvenire subito dopo l’accettazione della connessione, prima di leggere o applicare comandi. Il percorso ottenuto va confrontato con quello atteso, ma l’eseguibile deve trovarsi in una directory non modificabile dagli utenti standard. In caso contrario, un aggressore potrebbe sostituire il file mantenendo lo stesso percorso.

Per una verifica più forte si possono controllare la firma Authenticode o una corrispondenza crittografica con un riferimento approvato.

Il nome della pipe non è un segreto. Un attaccante può conoscerlo, tentare di creare una pipe con lo stesso nome prima dell’avvio del server legittimo e indurre il client a collegarsi al processo sbagliato. L’opzione first-pipe-instance può aiutare a rilevare che il nome è già stato reclamato, ma non sostituisce ACL corrette e identificazione del processo.

Ogni messaggio va trattato come input ostile

Un client anche legittimo può inviare dati corrotti, troppo grandi o costruiti per provocare errori. Il protocollo dovrebbe prevedere framing rigoroso, limiti dimensionali, schema verificabile e una allowlist dei comandi supportati.

Sono necessarie anche:

• normalizzazione dei percorsi;
• rifiuto delle operazioni ambigue;
• gestione sicura degli errori;
• autorizzazione per singola operazione;
• separazione tra funzioni informative e azioni privilegiate;
• limitazione delle funzionalità al minimo indispensabile.

Il servizio non dovrebbe accettare percorsi arbitrari quando può lavorare con identificatori predefiniti. Per esempio, è più sicuro permettere l’aggiornamento di una configurazione specifica che ricevere dal client il percorso completo di una chiave del Registro.

Lo stesso vale per i processi: un comando limitato all’avvio di un componente noto è meno rischioso di un’interfaccia capace di eseguire qualsiasi programma con argomenti scelti dal client.

Disponibilità e accesso remoto

La minaccia non riguarda soltanto la riservatezza o l’escalation dei privilegi. Un processo malevolo può aprire molte connessioni, mantenerle attive, inviare messaggi incompleti o consumare memoria, CPU e risorse kernel.

Timeout, cancellazione delle richieste, numero massimo di connessioni, concorrenza controllata e dimensioni massime dei messaggi riducono il rischio di abuso.

Non tutte le named pipe sono inoltre necessariamente limitate al computer locale. In alcune configurazioni Windows può consentire l’accesso remoto. Le pipe destinate esclusivamente all’IPC locale dovrebbero bloccare esplicitamente identità di rete come NT AUTHORITY\NETWORK, oppure usare un meccanismo che garantisca il funzionamento soltanto locale.

Non è noto un CVE associato a questo problema, né sono indicate specifiche versioni di Windows o prodotti vulnerabili. Si tratta di un modello di sicurezza applicabile alle implementazioni che usano named pipe, non della descrizione di una singola falla identificata.

La verifica corretta deve considerare insieme cinque elementi: identità del processo, permessi effettivi, autorizzazione dell’azione, sicurezza dei dati e limiti di risorsa. Una connessione accettata non equivale mai a un’autorizzazione generale.