xp dcom launcher useful or not?

Hello;
Merry Christmas to everyone.

Could anyone tell me if the xpSP2 service "DCOM server processes launcher" is to be set on "automatic"? If so, why?

Asking this because I set it on "disabled" and can't see any trouble on my system right now, but I'm afraid maybe I set something bad in motion by disabling it !?

Cheers

 

Bart Fan, I am not advanced user but I can tell you that they have a program made just to disable DCOM because of it's security risk, it is called Dcombobulator. Go to theeldergeek.com, it will give you a thorough rundown of services you don't need running. I'm sorry I can't remember where the article is but there is an article that dicusses how dcom is just something useless that microsoft has just to say they have it, something along those lines. If you search you will find this article, but whatever you do make sure you go to theeldergeek.com, they will help you be sure about all your services as well as many other articles that might be helpful. Just look for the xp services section.

 

Just to avoid any confusion.....the Dcombobulator is available from Steve Gibson's site:-

http://www.grc.com/dcom/

Regards eyes-open

http://smilies.sofrayt.com/%5E/i/santa2.gif

 

Hi guys

Thanks for your answers.

In fact, I already have Gibson's DCOMbobulator installed and running, and also WWDC, and also safeXP. With all these ["cross-layered defence !? ], the DCOM was already deactivated.

BUT: to my great surprise, I found in the Services list that the "DCOM server process launcher" was still activated and running. So my guess is that these are two different processes: "DCOM" is different from "DCOM server process launcher".

And I plain don't know why Steve Gibson's soft, for instance, would take care deactivating DCOM while leaving DCOM server process launcher alive and running.

So I deactivated DCOM server process launcher by hand, which led to my question in the previous BartFan post.

Any ideas?

 

I think Diskeeper v10 NEEDS DCOM

 

I also found this:
http://www.theeldergeek.com/dcom_server_process_launcher.htm
which states that the DCOM launcher should be kept on automatic, but I can't find any understandable reason why, nor does my computer seem to suffer for now...

What to do, since I do like to heave as few running services as possible, provided my machine is in good shape and secure...?

But I ain't sure about that one.

Helllllpppppp

Cheers

 

Bart Fan,
DCOM and DCOM server process launcher are supposed to be the same thing, if you have two different DCOM services running then I am unfamiliar with this and I do not believe this should even exist and should be thoroughly investigated. As for software you bought to disable DCOM, why send a boy to do a man's job if you are able to do it, you are. I know you can go to control panel/administrative tools/services and disable DCOM, and server,and terminal services,and remote desktop(netmeeting too), and tcp/ip over net bios, and distributed link transaction(both of them). Does theeldergeek say to leave DCOM on automatic? Dude said diskeeper uses DCOM, if you don't have that program and you run through everything and find that you aren't kept from doing anything that you could do before then forget about leaving DCOM enabled as it has been labeled by many professionals on another level we haven't reached yet to be a security vulnerability. I am sorry for the original incorrect information regarding theeldergeek's stand on DCOM but it is possible that I took the stance on DCOM from an even better "services running on xp" site which was called "Black Viper", I don't believe this site still exists though or I would have pointed you in this direction.

 

I agree this is strange, especially since my system has been built step by step from a fresh install, meaning I always make an image of my system, and only sparely add anything before doing another image...

Yeah, I see the point But I didn't buy anything:Windows Worm Doors Cleaner, SafeXP and DCOMbobulator are all freeware.

Yes, I hear you...

Hmmm, interesting...
Thanks for your advice

Cheers

 

Strange...
I completely trust Steve Gibson and his tools, among which DCOMbobulator.

Running DCOMbobulator on my system works, too: if I enable the service and do the local test, I'm found vulnerable. If I activate DCOmbobulator again, I'm labeled "safe". But all this doesn't have any effect on the DCOM launcher in the services list, which stays as I hand-put it !

 

BartFan,

Excuse the lack of detail's here because I'm not exactly sure how closely the launcher itself is intertwined within the main DCOM architecture, but am aware there were significant changes implemented to access permission's and launch right's with the deployment of SP2. The service you question may be set to manual until required for XP's own defragmentation feature, started manually before use. The one other area in which you may experience problem's on SP2 is with the Windows Firewall Service.


GF

 

GF, Its important to note that some programs i.e AV, Firewall may need Dcom to work correctly or other 3rd party system components, so check first before disabling this service, T

 

See this link:
http://www.experts-exchange.com/Security/Q_21590673.html

"shutdown the DCOM Server process launcher under services"

You think that's a good idea?

Read this: http://support.microsoft.com/default.aspx?scid=kb;en-us;892504

"If this service is not started, any DCOM-related services cannot start. Therefore, the Windows Firewall Service cannot start if the DCOM Server Process Launcher service is not started. This is because the Windows Firewall Service requires the DCOM component. Other services such as the Network Connections service and the COM+ Event System service are also dependent on the DCOM component."

and this: http://www.greatis.com/appdata/n/d/dcom server process launcher service (dcomlaunch).htm

"DCOM Server Process Launcher service (DCOMLAUNCH) - Necessary"

Necessary, it seems!

And here's another important fact: http://forums.pcworld.co.nz/archive/index.php/t-55370.html
"In SP2, the service "DCOM Server Process Launcher" must be running if you wish to use to use the defragger. If not, it will start, but when you click analyse or defragment, nothing will happen. So you must either leave this service set to automatic, or set it to manual and start it yourself when you wish to defrag. Note, running the defragger won't start it in manual mode."

Whew! Better leave everything as it is, especially if you are not one of those network freaks who know everything ;-)

 

I have both the windows firewall and COM+ event system disabled. I don't see DCOM server process launcher listed as a service that Network Connections service is dependent on. But the prerequisite services are not always listed.

If that's the case, you can set DCOM to manual and it should turn on the occasions you want to do a defrag.

I still have my DCOM server process launcher set to Automatic but one of these days, I'll turn it off to see if it does affect the Network Connections service. The worst that can happen is that I'll need to turn the service back on and reboot.

 

Brinn,
Microsoft says DCOM could effect network connectivity because they want you to have port 135 open to broadcast yourself on the network(it even states that is how you close port 135 on the link you refer to{experts exchange}, it in no way effects your connectivity. If you want to pariicipate in broadcasting your presence online, go ahead, I'll pass and I try to keep other people with the same security awareness I have. Also, I don't consider built in windows firewall something to even be concerned about, in my opinion if you want to be secure why would you depend on something that only blocks incoming and part of it's name even says internet-connection-sharing. In case you haven't noticed Bill Gates makes everything for convenience to newbies, he's in no way concerned about security when he puts out products, microsoft leaves 0days unpatched for weeks even months, and only when pressured do they release a patch that usually requires a patch for that patch. I'm not saying don't listen to microsoft, no, learn everything you can about windows from their site, but check everything on your own with security experts outside microsoft, don't be a duck. As for defragmentation I will admit you are probably right, thing is I don't go long enough without Darik's Boot and Nuke to have to touch any defrag process. You should read links thoroughly when posting though, like I said earlier it clearly states that disabling DCOM will close port 135, in turn helping to prevent it showing up on port scan. So if you want to let your system get built up with enough junk to even have to defrag and then leave DCOM on it's all you, I'm going to share what I think will keep folks one step ahead of a cracker.

 

@emir & BartFan

Here's a link to the archived page of

http://web.archive.org/web/20041128084144/http://www.blackviper.com/WinXP/servicecfg.htm

If you are running XP(SP2) other than on a 'Bare Bones' system basis, he was recommending the service be set on Automatic.

PS. Note the links on the page aren't active due to the archive nature of the page.

 

http://www.symantec.com/avcenter/venc/data/w32.bobax.c.html

When W32.Bobax.C is executed, it performs the following actions:

Creates a mutex "06:08:07:<random numbers>", where <random numbers> is a series of random numbers based on the volume serial number of the infected system. This mutex ensures that only a single copy of the worm is present in memory.

Copies itself as %System%\<random_characters>.exe, where <random_characters> is a random number of random characters.


Note: %System% is a variable. The worm locates the System folder and copies itself to that location. By default, this is C:\Windows\System (Windows 95/98/Me), C:\Winnt\System32 (Windows NT/2000), or C:\Windows\System32 (Windows XP).

Adds the value

"<random_characters>" = "%System%\<random_characters>.exe"

to the following registry keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
RunServices


Attempts to delete all files in %temp% that begin with "~".

Drops a randomly named .tmp file into the %Temp% folder. This file is actually a .dll file that contains the worm's main functionality.


Note: %Temp% is a variable. The worm locates the temporary folder and copies itself to that location. By default, this is C:\Windows\TEMP (Windows 95/98/Me/XP) or C:\WINNT\Temp (Windows NT/2000).

Injects the .dll file into Explorer.exe and then ends its own <random_characters>.exe process. This may cause Windows Explorer to stop working.


Attempts to download one of several files from various Web sites to gauge the speed of the internet connection of the host computer.


Attempts to contact a remote Web server with a unique ID code, and some information about the infected host, as notification of infection. The worm parses the response for commands to activate, which include the following:
Sending spam mail
Sending system information to the author
Stopping and restarting scanning
Downloading and running a specified executable
Updating itself

Scans randomly generated IP addresses, attempting to connect to them on TCP port 5000. This will determine whether the system is a Windows XP-based system (see Microsoft Security Bulletin MS01-059). The worm then probes port 135 of the remote computer to verify that the RPC DCOM interface is available.

If the worm determines that the remote system is running Windows XP, it performs the following operations:
Sends shell code to the host on TCP port 445, attempting to exploit the Microsoft Windows LSASS Buffer Overrun Vulnerability, which is described in Microsoft Security Bulletin MS04-011.
If this exploit does not succeed, the worm sends data to TCP port 135 in an attempt to exploit the DCOM RPC vulnerability.
If either exploit is successful, the code that is executed on the remote computer uses HTTP to force a connection to the host computer on a random port.
Downloads the worm from the host computer and saves it on the remote computer as Svc.exe or as an executable file with a .gif extension.
The worm is executed on the remote computer.

If the worm determined the remote computer was running Windows 2000, it would only attempt to exploit the DCOM RPC vulnerability, as in steps b through e.

Notes:
A side effect of this exploit is that it eventually crashes the LSASS process, forcing the computer to restart. This is similar to the effect of W32.Sasser.Worm.

Due to the random nature of how the worm constructs the exploit data, this may cause the RPC service to crash if it receives incorrect data. This may manifest as Svchost.exe, generating errors as a result of the incorrect data. If the RPC service crashes, the default procedure under Windows XP and Windows Server 2003 is to restart the computer. To disable this feature, see step 1 of the Removal Instructions.
10. Opens a number of randomly selected ports and awaits incoming connections. The worm runs its own SMTP server routine on these ports, leaving the infected computer open to be used as a spam relay.







Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":
Turn off and remove unneeded services. By default, many operating systems install auxiliary services that are not critical, such as an FTP server, telnet, and a Web server. These services are avenues of attack. If they are removed, blended threats have less avenues of attack and you have fewer services to maintain through patch updates.
If a blended threat exploits one or more network services, disable, or block access to, those services until a patch is applied.


http://grc.com/dcom/

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.


http://www.computerworld.com/securitytopics/security/holes/story/0,10801,83619,00.html


Although the original DCOM RPC exploit code worked only on machines running English-language versions of Windows 2000, recent modifications show that the code has been modified to exploit the same vulnerability on French, Chinese, Polish, German and Japanese versions of Windows 2000, XP and NT.

RPC is at a stage similar to that of a widespread Microsoft SQL vulnerability after exploit code for that vulnerability was published in August 2002 by David Litchfield, a security researcher at U.K.-based Next Generation Security Software Ltd., according to Ullrich. That exploit code was later modified to create Slammer, one of the most widespread worms to exploit disclosed vulnerabilities.

In its present form, the DCOM RPC exploit code probably isn't ready for wide distribution as a worm, according to Ostwald. The code isn't fully developed and often relies on variables such as the presence of particular versions of Windows to work, he said.

In contrast, Last Stage of Delirium developed so-called proof-of-concept code for use internally that works against a wide variety of Windows platforms and requires only the Internet Protocol address of the vulnerable machine to create a buffer overflow, Ostwald said. Such code would be "very useful" to worm writers, making it easy for a worm to spread from machine to machine, he said.

Hackers are also working on shrinking the exploit code, narrowing the exploit to work on a small set of sytems that will net the most compromised machines, Ullrich said.

 

I'll probably shut it down. I've run Steve Gibson's DCOMbobulator and my firewall blocks access to and from it. I've just never dealt with that particular service before.

 

Okay, I have the service set to manual and nothing's blown up yet. As expected, Windows defrag isn't functional with it off. I hoped DCOM launcher would turn on like some other services could when needed but it didn't. So I took this time to download a third party defrag app. I chose Diskeeper 7 after a short search (it's free). Curious thing, though. It needed DCOM launcher active to install but not to run.

 

Microsoft Security Bulletin MS01-059 - December 20, 2001
Microsoft Security Bulletin MS04-011 - April 13, 2004​

To BartFan/other's,

I'll attempt to keep all additional info surrounding DCOM relevant, current, and as it applies to XPSP2.

Hey, nothing's perfect!

*One comment I'd like to correct/modify is that leaving DCOM Launch set automatic should work fine for the majority of average user's under SP2. If, like BV and other service guru's around state, power user's should have no problem running a minimal, *bare bone's* services configuration.


GF

 

Hey Brinn, did you make out alright firing up that service again? COM permission's?

GF

 

Okay, I've figured it out. When I installed Diskeeper, it needed DCOM launcher to run initially. After that, it ran its own service, dkservice.exe, to replace the function of DCOM launcher. Basically, there's no net gain in terms of shutting down unneeded services. I've traded one for one (I've disabled DCOM after the install). I'll take it, though. Diskeeper 7 is a nice little defrag app.

 

As a further update, having the DCOM service shut down caused a pop up whenever a Word document is opened which says, "This document could not be register. It will not be possible to create links from other documents to this document." I'm not sure what this means but if it becomes necessary, all you have to do is set the service to Automatic and reboot.

I also wrote a little .bat that starts up dkservice.exe along with diskeeper so that the service is not running when I don't need to do a defrag. That's one less service I have running.

 

I don´t know why but I have it set to "automatic", if it doesn´t give any problems I will disable it. And btw, in Samurai I have enabled the setting "Disable RPC based DCOM", so far without any problems.

More info: