Named pipes are a common choice for communication between applications running on the same **Windows** computer. They offer speed and direct operating system support, making them ideal for communication between **Windows** services, desktop applications, tray processes, command-line utilities, and background agents. A typical design often involves a privileged **Windows** service acting as the named-pipe server, with a user-facing application connecting as the client. Developers frequently treat this communication as inherently trusted because both processes run on the same machine. This assumption, however, is unsafe. In reality, the pipe is accessible from an environment where numerous unrelated processes may be running under different users, sessions, and security contexts. ## Local Does Not Mean Trusted The misconception that named pipes are private due to their local usage is a significant security flaw. A **Windows** workstation can host processes under diverse security contexts, including `LocalSystem`, administrators, standard users, service accounts, and separate interactive or remote sessions. This environment can also include third-party software, scripts, diagnostic tools, and even malware operating under a compromised account. Any process that knows the pipe name and possesses sufficient access rights can attempt to connect. **Windows** does not inherently verify which executable the developer intended to use the pipe. Consequently, a named pipe should be treated as an exposed local interface. Before processing any request, an application *must* determine the connecting identity, its authorized actions, and the safety of the provided data. ## Identity, Access Control, and Privilege Boundaries The risk escalates significantly when a privileged **Windows** service communicates with a less privileged desktop application. A service running as `LocalSystem` can modify protected files and registry keys, launch processes, alter system configurations, access other users' data, or interact with kernel drivers. When these operations are exposed via a named pipe, the pipe essentially becomes an API to privileged functionality. A successful connection only confirms that the client had permission to open the pipe. It does *not* confirm: * The client is the expected application. * The connected user is authorized. * The requested operation is permitted. * The supplied command is safe. Pipe permissions must be explicitly defined and restricted to the smallest appropriate set of identities. Broad permissions for `Everyone`, `Authenticated Users`, or all interactive users can allow unrelated processes to reach the pipe. Authentication and authorization must also remain distinct. A user might be permitted to query service status but not to stop the service, change protected settings, launch processes, or access arbitrary files. Sensitive commands require individual authorization. Impersonation can help by performing operations under the client’s security context, but it requires careful handling. The server must verify successful impersonation, limit the scope of work performed while impersonating, and always revert to its original identity. ## Untrusted Servers, Commands, and Data Client applications must also verify the server, just as servers verify clients. A predictable pipe name is merely an identifier; it is not a secret and does not prove which process created the pipe. An attacker could create a pipe using the expected name before the legitimate server starts, leading the client to connect to an attacker-controlled process. The 'first-pipe-instance' option can help detect if a name is already claimed, but it is not a substitute for robust access controls or server identity verification. Messages received through the pipe must be treated as untrusted input. Even an authenticated client might send: * Malformed or oversized payloads. * Invalid file or registry paths. * Unsupported command combinations. * Corrupted serialized objects. * Values designed to trigger error conditions. A privileged service that directly translates such input into file, registry, process, or command-line operations risks becoming a 'confused deputy' – the attacker supplies the instruction, and the service supplies the privileges. Requests should employ strict message framing, bounded sizes, command allowlists, schema validation, path normalization, operation-specific authorization, and safe error handling. ## Availability and Remote Exposure Named-pipe security extends beyond privilege escalation and unauthorized commands. A malicious or malfunctioning process could repeatedly connect, hold connections open, send incomplete messages, or submit requests that consume excessive CPU, memory, or kernel resources. Servers should implement connection limits, timeouts, cancellation, bounded message sizes, controlled concurrency, and rate limiting as appropriate. Furthermore, it is unsafe to assume that every named pipe is accessible only from the local computer. **Windows** named pipes can support remote access in certain configurations. Pipes intended exclusively for local IPC should explicitly block network identities such as `NT AUTHORITY\NETWORK`, or utilize mechanisms that guarantee local-only communication. The correct threat model is straightforward: 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. ## When a Named Pipe Becomes a Security Boundary A named pipe functions as a security boundary when processes at its ends operate with different privileges or trust levels. A common scenario involves a **Windows** service running as `LocalSystem` and a desktop application under a standard user account. The service can perform operations like modifying protected files, starting processes, changing system configuration, or accessing other users' data – actions normally beyond the desktop application's direct capabilities. When the service accepts commands via a named pipe, that pipe becomes an interface to these privileged functions. Any weakness in the pipe’s permissions, identity checks, command validation, or authorization logic can enable an untrusted local process to exploit the service’s privileges. A successful connection merely indicates that the connecting process had sufficient permission to open the pipe. It does not validate the client as the *expected* application; another process under the same user account could have identical access. The server *must* validate the security identity behind the connection, rather than relying on process names, executable paths, or the perceived secrecy of the pipe name. Each operation must also be authorized individually. A client permitted to request service status should not automatically be allowed to stop the service, modify protected configuration, launch a process, or access arbitrary files. Authentication confirms who connected; authorization determines what that identity is permitted to do. This distinction is crucial when the server processes client-controlled paths, command-line arguments, registry locations, executable names, or serialized commands. Without stringent validation, the service can become a 'confused deputy' – the client dictates the action, and the privileged service executes it. For instance, a seemingly innocuous request like: could become dangerous if the client can replace the path with: The same principle applies to requests that initiate processes, delete files, update registry values, install components, or communicate with a driver. The service must not just validate syntactic correctness; it must verify that the connected identity is authorized to perform that *exact* operation against that *exact* resource. A secure named-pipe server should implement several checks before executing a privileged request: * Verify the connected client’s **Windows** identity. * Restrict access using an explicit pipe security descriptor. * Authorize each command independently. * Validate all paths, arguments, identifiers, and payload sizes. * Reject unsupported or ambiguous operations. * Avoid exposing general-purpose privileged functionality. This last point is critical. A command like "write this value to any registry key" creates a far larger attack surface than a narrowly defined command such as "update this specific application setting." The more generalized the pipe protocol, the more it resembles a privileged local API, and the more rigorously it must be secured. The correct design principle is straightforward: the pipe server must never perform an operation solely because a connected client requested it. It should only perform the operation after confirming who requested it, whether that identity is authorized, and whether the request adheres to narrowly defined security boundaries.