False Positive Issue Not Issueable By Simple File Check

Note: the standard procedure of issuing a File or URL via http://www.bitdefender.com/submit/ cannot be applied here, because a certain use case must be followed.

Some curious problems appear upon using an industrial software application while bitdefender is operating. It appears that bitdefender is hypersensitive.

After quite a lot of experiments, a simple use case test could be defined which allows you to analyze what's happening.

The core of the phenomenon can be described as follows:

An executable for the command line interface (e.g. a simple program that outputs "hello world" in the console window) runs flawlessly when started from a Windows cmd-console (tested on Windows 7). However, using a scripting language that provides its own command line interface, an invocation of the SAME executable is treated as suspicious by bitdefender. Not the shell program is put in quarantaine, but instead the unsuspicious "hello world" executable!

Here is the use case:

1. start the Windows command line console (CMD).

2. type helloworld.exe<Enter>, several times (using the cursor-up key).

There will be no problem.

3. invoke tclkit-gui-864.exe. A command line shell is presented.

4. type exec helloworld.exe<Enter>, several times (using the cursor-up key).

Bit defender will report problems, finally blocking helloworld.exe.

Of course, the customer does not use a precise use case like this. Calls to commandline executables from a Tcl ****** represent daily automated stuff. And causes this problems.

Where are the used resources?

- Three different versions (from different compilers) of a helloworld-program are attached in a packed 7z-file. The smallest one is not an .exe file, but a .com file. This one yields no problems in the scripting shell.

- tclkit-gui-864.exe can be downloaded here: http://www.patthoyts.tk/tclkit/win32-ix86/8.6.4/

FYI: this represents a full-blown Tcl/Tk scripting engine with extensive GUI capabilities packed in a single file, without library dependencies.

The attachment has the suffix .doc. It must be renamed to have the ending .7z.

No packed file format (like zip or tar) is accepted by the forum.

/applications/core/interface/file/attachment.php?id=14377" data-fileid="14377" rel="">helloworld.doc

Find more posts tagged with

Comments

rnovasconi

Hello rm61,

I provide my contribute/opinion as a medium advanced user of Bitdefender products.

Bitdefender 2016 includes a feature, named "Active Threat Control" (formerly Active Virus Control).

This feature makes Bitdefender to check what the processes do. Basing on their actions, it composes a score (as it happens with antispam).

When this score reaches a thresold, the process is blocked.

I' have no deep infos about the score composition criteria, but, when a process calls another executable, I'm pretty sure that it raises the suspect score, because this is a common practice in malicious software.

This is the probable reason for some of the conditions that you mentioned.

We can agree more or less with the criteria, but the presumed "hypersensitive" approach in Bitdefender, is the probably the same thing that can save us, against new threats and zero days.

In any modern, medium sophisticated, antimalware solution, a process behavioural control is implemented.

Each brand makes its better to make it as effective and transparent as possible, but surely, due to its nature, a behavioural control can, in some cases, detect something suspect by legitimate executables. This happens every day, on undread of files, by several antimalware solutions.

Bitdefender also considers the digital sign as a marker for legitimate executables. Signed executables are allowed to perform "at risk" actions , without triggering Bitdefender intervention. If an unknown, unsigned executable instead do the same, it is blocked.

Malware has often easy life, due to "hypertrusting" on unsigned/unverified pieces of software. Blocking by default unknown files that are performing questionable actions, is a rasonable approach. In an ideal world, any executable file should be certified. Since there, this is probably the only way to put an effective limit to malware spread.

Finally,

if you are pretty sure that some unkknown unsigned file is legitimate, and not dangerous, you can insert a Process exclusion in Bitdefender for it.

Let we take care that only exclusions for "Process" applies to Active Threat Control activities.

You cannot apply Folder or File Exclusions to Active Threat Control.

Nesivos

Hello rm61,

I provide my contribute/opinion as a medium advanced user of Bitdefender products.

Bitdefender 2016 includes a feature, named "Active Threat Control" (formerly Active Virus Control).

This feature makes Bitdefender to check what the processes do. Basing on their actions, it composes a score (as it happens with antispam).

When this score reaches a thresold, the process is blocked.

I' have no deep infos about the score composition criteria, but, when a process calls another executable, I'm pretty sure that it raises the suspect score, because this is a common practice in malicious software.

This is the probable reason for some of the conditions that you mentioned.

We can agree more or less with the criteria, but the presumed "hypersensitive" approach in Bitdefender, is the probably the same thing that can save us, against new threats and zero days.

In any modern, medium sophisticated, antimalware solution, a process behavioural control is implemented.

Each brand makes its better to make it as effective and transparent as possible, but surely, due to its nature, a behavioural control can, in some cases, detect something suspect by legitimate executables. This happens every day, on undread of files, by several antimalware solutions.

Bitdefender also considers the digital sign as a marker for legitimate executables. Signed executables are allowed to perform "at risk" actions , without triggering Bitdefender intervention. If an unknown, unsigned executable instead do the same, it is blocked.

Malware has often easy life, due to "hypertrusting" on unsigned/unverified pieces of software. Blocking by default unknown files that are performing questionable actions, is a rasonable approach. In an ideal world, any executable file should be certified. Since there, this is probably the only way to put an effective limit to malware spread.

Finally,

if you are pretty sure that some unkknown unsigned file is legitimate, and not dangerous, you can insert a Process exclusion in Bitdefender for it.

Let we take care that only exclusions for "Process" applies to Active Threat Control activities.

You cannot apply Folder or File Exclusions to Active Threat Control.

Good points

Also note this.

Recent updates to Windows 7 appear to have created problems running UPX compressed executables and there is currently no fix available so this set of files are not UPX compressed and are therefore much larger than previous versions.

link

There may also be some pertinent info here

<h1 itemprop="name">Are there any downsides to using UPX to compress a Windows executable?</h1>