When running one of my exe I get the following Defense+ warning:
“ioUrbanTerror.exe could not be recognized and it is about to access the protected COM interface C:\Windows\System32\svchost.exe. If ioUrbanTerror.exe is one of your everyday applications, you can allow this request.”
If I globally allow Protected COM Interfaces for my exe, the warning no longer appears. OK.
Instead if I wish to allow only this interface, the only way is to add a new “COM Component” named “C:\Windows\System32\svchost.exe” because svchost.exe is not in the Comodo list of Protected COM interface.
For sure svchost.exe is not a COM interface itself.
I’m wondering where the issue is.
Is it only an incorrect warning message (it should display the real interface name) or is there something more serious? :-\
My second sentence meant: Answering in the question window is easier than to make rules somewhere else.
If i choose “allow and remember” for specific questions, only the things are allowed which are in the window.
Question: D.exe tries to do this.
My answer: Allow, remember my answer.
Everything else would still be asked.
If you do the same as i described, but the D.exe would be allowed then to do anything except running something else, then you somehow give it “trusted” permission in the list. This is a setting problem.
I use safe mode for defense+ (or paranoid mode).
Btw, i looked in the defense+ rule set. Svchost is under the predefined rule category “windows system applications” automatically. These application rule contains all the rights apart from “execute something else”.
I use Defense+ in Paranoid mode for 2 years.
“Create rules for safe applications” option is activated.
My trusted vendor list contains Microsoft entries and nothing else. Anyway, this list should be ignored in paranoid mode.
I confirm your scenario is the one I follow.
I confirm what I wrote: all access rights are allowed (except Run an Executable).
I’ve looked for settings which could impact but haven’t find anything obvious.
I think it’s a different behavior compared to previous version (but I didn’t check).
Do you see svchost among the entries of the predefined rule category “windows system applications”?
In the defense+ list of all rules.
If you see svchost among these entries, then svchost will have all permissions apart from “start something else”. Like all the other entries of that category.
You can review the permission of this category by clicking “predefined rules” tab above that defense+ list.
Btw, why do you activate “create rules for safe applications”, if you run paranoid mode? Shouldnt it be effectively inactive while using paranoid mode anyway?
You confirmed, all access rights are allowed. Of which program? If another than svchost, lets know which.
Or if my words do not cover your problem, try to define it more specific
A bug that i reported back in may 2011, it all started in the 5 series of cis, even if you remove all the protected com interfaces entries you will still get alerted.To me it seems like a memory access alert but intercepted wrongly by d+. I guess 99% of users don’t use paranoid mode but it’s a really annoying bug when using paranoid mode.
This happens when your program ioUrbanTerror.exe wants to make DNS-request, operating like DNS-client and if is running DNS-client service(svchost(Dnscache)). If you stop and disable DNS-client service then you will get another warning message from CIS: ioUrbanTerror.exe wants to connect to the Internet to the UDP 53 port. You can create a predefined policy such as DNS-client in Firewall settings and choose it for such requests(as I have made for example).
I don’t think that this is a good idea, because if some program wants to make a request as DNS-client you must see it. And if svchost(Dnscache) is working and you allow by default to ALL application access to it then any application can without any alerts from Comodo connect by UDP on 53 port. Because we by default have an allowed rule for svchost.exe in Firewall Rules, we need it for example for windows’s updating.
If DNS-client service is stoped then you will get warnings from Firewall(see above). In this case for known applications you can create a rule in the Firewall Rules: Allow OUT UDP to 53 port to your DNS-severs. Any unknown application must be controled for such requests.
I think this is not a bug, this is how WinSock API function gethostbyname and similar works. At first it try to make a DNS-request through svchost and if it stoped then it try to connect directly by UDP on 53 port. So this request to svchost from application is interpreted as access to COM-interface.
For dns request you get a different alert anyway, something like application is trying to access the DNS/RPC client.
As you can see from his quote, you can’t add svchost.exe as a com interface because it’s not one.
Also it’s not just svchost.exe you get alerted about it could be any executable which is clearly a bug.
Yes and this is too. I attached 5 screenshots, where you can see how an application gethostbyname.exe operating like a simple DNS-client treated by Comodo. DNS-client service is turned OFF.
And you can see on screenshot #6 an accessing of gethostbyname to COM interface svchost.
This is not a bug. I explained your above how WinAPI calls work. If an application don’t use WinSock API functons such as gethostbyname you will not get an alert from Comodo about access to svchost COM interface.
my exe ioUrbanTerror.exe is allowed by the firewall part
among the 6 activities that can be monitored by Defense+, I only monitor 5: the “DNS/RPC Client Service” activity is unchecked in my config
About your image ghbn6.png: it’s indeed the message I receive.
Don’t you think this message is weird?
Indeed %windir%\system32\svchost.exe is not a Defense+ “protected COM interface”
Moreover, svchost.exe can host a lot of other things than DNS client.
So allowing svchost.exe as a whole looks like allowing all the COM interfaces implemented in all services running in svchost.exe.
Lack of control, no?
So one can allow the first 4 safely … requests to the Windows Socket Interfaces, DNS/RPC Service & the Firewall for common applications (e.g. browsers) and Block the last “Access COM Interface” of svchost.exe?
since that would open the Pandora’s box…
