Kaspersky is choking on my pre/post build events

Question

Apparently VS wraps up post- and pre-build events in a cmd file which it pops in the LocalSettings/Temp folder. Kaspersky has suddenly (it worked fine yesterday) decided that this is a threat (RootShell risk), and puts them in quarantine, which leaves me with a hung VS, and no way to compile projects (other than going through them all manually removing the events).

The SysAdmin here is - understandably - not keen on doing a wildcard exception for *.TMP.EXEC.CMD files in the LocalSettings/Temp folder. My Google-fu hasn't helped me so far.

Anyone encountered this problem or got any tips?

EDIT FWIW, having the same problem with git, SmartGit, and a load of other programs. Kaspersky getting to smart for their own good...

Answer 1

Wait, your company's own IT policy is preventing you from getting your work done?

@Greg: It pains me to see this mentality perpetuated in the guise of a technical answer. We should encourage working with your sysadmin, not against them. In all probability, this is merely the result of a default setting within Kaspersky, combined with a slightly-odd practice by Visual Studio and, now the sysadmin is aware, they are trying to find a workable solution.

That said, having dismissed the idea of the wildcard, if your sysadmin is not actively looking for an alternative solution, then they are not doing their job properly. That is a reportable issue. Of course, your office's politics are going to play heavily on who wins in a developer vs sysadmin argument -- even some higher-ups get panicky when the sysadmin's stock 'company security' card is played!

As a sysadmin, I am also uncomfortable with arbitrarily allowing *.tmp.exec.cmd files to execute unchecked -- Local Settings\Temp is surprisingly easy to write to from many places and plenty of (insert well-known software) exploits can allow execution.

That said, as a developer, I have also recently experienced the same issue and would love to see a solution.

So, with both hats on (and a bit of Googling), I look at the Kaspersky policy/events relating to our client machines and can see that the build event batch files are triggering the Input/Output redirection rule in the Application Activity Analyser. So I guess it is a problem with the way Visual Studio captures the output from your build events.

Much of the following is going to be a brain-dump of the things I have tried to get around this issue, with varying degrees of success. I also run CruiseControl.NET on a couple of separate build machines (this is where I first noticed the issue), so I will break off on a tangent to cover those too.

It is my belief that a recent Kaspersky update might have altered the default action for this from Allow/Prompt to Quarantine, or that the definitions for this are now over-zealous.

Kaspersky documentation can be a little light (at best), particularly with regards to the Proactive Defence component and what it is actually checking for.

I can see four possible solutions to this, besides the aforementioned wildcard exclusion:

1. Changing the AAA settings in Kaspersky to make I/O redirection a prompatable activity
2. Add the exclusion rule for *.tmp.exec.cmd but limit it only to not being subject to the Proactive Defense component for the threat type RootShell
3. Turning off the check for I/O redirection
4. Adding a "trusted zone" exclusion for %WINDIR%\Microsoft.NET\Framework\*\MSBuild.exe, (and Framework64) with Do not restrict application activity

Option #1 might be sufficient, as it puts the control with the end user (if they are considered reliable enough to make the decision) but may lock up the CC.NET build process while it waits for a response.

Option #2 might supply enough of a edge case that the sysadmin is more amenable to including the rule. You may also be able to qualify the rule with the temp path, such as %TEMP%\*.tmp.exec.cmd to further reduce the concern. For the service session, the environment variables don't seem to be be loaded, though (at least the rule didn't seem to be triggered), so you have to get around this by running CC.NET under a known domain service account and adding another rule explicitly specifying its temp location.

Option #3 smells just as much as the wildcard exception, if not worse. Although, is I/O redirection actually that big of a deal? Should the ability to pipe the output of a process to another be that tightly controlled? Kaspersky seems to think so, but I'm not so sure. Surely many automation/scheduler-style apps would be adversly affected by this?

Option #4 is my preference as a sysadmin. If I can find the correct combination of settings so that MSBuild is allowed to do its job, but everything else is still covered, that must be the correct way, surely?

Unfortunately not, as the MSBuild.exe process spawns a cmd.exe process to run the *.tmp.exec.cmd files and it is under the context of that cmd.exe process that Kaspersky scans the file. Which means that the trusted application rule would have to be defined for cmd.exe, with Do not control application activity. This seems worse than the wildcard exclusion for *.tmp.exec.cmd because it would effectively mean that all batch files are excluded from the test, rather than just the subset.

So I come back to a combination of Options #1 and #2. I add exclusion rules for %TEMP%\*.tmp.Exec.cmd, %USERPROFILE%\Local Settings\Temp\*.tmp.Exec.cmd and %USERPROFILE%\AppData\Local\Temp\*.tmp.Exec.cmd (if %TEMP% is not defined, the %USERPROFILE%-based path should get there on XP and W7 respectively). I also change the default action for I/O redirection to Prompt so, if it is an overly-aggressive new rule/definition, any other programs this might affect can be explicitly controlled by my end users (or, at the least, it might scare them enough to come ask me about it).

As far as CC.NET goes, the plan is two-fold: Either I install CC.NET on actual servers, running Kaspersky Server Edition (which does not include the AAA module) or, if I am deliberately installing CC.NET to a workstation build (e.g. if I want to automagically see if my app works in W2K/WXP/W7 using unit tests, etc), I make it part of the standard operating procedure to configure the CC.NET service to run under my dedicated domain service account, svc-ccnet, and then add fixed exclusion rules to our Kaspersky policy for C:\Documents and Settings\svc-ccnet\Local Settings\Temp\*.tmp.Exec.cmd and C:\Users\svc-ccnet\AppData\Local\Temp\*.tmp.Exec.cmd, with a Threat Type of RootShell and the Component set to Proactive Defense. At a push I might add the CC.NET devices to a different KAV group which relaxes the AAA restriction.

I hope this helps (actually, I hope that someone else comes along and says "you've missed something really simple" and then explains what that is!!).

---

TL;DR version: The options I've found in KAV to prevent or reduce the effect of this are as follows. Get your sysadmin to pick the one they are most comfortable with:

1. Set the action for I/O redirect to Allow or Prompt in the policy's Application Activity Analyzer settings
2. Uncheck the I/O redirect option in the policy's Application Activity Analyzer settings
3. Add %COMSPEC% to the policy's list of trusted applications, checking the "Do not control application activity"
4. Add %TEMP%\*.tmp.exec.cmd to the policy's Exclusion Rules, using the threat type RootShell and the component Proactive Defense

My preference is #4; others may differ.