For performance reasons, I would like to whitelist the following files from an AV protection:

  • .vmdk (VMWare virtual disk file);
  • .lck (VMWare lock file for disk consistency, created in the same directory as the .vmdk file);
  • .vmsn (Virtual machine snapshot file);
  • .vmem (Virtual Machine memory snapshot, made during snapshot creation while the machine is powered on).

Would there be any negative effects of excluding these files from runtime protection on employees’ workstations (not production or testing environments; only PCs)?

I believe that the risk is pretty low, but I would like to double check it.

  • 1
    Will your scanner look inside these files normally? Some of them may not understand how to scan a virtual file system. – GalacticCowboy Sep 28 '16 at 14:58
  • Are these employee's developers? I see no reason than non-developers would need such VMs, neither a reason why a developer would not be able to decide by himself whether he wants the protection for these extensions or not. – grochmal Sep 29 '16 at 1:02

I can think of the following points:

  • A malicious file could be stored using these extension. It is not impossible for your hypervisor to contain a bug that could lead to an exploit once a crated storage file is loaded. Potentially, your AV could be made able to detect such a problematic file before you have the time to patch your hypervisor, reducing your window of vulnerability.
  • Your AV might be able to understand the format of these files and look into them for potentially harmful files. I'm not aware of any product that does that but I haven't looked very far (and I'm not overly interested by such a "feature").
  • It is possible that the AV heuristic engine could actually detect some form of malware directly in the files while they aren't in use (most likely shellcode).
  • Depending on how your AV works, if the files are stored on an NTFS file system, a malicious file could be stored as an alternate data stream for one of these files then the AV might also skip the ADS linked to the excluded file.

IMNSHO, I think that the above risks are well worth taking given the high performance cost of on-access scan of VM files (which tends to be huge).

  • Also, some antivirus just skip files bigger than xMB in size, being x a value you can configure. Also, some skip non-executable files. – Ismael Miguel Sep 28 '16 at 15:39
  • 1
    Bullet point 2 (inspecting content inside the VM) is a very strong reason not to allow AV software to scan them. That's a serious boundary violation that could break all sorts of things. It might even lead to VM escape vulnerabilities if the AV software has a bug. – R.. GitHub STOP HELPING ICE Sep 28 '16 at 17:01

That is a common problem in the Windows world: file types are normally indicated by file extensions, so it seems a good idea to tell the antivirus to ignore some extensions. It can indeed speed things but think of that scenario:

  • on a machine I ask AV not to scan txt files because I know that text files do not contain viruses
  • an evil person gives me a USB key containing a bunch of jpeg files and lists of those files with comments in txt files - one of those txt file is is fact an executable file containing a virus but renamed to txt
  • I copy the content of the key to my disk - AV does not detect anything
  • => a copy of the virus is now on my disk

A slighter worse one would be if the key contained a clean version of an installable application for browsing the files, and if the owner of the key explains that the installation is awfully complex and breaks when an anti-virus is on (think of some Pinnacle products...) but he put a batch file that automates it - in the middle of the batch file, he renames the false text file and executes it...

In the above example, replace txt with vmdk, and you will understand why rules stopping the AV to ignore known extension actually lower the security level.

When possible, I do prefere to tell the AV to ignore specific folders, or even better specific files

  • I don't think such a well-tailored virus would be stoppable. This is much more like social engineering than anything else. You don't even need the "evil txt file" for such thing - the bat can do the mess by itself. – T. Sar Sep 28 '16 at 16:19
  • @ThalesPereira: A batch file could not by itself open a backdoor. Viruses can carry trojans that can do good work in stealing information... – Serge Ballesta Sep 28 '16 at 16:21
  • @ThalesPereira - You can stop a batch file execution with properly configured antivirus. – boleslaw.smialy Sep 29 '16 at 12:07
  • @SergeBallesta - Theoretically, it could do it, e.g. by executing PS script embedded into the batch file. – boleslaw.smialy Sep 29 '16 at 12:07
  • "he renames the false text file and executes it" Your scenario stops here. As soon as the file is renamed to an executable, the AV can scan it. Also, AV normally scans any executable being invoked regardless of what extention they're in. (Because using APIs, you can run any file as executable regardless of file name.) – billc.cn Sep 29 '16 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.