File stats for: DCOMbobulator    Last Updated: Size: 29k May 24, 2004 at 13:17 (3,178.94 days ago) Downloads/day: 126 Total downloads: 1,823,368 Current Rank: 5 Historical Rank: 6

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?

Absolutely nothing . . . and that's the point. Somewhere along the bumpy road from OLE through COM to ActiveX, Microsoft's industry competitors began working on a distributed object system called CORBA. Microsoft's object system was not distributed, but as we know, if anyone else has one, Microsoft does too. So Microsoft looked around and 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 you?

Well let's see . . . it attracts Internet worms and permits your system to be remotely compromised by malicious hackers. Other than that, it's of absolutely no practical use other than to adorn Microsoft's "We Have That Too" chart. 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.

What does the DCOMbobulator do?

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 verify the effectiveness of Microsoft's DCOM patch This problem is serious enough that Windows users should have a simple means for verifying that their systems have been safely patched. We have received numerous confirmed reports of systems which were patched but reportedly remained vulnerable to remote DCOM exploitation. It appears that, for some reason, Microsoft's DCOM patch is not always effective. Every Windows user should use our DCOMbobulator to quickly verify the effectiveness of Microsoft's 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: www.microsoft.com/technet/security/bulletin/MS03-026.mspx If that link fails to function, please let us know, then search Microsoft's site for the phrase "MS03-026" to find references and help about this significant security vulnerability.

To 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. Corporate users with network-aware custom applications should check with their corporate IT personnel to see whether DCOM is being used within their organization. If DCOM is ever needed after being shut down, the DCOMbobulator's "Enable DCOM" button will bring DCOM back to life.

Introducing the DCOMbobulator

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:

DCOMbob disable

DCOMbob enable 

DCOMbob verify 

The use of any command-line option suppresses the DCOMbobulator's user-interface display and UI "click" sound, making its operation completely invisible and silent. The "disable" and "enable" verbs result in DCOM being disabled and enabled after the next system restart.

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:

The use of the "verify" verb supports corporate deployment where there's a need to check the continuing effectiveness of Microsoft's DCOM patch.

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 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:

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.

A Note of Acknowledgement: eEye Digital Security

This page would not be complete without a note of acknowledgement to the fine hacking work being done by the folks at eEye Digital Security. Their work is directly responsible for many of the important discoveries of critical Windows vulnerabilities. They are continually and successfully working to make Windows significantly more secure for all of us . . . and that's no small job. (It's certainly bigger than Microsoft.)

Corporate users would be well advised to check out their excellent vulnerability scanning products and services. It doesn't get any better.

Bravo eEye!

That's all there is to it.

You'll find that using the DCOMbobulator is simple, quick, clear, and reassuring. Since all versions of Windows after 95 (and even some Windows 95 systems) have DCOM enabled, tell your friends to visit this page ( www.grc.com/dcom/ ) to download their own copy of the DCOMbobulator so that they can increase the security of their systems and avoid any future trouble with DCOM.