|Written by: Patrick Chipman < >|
Created April 17 2001, modified April 17 2001
Coming from a heavy Windows NT development background, I can shed some light on what rpcss.exe is actually doing. RPC is short for Remote Procedure Call; it is a means by which two programs can call each other's publically available procedures over a network, and is nothing new (in fact, UNIX systems have had this in sunrpc/portmap for years). While RPC is not, by its nature, connected to any particular service and a program can handle RPC on its own, the Win32 API upon which Windows NT and 9x are based provides a series of RPC function calls which are handled by (you guessed it!) rpcss.exe. Originally, Windows 9x's Winsock service didn't provide RPC, so rpcss.exe was redistributed with the new Winsock that comes with newer Microsoft applications.
In any event, what rpcss.exe does is to handle a number of API calls that relate to RPC. In general (and this is somewhat of a simplification to prevent techie talk overload), a program can register certain entry points (the "procedures" in remote procedure call) that can be accessed by external applications. This is known as the "portmapper" function. Once registered, anyone contacting the RPC port and asking, in the appropriate format, for a particular function provided by a particular program will be allowed to execute the function. Any security checks are up to the contacted program, as all the portmapper does is to make the necessary procedure call on behalf of the client.
"WAIT JUST A MINUTE," you scream as your face turns red. "You mean ANY program can ask ANY OTHER program on MY MACHINE to do something for it WITHOUT MY KNOWLEDGE?" The sad truth is that, yes, this is true, and yes, this has been a constant source of security flaws in UNIX systems as such-and-such RPC service has this unchecked buffer or that improper security check which allows any remote user with the proper script to gain full control of the machine. Since no such flaws have been found in the rpcss.exe portmapper proper -- probably because no one's really looked -- the real threat comes from the programs that utilize the portmapper. Unlike UNIX, however, very few Windows programs use RPC; hell, most Windows 9x programmers aren't even aware that RPC exists, and RPC as a direct communications method is being replaced by DCOM and COM+ (which can, but do not necessarily, use RPC) in Windows 2000. Therefore, the likelihood of you even having a portmapped program on Windows 9x is extremely low, and thus the risk that RPC presents is also quite low.
On Windows NT/2000, the situation is somewhat different. One of the nice features of the operating system is the ability to remotely administer machines. All of these features -- and, in fact, all of the administrative tools and, really, all communications between services and the user -- are based on RPC and flow through rpcss.exe. The intimate connection between services and their front-ends using RPC means that the operating system requires RPC, even more so than a UNIX OS. If you doubt this, simply try a test: open up Task Manager, click the Processes tab, and kill rpcss.exe. The fact that you usually get an Access Denied error is very telling about the importance of this metaservice to the machine. If you do manage to kill it (lucky you) or accidentally crash it, you'll notice something interesting -- namely, that you cannot use the network, that most control panels do not work, and that none of the administrative tools work either. This is the direct result of Windows NT being a client-server operating system; due to this, a standard means of interprocess communication between userspace and kernelspace is required, and Windows NT's designers chose to make this linkage through RPC. The upshot of all of this is that, as has been stated before, rpcss.exe is critical to operation of Windows NT. Deleting it will completely disable your system -- or at least severely hamper it. (You can, of course, use your Emergency Repair Disk, your Setup boot disks, and the CD to recover the file using the Repair option in setup, assuming you haven't installed too many service packs.)
Knowing all of this, some might be wondering about the possibilities of spyware or other Trojan horses using RPC to perform tasks for their nefarious masters. While this is certainly a possibility, it is pretty unlikely for two reasons. First, as I mentioned before, RPC is a UNIX form of interprocess communication and is really only used by Windows NT programmers. As a result, the average spyware author is probably unaware of how to use it or unaware of how to use it properly. Second, RPC is a very noisy protocol that uses a lot of bandwidth. The above-average Trojan horse authors will not use RPC for this very reason, as a well-trained eye watching a network monitor can easily spot RPC traffic and such traffic is easily deciphered. In addition, many firewalls block RPC traffic anyway, just in case you happen to be running UNIX behind the firewall.
So, to sum things up in Q&A format: