|The strange history of DCOM
Many years ago, Microsoft began modularizing Windows and their Windows 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 sexy name “ActiveX”, and built it into virtually everything, that developers finally gave up trying not to use it.
What does all this have to do with you?
What does DCOM do for you?
their DCOM patches and finally turn DCOM off.
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.
I created the DCOMbobulator to perform two tasks:
to quickly verify the effectiveness of Microsoft’s
DCOM security patch, then completely disable
DCOM for greatly enhanced security.
Click this link, or the image above, to download
our 29k byte “DCOMbobulator” utility program.
|Getting Yourself DCOMbobulated
Download and run our small (29 kbyte) “DCOMbob.exe” utility. It will display the “DCOMbobulator?” information page to explain its operation, with two additional page tabs as shown in the screen shot above: “Am I Vulnerable?” to test the current state of your system’s DCOM facility and “DCOMbobulate Me!” to allow you to disable or re-enable DCOM as you choose.
The DCOMbobulator supports three command line options which can be useful for operation from corporate logon scripts or batch command files:
The “verify” option instructs the DCOMbobulator to verify that the system being tested is not vulnerable to the known remote DCOM exploit. If the system’s DCOM facility is either disabled or patched, “verify” will check this and exit silently. But if the system is vulnerable — with DCOM both running and unpatched — the following dialog will appear on the user’s display:
Under Windows 95/98/ME, disabling DCOM with the DCOMbobulator will close port 135 since the Windows 98/ME task scheduler does not use port 135 and those systems don’t have the Distributed Transaction Coordinator.
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:
That’s all there is to it.