bindview.lpc.txt

2000-10-04T00:00:00
ID PACKETSTORM:23247
Type packetstorm
Reporter Todd Sabin
Modified 2000-10-04T00:00:00

Description

                                        
                                            `BindView Security Advisory  
--------  
  
Various security vulnerabilities with LPC ports  
Issue Date: October 3, 2000  
Contact: Todd Sabin <tsabin@razor.bindview.com>  
  
Topic:  
LPC ports  
  
Overview:  
There are various flaws in the implementation of LPC ports.  
  
Affected Systems:  
Windows NT4 up to and including SP6a  
Window 2000 up to and including SP1  
  
Impact:  
Denial of service to possible local promotion.  
  
Background:  
  
LPC ports are a mostly undocumented client/server interprocess  
communication mechanism which are used by NT system components.  
Recently, they have been fairly well documented by third parties in  
[1] and [2].  
  
The main method of communication with ports is by passing messages  
from client to server and back. These messages are of the form  
  
typedef struct lpc_msg {  
unsigned short data_len;  
unsigned short msg_len; /* normally data_len + sizeof (struct lpc_msg) */  
unsigned short msg_type;  
unsigned short address_range_offset;  
unsigned long pid; /* process id of client */  
unsigned long tid; /* thread id of client */  
unsigned long mid; /* message id for this message */  
unsigned long callback_id; /* callback id for this message */  
/* unsigned char buff[0]; data_len bytes of data for this message */  
} LPC_MSG;  
  
  
One common usage goes something like this:  
  
Server ()  
{  
HANDLE hPort;  
NtCreatePort (&hPort, "MyPort");  
  
while (1) {  
NtReplyWaitReceivePort (hPort, NULL, msg_receive);  
if (msg_receive->type == connection_request) {  
NtAcceptConnectPort ();  
NtCompleteConnectPort ();  
} else {  
...  
NtReplyPort (hPort);  
}  
}  
}  
  
  
Client ()  
{  
HANDLE hPort;  
NtConnectPort (&hPort, "MyPort");  
while (1) {  
...  
NtRequestWaitReplyPort (hPort, msg_in, msg_out);  
...  
}  
}  
  
(For complete examples, see [1] and [2]. [1] has better examples, but  
[2] has more complete documentation of the individual calls.) Also,  
there will be a proof of concept utility available at  
http://razor.bindview.com/tools which can be used for reproducing the  
vulnerabilities.  
  
The interesting thing about the way ports are used is that although a  
server receives a new handle from NtAcceptConnectPort for each client  
that connects, it usually doesn't use that handle when communicating  
with its clients. Instead, it uses the original handle it got from  
the NtCreatePort call. How then does the kernel know for which client  
a particular reply is intended? It uses the pid, tid, and mid from  
the message to figure out where the message should end up.  
  
There are several problems with the LPC ports implementation.  
  
  
Details:  
  
1. Connection Stealing [NT4 only]  
  
It is possible for any process to call NtAcceptConnectPort and hijack  
port connections. The NtAcceptConnectPort api doesn't require an  
existing port handle to call. All that's required is an LPC_MSG with  
the correct triple of pid, tid, mid. If the correct triple are  
specified for an outstanding connection request, the call succeeds and  
the process is given a handle to the port. It can then process  
requests from that client. Presumably, it could also impersonate the  
client with NtImpersonateClientOfPort.  
  
Note: Win2k has a new API NtSecureConnectPort which allows a client to  
verify that the port's server is running with a particular SID. Also,  
the Win2k version of NtAcceptConnectPort verifies that the calling  
process is the same as the process that created the server port, which  
prevents this attack.  
  
Repro:  
  
start porttool -s \BaseNamedObjects\Foo  
start porttool -c \BaseNamedObjects\Foo  
porttool -s1  
(enter pid, tid, and mid printed by porttool -s ...)  
  
2. Denial of Service -- BSOD [NT4 only]  
  
As described above, when a server process receives a connection  
request from a client, it is supposed to call NtAcceptConnectPort and  
NtCompleteConnectPort to complete the connection. However, if, upon  
receipt of a connection message, the server calls NtReplyPort()  
instead of NtAcceptConnectPort(), then a kernel exception will be  
triggered, resulting in a BSOD.  
  
Repro:  
  
start porttool -s2 \BaseNamedObjects\Foo  
porttool -c \BaseNamedObjects\Foo  
  
3. Spoofed Replies [W2K, NT4]  
  
Using NtReplyPort (or any of the NtReply...Port calls), anyone  
can reply to a waiting client of any server, provided the attacker  
can supply the correct triple of pid, tid, and mid.  
  
Aside from the obvious denial of service problems, there are also  
potential methods of exploiting this to gain privilege. One  
possibility: the ncalrpc RPC protocol sequence uses LPC as the  
transport mechanism. When an RPC client connects to a server using  
this transport, it first resolves which LPC port the server is  
listening on by contacting the RPC portmapper, which is listening on  
the well-known endpoint "\RPC Control\epmapper". By spoofing a reply  
to a portmapper request, an attacker could fake a client into  
connecting to a port which he is listening on, and then impersonate  
the client.  
  
Repro:  
  
start porttool -s \BaseNamedObjects\Foo  
start porttool -c \BaseNamedObjects\Foo  
porttool -s3 \BaseNamedObjects\Foo2  
(enter pid, tid, mid from porttool -s ...)  
  
4. Impersonation of (somewhat) arbitrary processes [NT4, W2K (harder)]  
  
As earlier reported in [3], NT4 was vulnerable to an attack which let  
anyone impersonate any other process on the machine by calling  
NtImpersonateClientOfPort with the target's pid and tid, and a mid of  
0. This worked because if a thread is not making an LPC request, its  
recorded mid will be 0. Apparently the patch which fixes this adds a  
check to be sure that the mid is not 0. This still allows anyone to  
impersonate any process, provided that process is currently making an  
LPC request, and the attacker can supply the proper mid.  
  
W2K has an added check which makes this attack more difficult, but  
still possible under some circumstances. The attack will still work  
on an LPC server, provided that server is in the middle of an  
NtReplyWaitReplyPort call, and the attacker can provide the proper  
pid, tid, mid, and cid. [I don't as yet understand the exact  
circumstances under which a normal server will call  
NtReplyWaitReplyPort. If someone has more info on this, please drop  
me some mail.]  
  
Repro on NT4:  
  
start porttool -s \BaseNamedObjects\Foo  
start porttool -c \BaseNamedObjects\Foo  
porttool -s4 \BaseNamedObjects\Foo2  
[in another window] porttool -c \BaseNamedObjects\Foo2  
(enter pid, tid, mid, cid from porttool -s)  
  
Repro on W2K:  
  
start porttool -s4b \BaseNamedObjects\Foo  
start porttool -c \BaseNamedObjects\Foo  
porttool -s4 \BaseNamedObjects\Foo2  
[in another window] porttool -c \BaseNamedObjects\Foo2  
enter pid, tid, mid, and cid port porttool -s4b. Note that the  
pid and tid in this case are the ones that belong to porttool -s4b  
itself, not the ones it prints from the lpc message  
  
  
5. Reading and writing other processes' address space [W2K, NT4]  
  
Background  
  
Besides the normal method of passing request/reply data in the message  
itself, there is another means by which LPC clients and servers can  
pass data. NtReadRequestData and NtWriteRequestData allow an LPC  
server to read and write to certain parts of the client's address  
space, as specified by the client in the request message. To enable  
this, a client fills out a struct like this:  
  
struct addr_ranges {  
unsigned long num_entries;  
struct addr_entry {  
void *addr;  
size_t len;  
} addrs[N]; /* where N is num_entries */  
};  
  
The client then puts this structure within the data portion of its  
message, and sets the address_range_offset of the LPC_MSG to be the  
offset of the struct in the message, and then makes a  
NtRequestWaitReplyPort () call as usual. Now the server can read or  
write to the specified address ranges with Nt{Read,Write}RequestData.  
  
  
5a. Reading/writing portions of other clients' address spaces  
  
The previous description is how things are supposed to work. However,  
due to a bug, it is possible for one client of a port to use these  
calls as if it were the server, and access areas of memory in a second  
client, provided that the second client is making a call using the  
address_range_offset feature, and again assuming the attacker can  
provide the proper pid, tid, mid.  
  
Repro:  
  
start porttool -s5a \BaseNamedObjects\Foo  
start porttool -c5a-1 \BaseNamedObjects\Foo  
porttool -c5a-2 \BaseNamedObjects\Foo  
(enter pid, tid, mid, cid from porttool -s5)  
  
  
5b. Reading/writing arbitrary areas of other processes.  
  
Through a more elaborate attack, it is also possible for a server to  
read and write arbitrary areas of other processes address spaces,  
whether or not those processes are clients of the server or not.  
  
When a client make a call using the address_range_offset feature, the  
kernel keeps a copy of the request on a list inside the server's port  
object, and then removes it when the matching reply is sent. The list  
is searched based on the mid and callback_id of the LPC_MSG.  
  
The way Nt{Read,Write}RequestData work is the kernel takes the LPC_MSG  
passed in, looks up the thread referenced by the pid and tid, and  
verifies that the thread is currently making a lpc call that matches  
the mid the server specified. Then, it verifies that the server port  
actually has an outstanding request with a matching mid and  
callback_id. It does this is by looking for the MSG on the list  
mentioned earlier.  
  
Now, since the target thread's mid must match some mid on the server's  
outstanding request list, in theory, the server should only be able to  
access its clients' address spaces. However, the mid is only a 32 bit  
integer, so there are only 2^32 possible mids. Once they've all been  
used, they will start being reused, meaning that there's the potential  
for collisions, provided a server doesn't send replies to its clients  
during the time it takes to wrap the mid counter. Testing shows that  
it takes about 21.5 hours on a PII 300 to run through 2^32 mids using  
a client and server that do nothing but request/reply in a tight loop.  
  
So, the attack goes like this: A server starts and listens on a port.  
Then, a client connects to it and send requests to it using the  
address_range_offset feature. The address ranges specified here are  
what the server will be able to access later, so they need to be known  
up front. To increase the odds of a successful collision, the client  
can send several thousand requests to the server. Now, this would  
normally require several thousand threads since the server needs to  
have these as _outstanding_ requests later in the attack, it can't  
reply to them.  
  
However, the outstanding request list is searched by mid and  
callback_id, as mentioned previously, but replies are sent based only  
on mid, so it's actually possible for the server to send a reply to  
the client without having it removed from its outstanding request  
list. Before replying, the server just changes the callback_id so it  
won't match; the reply is sent as usual, but it stays on the  
outstanding request list.  
  
Now, once the server has lots of outstanding requests for later use,  
the attacker does requests/replies in a tight loop until the mids roll  
back to the point where the server has some matching mids. Finally,  
the server specifies the target's pid and tid, and tries every mid  
that it has stored. If it misses, it can try again the next time  
around until it succeeds.  
  
Repro:  
  
start porttool -s5b \BaseNamedObjects\Foo  
start porttool -s5b-2 \BaseNamedObjects\Foo2  
porttool -c5b \BaseNamedObjects\Foo \BaseNamedObjects\Foo2  
(wait until mids wrap around)  
  
start porttool -s \BaseNamedObjects\Foo3  
porttool -c \BaseNamedObjects\Foo3  
  
(in window for porttool -s5b)  
enter pid, tid, mid, cid from porttool -s  
  
  
6. Consuming kernel memory. [W2K, NT4]  
  
As mentioned in 5, the kernel keeps copies of all outstanding LPC  
messages in kernel memory. It allocates memory from an LPC 'zone' for  
these messages. When a message is finished, it's memory is returned  
to the zone and can be reused. If is no memory left in the zone when  
a new request comes in, then additional kernel memory will be  
allocated and added to the zone. Once added to the LPC zone, the  
memory is never released.  
  
Using the trick about mismatched callback ids from number 5, it's  
possible for a rogue server to arrange that none of the messages which  
are sent to it get freed back to the lpc zone. This will result in  
the size of the lpc zone growing continually. Once the server exits  
(or is killed), the memory will finally be returned to the lpc zone,  
but the memory in the zone will never be freed back to the general  
kernel memory pool.  
  
Repro:  
  
start porttool -s6 \BaseNamedObjects\Foo  
porttool -c6 \BaseNamedObject\Foo  
  
  
7. Fragile LPC servers -- BSOD [NT4 only]  
  
If a client connects to either of \DbgSsApiPort or \DbgUiApiPort and  
sends a garbage request, the machine will BSOD.  
  
Repro:  
  
porttool -c \DbgSsApiPort  
or  
porttool -c \DbgUiApiPort  
  
  
Workarounds:  
none known.  
  
Recommendations:  
Install the hotfix(es) from Microsoft.  
  
Limit local logon rights.  
  
  
References:  
  
Microsoft's security bulletin:  
http://www.microsoft.com/technet/security/bulletin/MS00-070.asp  
  
Microsoft's Hotfix:  
NT4: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24650  
W2K: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24649  
  
Microsoft's Knowledge Base article:  
http://www.microsoft.com/technet/support/kb.asp?ID=266433  
(may take a couple days to appear)  
  
[1] Undocumented Windows NT  
http://www.amazon.com/exec/obidos/ASIN/0764545698/  
  
[2] Windows NT/2000 Native API Reference  
http://www.amazon.com/exec/obidos/ASIN/1578701996  
  
[3] BindView Security Advisory on NtImpersonateClientOfPort  
http://razor.bindview.com/publish/advisories/adv_NTPromotion.html  
  
`