WIN 7 Defense+ bug with OS generated .vbs files?

WIN 7 Premium x64 and Comodo 5.4.189822.1355.

I am running Comodo with Firewall and Defense+ set to safe mode. Sandboxing is set to auto and limited.

Every time I am using WIN 7 event viewer and I elect to dial out to MS to get additional info, a user directory temp folder .vbs file that is generated by the connection process is being auto sandboxed as unknown?

First, I was not aware Defense+ checks scripts. Second, this is obviously a safe process since it was generated by an OS process.

[Edit] I am also running Avast 6 with script shielding on. Wonder is there some interaction there between Defense+ and Avast’s script shield?

What process is starting up the .vbs file? Can you show a screenshot of the Active Process List from the situation?

Best I can tell is iexplorer is creating the .vbs file Defense+ is sandboxing. Defense+ popup occured before the Flash exe started but after iexplorer started.

[attachment deleted by admin]

[Edit] I am also running Avast 6 with script shielding on. Wonder is there some interaction there between Defense+ and Avast's script shield?
There is only one way to find out; temporarily disable the Avast script shield and see if that brings a solution or not.

Nope. It’s not Avast’s script shield.

I also forgot to mention that when I first try to connect to MS for further event info, nothing happens. It is when I try the second time that I get the Defense+ popup.

I have checked all my Comodo and Avast event logs and nothing shows except Defense+ sandboxing that temp .vbs file. Nothing unusual in the WIN 7 event logs either?

[Edit] I also disabled the Flash plug-in in IE and tried again. Same result so this .vbs file is being generated by IE and I have to assume it is legit.

OK. Here’s an example of a .vbs script that is being sandboxed as unknown and the object it is trying to run. Nothing malicous here.

Set shell = createobject(“wscript.shell”)
Shell.run “”“C:\Users\Don\AppData\Local\Temp\tmpF3A5.url”“”

Once sure this is not malware (check Eric iis satisfied), please see #6 on the known issues list. Follow the ‘fix’ link for a fix.

Best wishes

Mouse

Thanks, Mouse.

Best fix I saw in the link you provided was “Random Temporary .bat Files Need To Be Trusted.” I really don’t know if I want to add an exception in my User temp directory for tmp*.vbs. That appears to be opening me up to a lot of exploits.

Bottom line is the event lookup does work when sandboxed as limited although I have to do it twice and then live with the Defense+ popup.

Strange that MS help works just fine with no alerts. This must be something new that MS introduced with WIN 7 event viewer dial-outs for additional detail. Appears it is using IE to generate the .vbs scripts?

Ah I see the link is not sufficiently specific, sorry. I will amend. You need to apply the installer-updater policy to the program that creates or runs the .vbs files. Probably mmc.exe, though I don’t have Win7 so I’m not sure. Just check what seems to be creating and running them in the Active Processes list in CIS - look at this view in real time when you click the link.

OK new guidance at D here.

Best wishes

Mouse

At least now we are getting somewhere although I can’t say we are making any progress.

That process explorer in Defense+ is pretty slick.

The process generating the .vbs script is taskeng.exe. It’s in the System32 directory. Now the bad news. It is spawned by svchost.exe. I did set taskeng.exe as installer-updater but when it executes under svchost.exe, it runs as trusted.

Only firewall I know of that allows for creation of spawned process rules is Sophos.

Any further ideas?

With taskeng as an installer/updater are the files still being sandboxed acc to the active process list? (I’ve seen D+ installer/updaters not being flagged as such in the active process list).

Are the .vbs files being run in the context of taskeng? or being created by taskeng, or both?

If a different file is creating them (not easy to determine) then that program can be made an installer.

You can use the Microsoft process explorer (just Google it) process properties to determine this - look for the vbs file’s parent on the image tab.

Best wishes

Mouse

With taskeng as an installer/updater are the files still being sandboxed acc to the active process list? (I’ve seen D+ installer/updaters not being flagged as such in the active process list).Yes, the .vbs is being sandboxed as limited as was done previously.

Note: Like I said previously, taskeng.exe when spawned from svchost.exe is running as trusted - not as installer/updater. This tells me that Defense+ is assigning the spawned process the security attributes of it’s creator i.e. svchost.exe. Unless there is a manual way for Defense+ to assign separate attrinbutes to a spawned process, there is no manual way to correct this.

I am positive that taskeng.exe is the process Defense+ is responding to since I saw the Defense+ alert executable show under it when the Defense+ popup appeared on the desktop.

I have understood you, and yes the installer/updater has been able to over-ride inheritance in previous versions, but the result I’ve observed recently that it is not always labelled as installer/updater in the active process list, that’s why I asked. (If this confuses think two disinct sets of policies that interact, Old D+ and sandbox policies).

To make sure the old D+ policy over-rides any sandbox policies, please do the follwing:

  1. remove any taskeng and .vbs file entries from unrecognised files
  2. remove any taskeng entries from trusted files (probably none)
  3. make sure the taskeng entry in D+ is at the top of the ‘D+ rules’ list in the computer security policy
  4. make sure ‘automatically detect’ and ‘automatically trust’ are ticked on the D+ settings ~ sandbox tab.

It’s most likely 3 or 4 if you want to try a couple first.

Best wishes

Mouse

Did everything you requested. Only thing I could not remove from Defense+ logs were some .vbs files in the Submitted section. I asked in another thread how to do that and never received a response. I also moved the Defense+ rule to the top. Still a no go.

I them changed the Defense+ rule to System Application. Still a no go. I then rebooted after deleting the .vbs file from the untrusted. Still a no go.

In all the above instances, taskeng.exe is being created as “Trusted.”

Oops!!!

Forgot to tick the Run Installers and Updaters option. Changed the Defense+ rule back to Unistaller/Updater and that did the trick!

Now the question is … the common understanding is to not allow that out of sandbox installer/updater option for security reasons?

Can I just check, did you ensure “automatically detect” and “automatically trust” under sandbox settings were ticked.

I should have also said reboot after changing all the settings. So could you please make taskeng an installer again recheck everything else again then reboot, and retry.

If his does not work please post screenshots of 1) your D+ logs from the boot to the re-try of your problem with all column info showing 2) your full active process list with all column information showing, inc a .vbs file being run

Best wishes

Mouse

Thanks, Mouse.

Like I said in my prior reply, when I checked “Allow Installers/Updaters To Run Outside the Sandbox” option, I was able to connect to MS without a Defense+ alert.

Now the question is … the common understanding is to not allow that out of sandbox installer/updater option for security reasons?
This is my main concern now. Most expert opinions I have read on Defense+ sandboxing recommend this option be disabled. I would rather live with the Defense+ bogus alert than get nailed by a malware installer.

Sorry our posts collided. This option is safe so long as:

  1. You trust fully any file you make an installer/updater, and any file it is likely to drop or run without asking

  2. You don’t ever use any file you make an installer/updater to run other files you do not know or trust

  3. you trust CIS to make the right judgements on what files to make an installer updater

  4. Usually applies only if the file involved is an explorer substitute, development tool or some other very general utility.

I’m glad this is resolved. You only other option really is to determine the file name pattern and use wildcards to make the .vbs files trusted (not installers). Happily CIS supports ? as well as *, so the patterns can be quite specific.

Best wishes

Mouse