Introduction to Named Pipes
Named pipes are a common choice for communication between applications running on the same Windows computer. They are fast, supported directly by the operating system, and work well for communication between Windows services, desktop applications, tray processes, command-line utilities, and background agents.
Local Does Not Mean Trusted
A typical design may include a privileged Windows service acting as the named-pipe server while a user-facing application connects as the client. Because both processes run on the same computer, developers often treat this communication as internal and therefore trusted. However, this assumption is unsafe.
A Windows workstation may run processes under LocalSystem, administrators, standard users, service accounts, and separate interactive or remote sessions. It may also contain third-party software, scripts, diagnostic tools, and malware operating under a compromised account. Any process that knows the pipe name and has sufficient access rights can attempt to connect.
Identity, Access Control, and Privilege Boundaries
The risk is greatest when a privileged Windows service communicates with a less privileged desktop application. A service running as LocalSystem may be able to modify protected files and registry keys, launch processes, change system configuration, access other users’ data, or communicate with kernel drivers.
When these operations are exposed through a named pipe, the pipe becomes an API to privileged functionality. A successful connection proves only that the client was allowed to open the pipe. It does not prove that the client is the expected application, the connected user is authorized, the requested operation is permitted, or the supplied command is safe.
Pipe Permissions and Access Control
Pipe permissions should therefore be defined explicitly and restricted to the smallest appropriate set of identities. Broad permissions for Everyone, Authenticated Users, or all interactive users may allow unrelated processes to reach the pipe.
Authentication and authorization must also remain separate. A user may be allowed to query service status but not stop the service, change protected settings, launch processes, or access arbitrary files. Sensitive commands should be authorized individually.
Untrusted Servers, Commands, and Data
The client must verify the server just as the server verifies the client. A predictable pipe name is only an identifier. It is not a secret and does not prove which process created the pipe.
An attacker may create a pipe using the expected name before the legitimate server starts, causing the client to connect to an attacker-controlled process. The first-pipe-instance option can help detect that the name has already been claimed, but it does not replace proper access controls or server identity verification.
Message Validation and Error Handling
Messages received through the pipe must also be treated as untrusted input. Even an authenticated client may send malformed or oversized payloads, invalid file or registry paths, unsupported command combinations, corrupted serialized objects, or values designed to trigger error conditions.
A privileged service that converts such input directly into file, registry, process, or command-line operations may become a confused deputy: the attacker supplies the instruction, while the service supplies the privileges.
Availability and Remote Exposure
Named-pipe security is not limited to privilege escalation and unauthorized commands. A malicious or malfunctioning process may repeatedly connect, hold connections open, send incomplete messages, or submit requests that consume excessive CPU, memory, or kernel resources.
The server should use connection limits, timeouts, cancellation, bounded message sizes, controlled concurrency, and rate limiting where appropriate. It is also unsafe to assume that every named pipe is reachable only from the local computer.
Threat Model and Security Boundaries
A named pipe becomes a security boundary when the processes on its two ends run with different privileges or operate under different trust levels. A common example is a Windows service running as LocalSystem and a desktop application running under a standard user account.
The correct threat model is simple: every named-pipe connection should be considered potentially hostile until the client or server identity, permissions, requested operation, and message contents have all been verified.
Access Control and Client Authorization
A named-pipe server should decide who may connect before it begins processing messages. This starts with an explicit security descriptor that grants access only to the required Windows identities.
The pipe’s DACL controls access to both ends of the named pipe. When a client attempts to connect, Windows compares the client’s access token and requested rights with that DACL.
Relying on the default descriptor is risky because its permissions may be broader than the application requires. Access to the pipe does not automatically authorize every available command.
Verification and Validation
A client may be allowed to retrieve status information while being denied permission to modify configuration, start processes, or access protected files. Authorization should therefore be performed for each sensitive operation rather than only once when the connection is established.
For local application-to-application communication, the applications can also inspect the process associated with the opposite end of the pipe: the server can call GetNamedPipeClientProcessId; the client can call GetNamedPipeServerProcessId.
These Windows APIs return the process identifier associated with the connected client or server. They should be called only after the pipe connection has been established.
Source: BleepingComputer