IPC security named pipes

1
votes

I wish to use named pipes in my app. Server would be NT service and client is user space app. I presume that there could be a problem if someone could create application client that lock pipe(or something) and my server stop receive messages.

I wish to add that client should always send messages and server receive them. If someone disturb that process there be a problem.

I need advice how to secure named pipes

2
c++ipcnamed-pipesboost-interprocess

2 Answers

1
votes

Here are some things to consider in terms of implementing "secured" named pipes.

  • Named pipes in Windows OS are placed in a special path \\.\pipe\ to which every user (including guest) has access.

  • A named pipe can have multiple instances that share the same name;

    • Each instance connects exactly one pipe server and one pipe client.
    • New pipe clients connected to the pipe servers in round-robin order.

  • The creator of the first instance decides the maximum number of instances as well as specifies the security descriptors.

    • This includes an access control list (DACL) to control all the instances.
    • The default descriptor grants read access to everyone and full access only to the creator user and the administrators.

  • If a named pipe does not exist, any user can create the first instance and set DACL of all pipe instances.

  • If it exists, only users with FILE_CREATE_PIPE_INSTANCE permission can create new instances.

    • Take advantage of FILE_FLAG_FIRST_PIPE_INSTANCE flag for your server to ensure that it is creating the first instance.

Credits: Man-in-the-Machine (MitMa) attacks on ill-secured inter process communications, which explains the harm of not securing many IPC methods including named pipes.

0
votes

AFAIK, multiple different client processes can all open the named pipe and write to the single reader process. This would certainly hold true on Unix, so it probably does on Windows too.

That means that a single process cannot stop other processes writing to the server - though a misbehaved process might overwhelm the server with its messages. There is no easy protection against an over-enthusiastic client.