CFP - on default interactive security mode, you will get only one pop up that is execution of dll/ vmx file by rundll32. If u allow it, no more pop ups and malware is free to do all its actions. CFP however did label it as suspicious via file heuristics.
I wonder what if some one just allowed the execution of vmx file by mistake. No second chance in this case! Hmmm… I don,t feel so good.
My thread is here.
[attachment deleted by admin]
This problem is because rundll.exe is a trusted application and one it has permission to run the dll the dll has all the permissions of rundll.exe. I have a global defence+ rule forbidding running dlls from untrusted locations (including removable drives) but this takes some setting up and is too complicated for the average user.
rundll32.exe is not whitelisted.
Anyway IMHO this test show once again that D+ already has Heuristics (something that was questioned few times).
As for the rest the only tested software that did not receive a 
remark was geswall although it looks like it needed custom rules.
Did geswall rate that file as suspicious? I looked at that topic in a hurry.
I don’t think that’s fully correct, otherwise D+ would be totally useless if you allow explorer.exe to run suspicious programs.
Or is rundll32.exe an exception?
@aigle: The config profile of Comodo was the proactive one (maximum protection)?
[/quote]
Actually I did not mean a comparison between the two as the two are different types of software and I use both of them.
GesWall has no fearture of labelling a file as suspicious or not and being a sandbox it doesn,t need that feature.
Yes. It was proactine one.
It looked also like GesWall doesn’t even catch it by default though.
CFP - on default interactive security mode, you will get only one pop up that is execution of dll/ vmx file by rundll32. If u allow it, no more pop ups and malware is free to do all its actions. CFP however did label it as suspicious via file heuristics. PASS though I am not so happy about this pass.
Whereas CIS was simply tested using its default configuration. ???
and the same user who is able to configure GesWall (but not D+) is assumed even to overlook the D+ alert with explicit warning due to heuristic analysis.
You are making a wrong comparison, i am not comparing CFP with GesWall. GesWall is supposed to isolate certain infection vectors only, like ur browser, mail etc and it does that pretty good without pop ups.
CFP on the other hannd monitors each and every part of system and is supposed to catch a malware even if it allowed to run. As far as suspicious alert is concerned, practically I get that alert much more commonly for bening legit files infact.
Being a classical HIPs with complex parent child relationship for executables, it,s too chatty. So I have tweaked rules( while keeping paranoid settings) to get the minimum of alerts. I will give u examples:
1- I allowed svchost.exe to creat any file anywhere otherwise I get too many alerts about it creating/ modifying file that was legit but bothersome for me.
Now here the malicious dll( vmx) and autorun files are created in USB devices via svchost.exe so during my testing it was a puzzle for me that which process is actually creating these files. I did not know until after many tries I found it out.
2- Similarly a dll in system32 is created by svchost.exe that my custom rules allowed silently.
3- I allow creation of tmp files globally without any pop up in my rules, so i never got an alert about creation of tmp file( ?driver) in this case.
4- More worse, just think of it. CFP intercept any dll execution by any process by default but it gives literally dozens of pop ups while executing legit applications, so i made a custom rule to allow any dll to be executed by any parent from anywhere.
Now if malicious dll is not spoofed as a vmx, you can guess what will happen. I will not get even a single alert and malware will execute n do its harm.
I think one pop-up is too litle from a classic HIPS. Infact I expect a classical HIPS to contain the damage even if u allow the sample to execute.
Now I realize how simple it might be for a clever malware to bypass a classical HIPS. I am not bashing CFP. Just showing that a clever piece of malware can do much harm even if u are using a classical HIPS. And it,s not difficult for any of us to make rules that will facilitate a malware to bypass the HIPS. After you always want a balance between security and usability( lesser the pop ups, better the experience).
Hope u get my point.
How do you know it is not whitelisted?
If rundll32 is not trusted how could it do anything?
I think rundll32 is different to explorer. If explorer runs a program then that programs rules are used. If a program runs a dll the initial programs rules are used. Otherwise rules would be generated for every dll.
Comparison? ???
I was asking about the testing methodology.
Eg: Why Geswall default configuration was altered?
What actually CFP default mean (is it full proactive)?
BTW I gather from screenshots that Geswall stopped the loading of the sample by adding a generic resource name (something possible with CIS too)
What malicious actions that sample actually carry?
What supposedly alerts should have been generated?
Is network-aware malicious activity involved?
There is an indirect way.
If it can be added to My own safe files or My pending files it is not whitelisted.
If a manual lookup is performed rundll32.exe is reported as unknown.
I cannot follow you anymore. Are you stating that you carried that test using an altered CFP configuration? ???
And you consider this CFP altered configuration lacking whereas Geswall altered configuration was effective? :o
GesWall - you need to make a rule to isolate ur USB drive in GW( see the pic). It stopped the worm dead. :-TU :-TU PASS
CFP - on default interactive security mode, you will get only one pop up that is execution of dll/ vmx file by rundll32. If u allow it, no more pop ups and malware is free to do all its actions. CFP however did label it as suspicious via file heuristics. :-TU PASS though I am not so happy about this pass. ;)So Geswall get :-TU :-TU and CFP get :-TU ;)
???
I like your tests aigle you have pointed out many flaws in comodo, and that way helped making it a better product! :■■■■
As for the testing, taking extra time tweaking the GesWall, to make it pass isn’t really fair, If you wanted to you could have made D+ block that file in a similar manner. Also you cannot do specific rules in CIS that says it sould not popup on this and that and then claim that its flawed for not popping up on this and that. CIS offers a lot of customization as you probably know and it did as you told it to, be happy. 8)
Well, if Comodo supported inheriting rights of parent process (like KIS) it would catch it.
So it’s not a HIPS design leak, rather a problem of a missing feature.
Maybe I misunderstood, could you please clarify the implementation details of that feature? ???
But CIS actually support inheriting rights of parent process (In CIS case mean to grant spawned processes the same D+ access rights of the parent)
In image execution control settings there is a list of file extensions to check. It also says “executables not listed under the files to check section are excluded”. If this is true why is there a pop-up when rundll32 tries to run the vmx file? Maybe it detects the file type and does not actually use the extensions in the list.
I’ve never seen this feature in CIS until now, all new started processes start by zero without inheriting any restrictions of the parent process.
How does Conficker use rundll32.exe? By starting it with parameters, code-injection…?
Shouldn’t a good HIPS be able to stop that? ???
Is the feature KIS has the same I described for CIS that is granting spawned processes the same D+ (or KIS in case of KIS) access rights of the parent?
Please at least me confirm what I asked you (KIS access right inheritance) before I describe how to enable it in CIS.
CIS is able to stop that. Is Kis likewise able to stop it? ???
What do you mean by this? If Firefox runs a malware program we do not want the malware getting the same rights as Firefox.
It is started by autorun. Maybe it looks to defence+ that the trusted OS is starting rundll32.exe and so there is no warning. I always disable autorun. Does defence+ need more checking of autorun programs?