Severe Windows security hole patched

All versions, big trouble

Every version of Windows with the exception of ME (and including the "Trustworthy Computing" engineered Windows Server 2003) has a nasty stuff-up in the RPC (remote procedure call) process, which yields complete system ownership to a third party.

RPC allows a program running on one computer to execute code on a remote system. This can be quite useful, particularly for networked machines sharing a printer over a LAN, say. In the case of Windows, the RPC service listens on port 135 for instruction.

In this case a buffer overflow can cause the preocess to panic in such a way as to transfer ownership of the machine. The actual culprit is a DCOM (Distributed Component Object Model) interface with RPC. In any case, RPC should never be showing itself to the Internet so firewalls for Windows systems should always be set to block port 135. Note that RPC cannot be safely disabled on Windows as it can on *nix. However there are patches now so all is well.

In keeping with its desperate PR inclination to pull "mitigating factors" out of its ass, Microsoft notes that "to exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135 on the remote machine" -- i.e., he needs a computer.

"For Internet connected machines, port 135 would normally be blocked by a firewall" -- because everyone's got one and knows how to configure it.

RPC has been buggy since the day it was born on UNIX and ought to be disabled on any non-Windows machine that doesn't need it. On *nix it's usually available on port 111 (sunrpc), but this is not chisled in stone. If portmapping is active it may find another outlet via UDP ports higher than 32770. You can set your firewall to block TCP/UDP port 111 or, even better, disable the portmapper altogether if you don't need it. It is necessary for NFS (Network File System) and NIS (Network Information Service); otherwise its just a hole. ®

Related Link MS advisory and links to patches