An Autonomous Zone

IPC Pipes (especially on Windows) are a pretty interesting topic for me because it has a lot to do with generic object and file security.

First, here’s the definition of a Pipe from msdn: http://msdn2.microsoft.com/en-us/library/aa365780(VS.85).aspx :

A pipe is a section of shared memory that processes use for communication. The process that creates a pipe is the pipe server. A process that connects to a pipe is a pipe client. One process writes information to the pipe, then the other process reads the information from the pipe. This overview describes how to create, manage, and use pipes.

And a little more here http://msdn2.microsoft.com/en-us/library/aa365137(VS.85).aspx :

There are two types of pipes: anonymous pipes and named pipes. Anonymous pipes require less overhead than named pipes, but offer limited services.

The term pipe, as used here, implies that a pipe is used as an information conduit. Conceptually, a pipe has two ends. A one-way pipe allows the process at one end to write to the pipe, and allows the process at the other end to read from the pipe. A two-way (or duplex) pipe allows a process to read and write from its end of the pipe.

So to begin with all pipes are securable objects, so they have specific access rights associated with their DACL entries (much like files).

While looking into this topic a bit a while ago I came across this paper (Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit):

http://www.blakewatts.com/namedpipepaper.html

Here’s some highlights from the paper:

A named pipe is a mechanism that enables interprocess communication for applications to communicate locally or remotely. The application that creates the pipe is known as the pipe server, and the application that connects to the pipe is known as the pipe client. Similar to sockets, after the server creates the named pipe, pipe clients may connect to the server. The function CreateNamedPipe provides the means to create the pipe. Clients use the CreateFile function to connect to the server-end of the named pipe. After the client and server have established a connection, they use the ReadFile and WriteFile functions to communicate.

The way in which named pipes are created and connected to is conceptually identical to how files are created on a file system–that’s no coincidence. Internally, named pipes are implemented as a file system (more on this later). The “file location” of creating and connecting to a pipe follows a standard naming convention. This effectively ensures that the creation and connection requests of pipes are internally routed correctly. That convention is as follows: \\.\pipe\pipename. The \\.\ segment is used to route the creation and connection of the pipe to the appropriate file system. The period in the \\.\ segment may be replaced with a remote system name. This enables the associated function to be invoked remotely.

So the above is just a bit about how pipes work and all that. But we probably need this interesting background info as well before we can really talk a lot about vulnerabilities with pipes – “Named Pipe Impersonation”:

Impersonation is the process of a pipe server temporarily assuming the security context of the client of its pipe. Pipe servers impersonate their client’s security context by calling the function ImpersonateNamedPipeClient. The requirements of impersonation are that a client connects to the pipe server and writes some data to it. After the pipe server reads the data from the client, its call to ImpesonateNamedPipeClient will succeed, and it is granted an ‘impersonation’ token of the client. The requirement of reading data from the pipe can be bypassed, and is discussed in the ‘File System Vulnerabilities’ section.

Some readers may be wondering as to why in the world would impersonation exist in an interprocess communication mechanism. Impersonation and IPC, implemented properly, can actually lead to better-designed software architecture. In its conception, it was created so that privileged subsystems and services could temporally lower their own security context while processing the requests of its clients. However, if implemented improperly malicious applications can attain full control of the system.

So this is really interesting because it leaves room for client attacks:

When a client connects to the server-end of a named pipe it may unknowingly be giving the server-end of the pipe the ability to perform any task on their behalf–by impersonating their security context. Clients can control their impersonation “level” by specifying specific flags in their CreateFile call (which is used for connecting the client to the server pipe), however is seldom performed. This process is formally known as setting the security quality of service. So the question on most readers mind is, “What if the server isn’t started, or has crashed?” Well, the answer is very simple. Their security context is up for grabs. Any security context (interactive user, service, etc.) may create the pipe that the client is looking for and assume their security context. This vulnerability classification is known as Superfluous Pipe Connectivity.

This is really interesting because through named pipe impersonation one can gain the privilege level of the client (if the client didn’t specify an impersonation level in the call to CreateFile() when creating the pipe).

Of course, we’re keeping in mind that “client” doesn’t always mean “lower privileged process.”

This type of attack lead to this (system privilege level) vulnerability (it’s actually a combination of client pipe and pipe namesquating):

Service Control Manager Named Pipe Impersonation Vulnerability (http://www.microsoft.com/technet/security/Bulletin/MS00-053.mspx)

There’s also vulnerabilities that were discovered like these:

http://secunia.com/advisories/9229/ (SQL Server Named Pipe Privilege Escalation Vulnerability)
http://www.microsoft.com/technet/security/Bulletin/MS01-031.mspx (Telnet Server Named Pipe Privilege Escalation Vulnerability)

The paper also says this:

Coaxing an application or service into connecting to a pipe is usually trivial in most situations. For instance, when starting a service, the service will typically connect to another service’s named pipe. A monitoring tool, such as Security Internals’ Pipe Security Explorer, will yield all the named pipes that an application or service connects to. It is probable that some pipes will not exist. If a client application attempts to connect to a server pipe without verifying that the server is running and has created the corresponding named pipe, it’s possible that at some point in time the client’s security context may be usurped by a malicious application.

Cheers,

Chuck B.