Named pipe client and server PIDs
in [Win32 Kernel]
|
Prev: Question about NtfsDisable8dot3NameCreation and Volumes
Next: Determining 'transient' nature of file
From: Corinna Vinschen on 16 Apr 2010 12:36 Hi, Vista/2K8 introduced Win32 functions GetNamedPipeClientProcessId and GetNamedPipeServerProcessId. Is this data already available in older Windows NT kernels and if so, is there a way to fetch this information from user space? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
From: Nobody on 16 Apr 2010 13:33 "Corinna Vinschen" <corinna(a)community.nospam> wrote in message news:hqa3nb$c1r$1(a)perth.hirmke.de... > Hi, > > Vista/2K8 introduced Win32 functions GetNamedPipeClientProcessId and > GetNamedPipeServerProcessId. Is this data already available in older > Windows NT kernels and if so, is there a way to fetch this information > from user space? Not sure if there is a solution pre-vista, but one solution I applied is to use digital signatures without requiring Internet access. The pipe server has a hardcoded public key, while the data sent by the client is digitally signed using a private key that only exists in my computer. There is no need here to use certificates from companies like VeriSign. Any key pair generated by the many tools available will do. Off course, this doesn't work if the data is dynamic, since you would have to include the private key in the client, which could be stolen.
From: Corinna Vinschen on 16 Apr 2010 15:27 Nobody wrote: > "Corinna Vinschen" <corinna(a)community.nospam> wrote in message > news:hqa3nb$c1r$1(a)perth.hirmke.de... >> Hi, >> >> Vista/2K8 introduced Win32 functions GetNamedPipeClientProcessId and >> GetNamedPipeServerProcessId. Is this data already available in older >> Windows NT kernels and if so, is there a way to fetch this information >> from user space? > > Not sure if there is a solution pre-vista, but one solution I applied is to > use digital signatures without requiring Internet access. The pipe server > has a hardcoded public key, while the data sent by the client is digitally > signed using a private key that only exists in my computer. There is no need > here to use certificates from companies like VeriSign. Any key pair > generated by the many tools available will do. Off course, this doesn't work > if the data is dynamic, since you would have to include the private key in > the client, which could be stolen. Thanks for the idea. I don't think it would work for me, though. The client is just another process using the same library, but it could be *any* client, an arbitrary number of them over the lifetime of the server process. What is supposed to happen is that the client process requests handles from the server process. So the client sends its own PID. The server checks if the process has sufficent permissions and, if so, uses the PID to open the client and duplicates the handles. What bugs me is that a client could generate random handles in other, unrelated processes by sending requests with arbitrary PIDs. I don't know how realistic my concern is, though. But if the server knows the PID of the client, the entire problem just goes away. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
From: m on 16 Apr 2010 22:45 IIRC this info is _available_ but there is no way to access it. The best that you can do is to check this on OSes that support that check and don't on OSes that don't. This is the kind of thing that often goes into release notes and users who are concerned about it will ensure that they only run more secure platforms. "Corinna Vinschen" <corinna(a)community.nospam> wrote in message news:hqadn5$e8l$1(a)perth.hirmke.de... > Nobody wrote: >> "Corinna Vinschen" <corinna(a)community.nospam> wrote in message >> news:hqa3nb$c1r$1(a)perth.hirmke.de... >>> Hi, >>> >>> Vista/2K8 introduced Win32 functions GetNamedPipeClientProcessId and >>> GetNamedPipeServerProcessId. Is this data already available in older >>> Windows NT kernels and if so, is there a way to fetch this information >>> from user space? >> >> Not sure if there is a solution pre-vista, but one solution I applied is >> to >> use digital signatures without requiring Internet access. The pipe server >> has a hardcoded public key, while the data sent by the client is >> digitally >> signed using a private key that only exists in my computer. There is no >> need >> here to use certificates from companies like VeriSign. Any key pair >> generated by the many tools available will do. Off course, this doesn't >> work >> if the data is dynamic, since you would have to include the private key >> in >> the client, which could be stolen. > > Thanks for the idea. I don't think it would work for me, though. The > client is just another process using the same library, but it could be > *any* client, an arbitrary number of them over the lifetime of the > server process. > > What is supposed to happen is that the client process requests handles > from the server process. So the client sends its own PID. The server > checks if the process has sufficent permissions and, if so, uses the PID > to open the client and duplicates the handles. > > What bugs me is that a client could generate random handles in other, > unrelated processes by sending requests with arbitrary PIDs. I don't > know how realistic my concern is, though. But if the server knows the > PID of the client, the entire problem just goes away. > > > Corinna > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat
From: Nobody on 17 Apr 2010 10:47
"Corinna Vinschen" <corinna(a)community.nospam> wrote in message news:hqadn5$e8l$1(a)perth.hirmke.de... > Thanks for the idea. I don't think it would work for me, though. The > client is just another process using the same library, but it could be > *any* client, an arbitrary number of them over the lifetime of the > server process. > > What is supposed to happen is that the client process requests handles > from the server process. So the client sends its own PID. The server > checks if the process has sufficent permissions and, if so, uses the PID > to open the client and duplicates the handles. > > What bugs me is that a client could generate random handles in other, > unrelated processes by sending requests with arbitrary PIDs. I don't > know how realistic my concern is, though. But if the server knows the > PID of the client, the entire problem just goes away. There is undocumented way to get the handles for all processes by using NtQuerySystemInformation(SystemHandleInformation), then try to get information about the specific thing you want. Here is an example: http://www.codeproject.com/KB/shell/OpenedFileFinder.aspx Another way to verify a client without using something special is to make the server gets the process ID from the client, then tries to find a window belonging to the client and send it a random number. The client must send this random number to the server through the pipe to verify that it's really the correct process ID, but any DLL can be injected into the client and fool this process. |