Charteris Community Server

Welcome to the Charteris plc Community
Welcome to Charteris Community Server Sign in | Join | Help
in Search

Chris Dickson's Blog

Exploring the WCF Named Pipe Binding - Part 2

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):


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



0x00000010 - FILE_WRITE_EA

0x00000008 - FILE_READ_EA


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.

Published Jun 16 2008, 07:04 PM by chrisdi
Filed under: , ,




(1)Chris wrote excellent blog about Named pipe Binding

July 11, 2008 9:42 PM

Pregnant Man » All About Named Pipe Binding said:

Pingback from  Pregnant Man &raquo; All About Named Pipe Binding

July 12, 2008 8:01 AM

marc said:

wow, great work. it's possible that this hels us to resolve a major issue in our project

March 14, 2009 4:54 PM

Chris Dickson's Blog said:

In my previous post in this series, far longer ago than I intended , I showed how the WCF named pipe

December 4, 2009 5:53 PM

Tim Haynes said:

Very interesting article.  What I don't understand is how, if "Everyone" is in the ACL, why I get different results when the server is running as a domain admin or a standard user.

My WCF client is actually a Windows service, running as Network Service (same problem occurs if it's Local system).  My WCF service is a user mode app running in a user session and listening on a WCF pipe channel.  If the user mode app (WCF service) is a domain administrator then it works fine... but if it's a standard domain user (or local user) then the WCF client fails to connect with "The communication object...cannot be used for communication because it is in the Faulted state".

I just don't understand how a different server account can affect it if Everyone has access.  Perhaps I'll try the technique in your later posts to add extra explicit ACEs to see if that helps.

Tim Haynes

July 19, 2010 10:07 AM

chrisdi said:

@Tim Haynes

re "I just don't understand how a different server account can affect it if Everyone has access..."

Are you sure that it's the ACL causing this? The error message you quote is not the one I would expect if ACL permissions were the problem. What is the full exception stack trace? Have you enabled WCF tracing and established exactly where the problem occurs in the WCF stack?

If it is due to the ACL, the obvious explanation would be that the Deny ACE for the Network Users group is denying permission before the Everyone ACE gets tested. Are you sure that the security context in which the client side WCF stack is called does not have Network User group membership?

July 19, 2010 10:33 AM

Tim Haynes said:

Hi Chris,

Thanks forthe reply. I'm not sure it's specifically the ACL, but something security related was the only explanation that came to mind for something which worked as a domain admin, but failed otherwise.  I also don't see how the network deny ACE could be the issue as it works for a domain admin.

It's on Windows 7, so I wonder whether there could be something UAC related going on?

I don't think I'm doing anything particularly unusual, using WCF for IPC from a Windows service to a user tray app for notifications.  I've boiled the problem down to a simple Calculator sample, so it's definitely the named pipe transport causing the problem.  If I change the config to TCP it works fine...but I'd rather use named pipe for more secure local communication and I really don't want to go through all the nonsense of opening windows firewall ports just for IPC.


July 19, 2010 11:39 AM

Tim Haynes said:

Looks like it's not the ACL.  I just found this on Christian Weyer's blog:

If my WCF server process using a Named Pipe-based endpoint doesn't have privileges to create a Global kernel object it silently fails and creates a local one which will not be visible to processes outside of its session."

So I guess named pipes aren't going to be of any use.  A shame that an intended tightening of security has actually had the effect of opening security loopholes as I'll now have to expose my service over a network visible protocol.


July 19, 2010 11:50 AM

Chris Dickson's Blog said:

I’ve mentioned previously the vulnerability to squatting attacks of WCF services using the standard NetNamedPipe

November 3, 2010 10:48 AM

What is the best choice for .net inter-process communication? - Programmers Goodies said:

Pingback from  What is the best choice for .net inter-process communication? - Programmers Goodies

July 6, 2011 5:47 AM

Training : Windows Communication Foundation | Stephen Haunts { Coding in the Trenches } said:

Pingback from  Training : Windows Communication Foundation | Stephen Haunts { Coding in the Trenches }

July 25, 2013 11:05 AM

Leave a Comment

Powered by Community Server (Commercial Edition), by Telligent Systems