Comodo did not sandbox it.
2012/8/15 14:54:14 Create new process (2) Permitted Process: c:\windows\explorer.exe Target: c:\windows\regedit.exe Cmd line: "regedit.exe" "C:\456546.reg" Rule: [App]*
4.environment:
Windows XP SP3 32bit
Could you upload the sample?
Can you PM me the .reg file?
Can the registry keys of CIS be deleted by running a .reg file?
???
The question is ‘how can this .reg file be executed’.
I think only the user can ‘execute’ this, and I don’t think the command-line heuristics will be triggered on .reg files but that’s just my personal opinion.
Can it be executed by an exploit kit?
for example:
iexplore.exe (trusted) → java.exe (trusted) → javaw.exe (trusted) → xxx.reg
With the buffer overflow protection of CIS we stand a good chance that the exploit gets caught in the act.
Please notice that in your topic start you were opening the reg file. CIS does not act as the nanny of user behaviour. It is only the nanny of program behaviour. CIS will allow the user to add something to the registry. An unknown program will not be allowed to write to protected parts of the registry.
1.The buffer overflow protection of CIS can not stop the drive-by download malware from running.
You can check this by the balckhole exploit kits.
1.I double clicked on the .vbs file
2.It was sandboxed as partially limited.
3.After the restart of the system, comodo did not start.
2012/8/16 10:59:09 Create new process Permitted Process: c:\windows\explorer.exe Target: c:\windows\regedit.exe Cmd line: "regedit.exe" "c:\2.reg" Rule: [App]*
6.environment:
Windows XP SP3 32bit
That seems real enough.
CIS should have prevented the vbs script targeting protected registry keys because it is an unknown program. Was "Do heuristic command-line analysis for certain applications " enabled when you tested this?
This looks like it could be a bug.
About the .REG files, CIS parses if these .req files are coming from a removable drive such as a USB drive or CD rom or from temporary files.
That’s why in this scenario when tings are done manually, CIS just skips it. I mean it is no different from manually editing registry entries.
Try using a USB drive. The attacks we have seen are from viruses which infect by using autorun.inf which automatically start *.reg file etc.
Please see the “Reply #9”
I move the two files to the USB drive.
I double click on the .vbs file.
.vbs file is sandboxed as “partially limited”
After the restart of the system, CIS can not start.
“partially limited” can not block this action:
simulate the input of the keyboard
Oh I didn’t notice keystroke simulation there. In CIS 6, this action is automatically blocked as well.
1.“Parental control” is enabled and is password protected by the user A.
2.The user B runs the .reg file and then restarts the system.
3.After that, CIS can not start.
4.The user B can do anything without the limitation by CIS. >:-D
Will CIS V6 add an independent function for self-defense?
Nothing new for this particular case but we are going to introduce a full parental cointrol suite in CIS sometime in 2013(Not in CIS 6.0). Full url, keyword filtering , bandwidth quotaing etc. with integrated user accounts.
But CIS doesnt protect itself from its human masters 
Only against malware.
What struck me is that the vbs script does not caught by the sandbox because it is not a known file. Could you comment on that?
Is there anything more to share about how this gets handled in CIS 6?
CIS is the nanny of program behaviour not of user behaviour.
2012-08-16 10:07:46 C:\Documents and Settings\Roger\桌面\virus\1\1+.vbs Direct Keyboard Access
Is that what the D+ logs generated?
