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:

• Is rpcss.exe a Trojan horse? No. It's a server that provides RPC capabilities to the Windows operating system.
• Is rpcss.exe a security hole? The program itself is not known to be a security threat. However, like its UNIX brethren, it does provide a gateway through which security holes in programs that use it can be exploited. RPC, like most other IPC protocols, is only as safe as the programs that utilize it.
• Can rpcss.exe be exploited by a malicious software author? Yes, but again, this has nothing to do with the program and more to do with what it does (namely, providing an IPC service). However, a smart author won't use it and will instead use "quieter" and lower bandwidth methods to keep his software hidden. A dumb author will probably be unaware of its existence. Either way, its abuse potential is pretty low.
• What could an exploit using rpcss.exe do? On Windows 9x, if the author could plant a program that registers itself with the portmapper (rpcss.exe) and communicate with it remotely, it would have unlimited access to the machine. In other words, you'd have a full-blown Trojan horse on your hands, albeit one that would be very easy to detect. On Windows NT/2000, the program would probably have to be a service and its powers would be limited based on the account under which it runs. In all likelihood, it would have to be installed by a member of the Administrators group to have any effect at all, although a lesser program (spyware, perhaps) could load itself for each user and register itself with the portmapper. In the end, RPC simply provides a conduit by which clients can execute predefined code on a server. Of course, a nasty programmer could conceive of a way to execute arbitrary code using RPC, but that's an exercise left to the reader (hint: think assembly language).
• Should rpcss.exe be deleted? No. Under Windows 9x, a program may need it to communicate with other components of itself. Of course, you could delete the program, but various unpleasantries could result. Under Windows NT/2000, deleting this critical system component will disable your OS (although I believe Windows 2000's system file protection service will automatically replace it with a backup).