In my previous post I explained how the named pipe for a WCF NetNamedPipe endpoint is named, and how a client discovers this name in order to connect to the service. This time, I'm looking at the Windows-level security.
Both the named pipe itself, and the shared memory object used by the server to publish the name of the pipe to clients, are objects which Windows secures with Access Control Lists (ACLs). Let's look at the named pipe itself first of all...
The ACL set up when WCF creates the named pipe looks like this in SDDL (Security Description Definition Language):
D:(D;;FA;;;NU)(A;;0x12019f;;;WD)(A;;0x12019f;;;CO)
The elements of this SDDL translate as follows:
(D;;FA;;;NU) - Deny Full Access to NETWORK USERS - that is: deny the access rights specified by the access mask GENERIC_ALL, to any security context having membership of the group with well-known SID S-1-5-2
(A;;0x12019f;;;WD) - Allow the access rights specified by the access mask 0x0012019f, to EVERYONE (the well-known SID S-1-1-0)
(A;;0x12019f;;;CO) - Allow the access rights specified by the access mask 0x0012019f, to the well-known SID S-1-3-0 (CREATOR OWNER)
The first entry enforces the rule that a WCF service endpoint with NetNamedPipe binding can only be accessed by a client process running on the same machine as the service. This is because any logon token created when a user is authenticated over a network protocol has the NETWORK USERS SID S-1-5-2 added to it by the system.
The second ACE allows any authenticated user which is not a network logon to have the specified access to the named pipe. The access mask 0x0012019f corresponds to the following access rights:
0x00100000 - SYNCHRONIZE
0x00020000 - READ_CONTROL
0x00000100 - FILE_WRITE_ATTRIBUTES
0x00000080 - FILE_READ_ATTRIBUTES
0x00000010 - FILE_WRITE_EA
0x00000008 - FILE_READ_EA
0x00000004 - FILE_CREATE_PIPE_INSTANCE
0x00000002 - FILE_WRITE_DATA
0x00000001 - FILE_READ_DATA
More on this in a moment.
The third ACE looks a bit odd to me. My understanding is that CREATOR OWNER is a placeholder SID which is really only relevant when a new security descriptor is being created for a new object using an existing descriptor as the pattern: if the template descriptor contains ACEs for the CREATOR OWNER SID, the corresponding ACEs in the security descriptor created for the new object have the SID for the principal which created the object. No logon token actually contains the CREATOR OWNER SID, as far as I know. Now, when an access check is being done against an ACL-protected object, only the ACEs which match a SID in the logon token are relevant to granting or denying permission. If I'm right that no logon token is ever going to contain the CREATOR OWNER SID, then this third ACE on the pipe's DACL will never have any function in an access check performed when a handle to the pipe is acquired. I suspect that the intention of the WCF developers was that this ACE would provide the access permissions for the service process whose channel listener created the pipe: but it doesn't do this, as I will demonstrate in a subsequent post.
For the remainder of this post, let's focus on that second ACE, which grants permissions to the EVERYONE group. Did you raise an eyebrow at that FILE_CREATE_PIPE_INSTANCE permission? Do we really want EVERYONE to have permission to create an instance of the service's named pipe? No, we certainly do not! This is a bug in WCF which opens a serious security vulnerability.
The problem is that any code at all, which is able to execute on the machine where the service lives, can call the Win32 API CreateNamedPipe with appropriate arguments and get a valid server-side handle to an instance of the WCF service's named pipe. It can then call ConnectNamePipe, whereupon it will be in direct competition with the actual service for incoming client connections to the service. Sooner or later some unsuspecting client trying to send a request to the service will be allocated to the instance of the pipe "owned" by the rogue process rather than one owned by the service.
At best, the client's request to the service will just fail. But the rogue process might also read the data in the client's request; use the client's credentials by calling ImpersonateNamedPipeClient; or possibly return spoof response data to the client.
We really need to do something about this, but what? Can we control the DACL which gets put on the pipe, when the service runtime is created? Let's deconstruct exactly where this happens...
The DACL applied to a named pipe is determined by the lpSecurityAttributes argument passed to Windows when CreateNamedPipe is first called:
HANDLE WINAPI CreateNamedPipe(
__in LPCTSTR lpName,
__in DWORD dwOpenMode,
__in DWORD dwPipeMode,
__in DWORD nMaxInstances,
__in DWORD nOutBufferSize,
__in DWORD nInBufferSize,
__in DWORD nDefaultTimeOut,
__in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes
);
In WCF, this function is declared in System.ServiceModel.Channels.UnsafeNativeMethods, and is called by the private method CreatePipe() of System.ServiceModel.Channels.PipeConnectionListener, which is the implementation of IConnectionListener used by the service channel stack of the netNamedPipe binding. CreatePipe() is invoked when IConnectionListener.BeginAccept() is called by the service runtime. Our old friend Reflector shows us that the lpSecurityAttributes argument for CreateNamedPipe() is constructed in the PipeConnectionListener.CreatePipe method, using a hard-coded constant -1073741824, and a private member field, allowedSids, of type List<SecurityIdentifier>.
That constant, -1073741824, is just 0xC0000000 in decimal, which is the value of GENERIC_READ|GENERIC_WRITE (defined in WinNT.h). This specifies the access mask which is granted to each of the allowed SIDs. Generic access masks are translated by Windows into the corresponding standard and specific access mask bits applicable to the type of object being secured: in this case, the translated mask is the 0x0012019f we saw in the pipe DACL actually created.
The list of allowed SIDs for the PipeConnectionListener is supplied in its constructor. If we look at the NamedPipeTransportBindingElement which defines how the transport channel is built for the netNamedPipe binding, we see that it too has a private List<SecurityIdentifier> field, called allowedUsers, and a corresponding internal property, AllowedUsers. So it looks as though the original intention of the WCF design was that the binding should define a set of SIDs which were to be allowed to access the pipe, and each one would get GENERIC_READ|GENERIC_WRITE access to the pipe. If this worked, it would not solve the problem that the DACL gives away FILE_CREATE_PIPE_INSTANCE rights to the pipe, but at least it would restrict access (including for that particular right) to a group of SIDs which the service configuration could control. This would be a big improvement on giving the right away to EVERYONE , even if it does not completely solve the problem.
Unfortunately, the plumbing does not appear to be all there in the WCF bits to make this work: the allowedUsers in the binding element is not hooked up to the allowedSids of the PipeConnectionListener when the service runtime is built. In my next post, we'll look at ways to get round this.