labview exe was considered as suspicious.cloud.5 and removed by Symantec

[rolfk]

LabVIEW could of course try something else to prevent this specific issue, but there is no guarantee that whatever they come up wouldn't be considered by one of the many virus scanners as an illegal action. As such it is pretty useless to spend much time on this.

The issue needs to be tackled at the virus scanner side by configuring an exception as first measure and reporting that to the virus scanner vendor.

[criminy]

I am having the same problem. This is NOT a FAULT issue. LabVIEW builds EXEs in a way that triggers the Suspicious.Cloud.5.A virus alert. This is an alert (relatively new) that detects possible viruses by behavior rather than a specific signature. This behavior was described above as LabVIEW attempting to change an already existing EXE when completing a build. (This is exactly what Trojan viruses do.

What happens to the file (once Symantec alerts on it) depends on your Symantec policies. In my case the policy is to delete the file (not quarantine)... So I cannot provide the file to Symantec or anyone else to examine as a false positive. My solution is to create a directory on my drive in which I will build LabVIEW EXEs. Then I requested that directory be white-listed by my IT Security responsible for the Symantec Rules.

[criminy]

What I wish is that National Instruments would get in contact with Symantec and work through this problem together. You'd think NI would be interested because this problem has been hanging around for a few years now.

[rolfk]

We use Symantec.cloud Endpoint Protection throughout the company for quite some time now and I have to hear any such error report so far. So it would seem more a configuration issue than a specific LabVIEW problem.

[criminy]

I think that it what I was saying. Symantec is just doing what it is configured to do... But it is still a false positive... and my IT will NOT change their rules for this, so I can only attempt to create a sandbox in which Symantec won't interfere with its configure rules. Once created as an EXE, and moved elsewhere, Symantec doesn't bother it, because the type of error is not a definition for Symantec.  I still wish NI would work with Symantec on this specific issue to see if there is some way to create the EXE that doesn't alert Symantec at all without causing too much pain for NI.

[RavensFan]

I question why Symantec changed something for this to now become a problem.

NI has been generating the executables for a long time that weren't causing Symantec to flag them as false positives.  Then Symantec changed something in their code to now have problems.  Symantec needs to take the responsibility to fix what they broke.

[altenbach]

---

@criminy wrote:

What I wish is that National Instruments would get in contact with Symantec and work through this problem together. 

---

No. Once you have a reproducible way to generate the false positive, you, or your IT department, needs to notify symantec and ask for a solution. You are (presumably) a valuable corporate customer of symantec and they need to fix whatever interferes with your daily work. If symantec ignores you, IT should immediately explore alternative security provider. I am sure there are some that actually value their customers.

For now we assume that your computer is NOT actually infected with a hidden rootkit or similar that (1) symantec AV fails to detect and (2) symantec detects by behavioral analysis. This is still a possibility. If innocently building an executable really is the true cause of the problem, I would expect many more customers to have that issue.

It is up symantec to contact NI if they need more information, not the other way around.

[criminy]

Yes... this thread is more than 3 yrs old. Symantec DID change something. They added the Cloud.5.A protocol that responds to suspicious behavior rather just specific know viruses. Specifically, in this case... Symantec is looking for anything attempting to alter an existing EXE. Since Ni LabVIEW does that in the process of building an EXE... it flags Symantec.

[criminy]

So, it's all on Symantec, huh? That's clearly a reasonable way to approach this... However, NI has often been proactive with issues that bug programmers and there's no reason they can't do that now.

example: I had an issue with VxWorks on cRIO. NI went to Wind River to come up with a solution, and Wind River then provided me a solution.

Since I am a valuable customer to BOTH Symantec and NI... BOTH should be concerned.

The argument about changing Vendors is certainly valid, but that is not something over which I have the slighest control. Once I get it white-listed (sandboxed)... I will have the file that creates the suspicious behavior... but that won't help because Symantec interferes WHILE the LabVIEW EXE is being built. Once built, Symantec doesn't see a risk... They would have to try the build and see the response. Or NI would need to provide them a detailed description of HOW the build, so Symantec could see an opportunity to change how Cloud.5.A detects. This kind of thing they do not generally do.

Symantec's False positive submission is built to send them an EXE that Symantec aborts when Launching... It is NOT built to examine a false positive (which is this case) caused while BUILDING an EXE.

[tst]

Regardless of how to fix this long-term, here are a couple of options you might be able to implement immediately and might help:

1. Set up a pre-build action and call the Clean VI in it (it's in a build palette inside the app control palette). This is supposed to delete all the files created by the build.
2. Build the EXE in a network drive. This might be monitored by the AV, but will probably not be monitored by the one running on your computer.