DCOMMicrosoft's DCOM security patch leaves DCOM running, open, and waiting for malicious exploit.
DCOMbobulator by Gibson Research Corporation is a 26 bytes application that allows any Windows user to quickly check their system's DCOM vulnerability, then simply shut down the unnecessary DCOM security risk.
The history of DCOM: Many years ago, Microsoft began modularizing Windows and their applications by breaking them into functional components with well-defined, "version safe" interfaces. The idea was to allow pieces of Windows and applications to inter-operate. The name first given to this effort was
OLE, which stood for Object Linking and Embedding. OLE suffered nearly terminal birthing pains and developed a reputation for being a bad idea. Undaunted, Microsoft renamed it
COM for Component Object Model. This was still the same old OLE, but Microsoft appeared to hope no one would notice. COM fared somewhat better, but it wasn't until Microsoft gave it the name
ActiveX, and built it into virtually everything, that developers finally gave up trying not to use it. Sometime after, Microsoft's industry competitors began working on a distributed object system called
CORBA. Microsoft's object system was not distributed, but as we know, Microsoft quickly stuck a "D" (for Distributed) in front of COM to create
DCOM, their Distributed Component Object Model. Then they crammed it into every version of Windows starting with Windows 98, even though no one needed it, wanted it, or was using it. That way they could say Windows already had a distributed component system built in.
What does DCOM do for the user?: It attracts Internet worms and permits your system to be remotely compromised by malicious hackers. There may be some custom corporate application developers who have managed to make some use of it, but mostly no one ever has. Nonetheless, it's there in Windows so that the competitors' CORBA isn't. DCOM serves no practical purpose for almost anyone and, as the entire world now knows, it creates a huge and unwarranted security risk. Therefore, it's crazy to leave DCOM running. Microsoft's DCOM vulnerability patch does fix this latest problem with DCOM. But this was not the first problem with DCOM, so there's little support for the hope that this was the last problem.
What does the DCOMbobulator do? The DCOMbobulator will help everyone to perform two tasks:
1) Verify the effectiveness of Microsoft's DCOM patch. Even though DCOM should be shut down altogether, Windows systems need all the security they can get. So verifying that the known DCOM vulnerability is not still threatening any Windows systems is important. For information about Microsoft's DCOM vulnerability patch, please see this page on
Microsoft's site or search Microsoft's site for the phrase "MS03-026" to find references and help about this significant security vulnerability.
2) Shut down DCOM completely. Since no typical Windows user has ever needed to have DCOM enabled, it should be shut down immediately and disabled (after first making sure that it's safely patched when it's enabled and running). The DCOMbobulator makes this as easy as pressing a single "Disable DCOM" button. You can then restart Windows and verify that DCOM has been safely taken out of service.
Closing TCP Port 135. Three systems within Windows NT/2000/XP/2003 share TCP port 135: DCOM, Task Scheduler, and Distributed Transaction Coordinator (MSDTC). Since running any of these services will hold TCP port 135 open to accept incoming connections, they must all be stopped and disabled in order to close port 135. The DCOMbobulator disables and "unbinds" DCOM from port 135, but it does not take any responsibility for dealing with the other two services.
Under Windows 95/98/ME, disabling DCOM with the DCOMbobulator will close port 135 since the Windows Task scheduler does not use port 135 and those systems don't have the Distributed Transaction Coordinator.[/me]
Any personal firewall or NAT router will isolate a system's open ports from external intrusion, so leaving port 135 open is not a problem if your system has additional intrusion protection in place. At the same time, the best security is obtained with multi-layered security where each layer is as secure as possible. If you can determine that you do not need the Windows Task Scheduler, or that you can live without its services, you can probably arrange to completely close your TCP port 135.
MSDTC — As with DCOM, typical Windows users have no need for the Distributed Transaction Coordinator service. If it is running, it can be stopped and disabled without any negative impact on the system. But unfortunately, as we'll see, the same may not be true of the Windows Task Scheduler service: Task Scheduler — Users of Windows XP who wish to use XP's "Prefetch" system for startup performance enhancement must leave the Task Scheduler running. Many people also depend upon Task Scheduler for timely anti-virus and other updates. For these reasons it may not be practical for you to shut down and disable the Task Scheduler. However, I wanted to provide the information for users of other Windows versions who care enough about permanently and finally closing port 135.
