Windows Named Pipe Access control

Question

My process (server) creates a child process (client) by CreateProcess and I am doing IPC between these processes. I begin with anonymous pipe, but soon I find that it does not support overlapped operations as explained here.

So, named-pipe is my second choice. My confusion is: if I create a named-pipe, is it possible to limit the access of this pipe only to my child process created by previously call to CreateProcess? Thus, even if another process obtains the Pipe's Name, it still cannot read or write to the pipe.

My IPC usage only limits to local machine and single platform (Windows).

BTW, I can change both codes for these processes.

Answer 1

You could explicitly assign an ACL to the new pipe by using the lpSecurityAttributes parameter. This would allow you to ensure that, if another user is logged on, they can't connect to the pipe.

However, if you create both ends of the pipe in the parent process there is very little scope for malfeasance, so in general explicitly setting an ACL is not necessary. Once you have opened the client end of the pipe, no other process can connect to the pipe anyway (you would have to create a second instance if you wanted them to do so) so there is only a very brief interval during which another process could interfere; and even if that happened, you wouldn't be able to connect the client end, so you would know something had gone wrong.

In other words, the scope for attack is limited to denial of service, and since the attacking process would need to be running on the same machine, it can achieve a much more effective denial of service simply by tanking the CPU.

Note that:

• You should use the FILE_FLAG_FIRST_PIPE_INSTANCE flag when creating the pipe, to ensure that you know if there is a name collision.

• You should also use PIPE_REJECT_REMOTE_CLIENTS for obvious reasons.

• The default permissions on a named pipe do not allow other non-administrative users to create a new instance, so a man-in-the-middle style attack is not a risk in this case.

• A malicious process running as the same user, or as an administrative user, could potentially man-in-the-middle your connection (regardless of whether you set an ACL or not) but since any such malicious process could also inject malicious code directly into the parent and/or child there is little point in worrying about it. The attacker is already on the wrong side of the air-tight hatchway; locking the windows won't do you any good.

• If your process is running with elevated privilege, you probably should set an ACL on the pipe. The default ACL would potentially allow non-elevated processes running as the same user context to man-in-the-middle the connection. You can resolve this by setting an ACL that grants full access only to Administrators. The risk is still minimal, but in this particular case a defense-in-depth measure is probably appropriate.

• An anonymous pipe is implemented as a named pipe with a unique name, so you haven't actually lost anything by using a named pipe. An attacker could in principle man-in-the-middle an anonymous pipe just as easily as a named one. (Edit: according to RbMm, this is no longer true.)