I would like to know if netNamedPipeBinding is considered safe:
On one hand NetNamedPipeBinding implements security only on the transport Layer and it uses NTLM (source) that is no longer recommended by Microsoft (source)
On the other hand the Named Pipie is not accessible from a remote computer, and there is no way to eavesdrop on a particular open pipe instance being used to transfer data, or write data to it, unless one can obtain the handle to the specific instance concerned.
This is the reason why I don't know what to think about the security of this solution.
You are not really asking the right question: it is not possible to give a boolean answer valid in all circumstances. You should always assess security of a solution as a whole, identifying threats and modelling the associated security risks.
That said, it is true that the WCF NetNamedPipeBinding does have security characteristics which makes it somewhat different from bindings based on network protocols:
- Compared to any network protocol, the NetNamedPipeBinding is inherently far more secure against threats to the communication over the transport connection. Rather than bytes being transmitted over a network, in the case of named pipes the messages are exchanged over a mechanism involving passing bytes of data (via operating system APIs) to and from memory managed by the operating system kernel on a single machine. The message stream can't possibly be eavesdropped except by an attacker who already has privileged code running in kernel mode (and if you have such an attacker already inside the knickers of your operating system he can probably already do anything he likes with your application process). Consequently the WCF "Transport Security" is more or less irrelevant to the security of the message stream and should arguably often be disabled in configuration to avoid unnecessary runtime overhead.
- The mechanism used by the named pipe binding to publish service endpoints to prospective clients is also inherently more secure than network-based protocols: it is based on a named Shared Memory object and thus impossible to access from any remote computer.
- The named pipe used for message exchange is named with a GUID which changes every time the server restarts, and is further protected by an ACL which prevents any remote user opening it, even if they were able somehow to discover the current GUID of the pipe name.
On the other hand, being based on an operating system facility accessed via an API, rather than on public standards for network communication, there are some specific security vulnerabilities which don't arise for network-based bindings:
- Server "squatting" attacks, where some process other than the intended WCF service host succeeds in listening on the named pipe. The named pipe binding in .NET 3.5 and prior was not secure against this vulnerability due to an error in the ACL created by the binding to secure the pipe. .NET 4 mostly corrected this error.
- Named pipes on Windows have an in-built mechanism to support named pipe servers impersonating their clients. The WCF NetNamedPipeBinding contains a bug which in some scenarios enables the pipe server (i.e. the WCF service) to use the client's Windows credentials for such impersonation even if the client-side WCF binding is configured to disallow impersonation.
In summary, you need to evaluate the overall security of your application/system in the light of the threats which matter to you, taking into account the particular characteristics of the various bindings you might consider. The NetNamedPipeBinding will often be the best choice for same-machine scenarios.
Menu
978
