The RPC/DCOM Bugs: How Bad Are They?

Windows & .NET Magazine Security UPDATE--August 6, 2003

1. In Focus: The RPC/DCOM Bugs: How Bad Are They?

by Mark Joseph Edwards, News Editor, [email protected]

You've undoubtedly learned about the remote procedure call (RPC)-Distributed COM (DCOM) bug in Windows by now. If not, you were probably on vacation and returned to what might seem like a crisis. Microsoft released its patch for the problem, which you can read about in "Microsoft Patches Leave Systems Insecure and Break RAS" and "Are You Vulnerable to RPC Exploitation?" in this issue of Security UPDATE. However, users have discovered that the Microsoft patch doesn't exactly fix all the problems.

Users who obtained the "demonstration code" (I use that term loosely) to test their patched systems quickly learned that systems are still vulnerable to a Denial of Service (DoS) attack that crashes the svchost.exe process. One reader informed me that Microsoft has acknowledged that problem and said that it will release a fix.

Microsoft originally reported that disabling DCOM (by using dcomcnfg.exe) and blocking port 135 would mitigate attacks, which is true. However, the company later modified its bulletin to indicate that you must also block port 137 and port 445 because someone can launch an attack against those ports as well. Another reader pointed out that CERT's bulletin [http://www.cert.org/advisories/CA-2003-19.html] about the matter adds port 139 to the list of vulnerable ports. You should block access to all of these ports (UDP and TCP) wherever and whenever possible. Ports can be open on many machines, and it's always best to block everything that you don't need to leave exposed.

Defending against attacks by disabling DCOM might not be a practical workaround either, depending on your network environment. Members of various mailing lists (e.g., Full-Disclosure, Focus-MS) report that you might encounter critical problems with such attempted workarounds.

For example, even if you perform the blocking actions described, you might still be at risk if your Microsoft IIS servers have COM Internet Services enabled. In that case, attacks might be possible against port 80 and port 443. Also, disabling DCOM on your system eliminates the ability of different systems' COM objects to communicate with each other, which has wide-reaching effects.

Microsoft Systems Management Server (SMS) servers won't be able to perform their tasks correctly. Also, after you disable DCOM on a machine, your remote management tools won't be able to access that machine. For example, if you need to reenable DCOM to regain functionality, someone will have to physically visit that machine to turn it back on.

Obviously, patches that correct these matters would provide the best solution. By the time you read this, Microsoft might have released another patch that corrects all the problems. I hope so, because many people are concerned that someone will unleash a worm or virus that could lead to massive DoS episodes--or release Trojan horses that open back doors. Unfortunately, both possibilities are likely and at least one worm, Autorooter, has already been discovered. (You can read about the worm at the Kaspersky Lab Web site. [http://www.viruslist.com/eng/viruslist.html?id=61506]) Other exploits might already have occurred by the time you read this newsletter. If such exploits occur, who will be responsible: the intruders, the people who fail to patch their systems, or the people who release proof-of-concept code? Perhaps all of those groups will have played a part.

In the meantime, you can monitor attack trends at Internet Storm Center. [http://www.incidents.org] The site provides useful information about security risk trends by gathering that information from numerous network sensors around the world. Be sure to check it out.