A security researcher is taking Microsoft to task for advising customers to exclude certain files and folders from anti-virus scanning, arguing the practice could be exploited by pushers of malware.
Microsoft issued the recommendations in October, as a way of improving system performance. They suggested administrators exclude …

Christmas is drawing near...

As we all know, MS already provide tons of jobs in the IT trade by way of their OSs being shoddy. What better way to celebrate Christmas than to present everyone with yet more opportunities to fix MS's mistakes? MS provides work for you, too!

Kernel32.dll?

I'm guessing the 'no need to scan' files are the core system files like kernel32.dll, which is impossible to change or kill whilst Windows is running. If you try renaming it, windows just spins off a fresh copy in a heartbeat and you're left renaming a copied file, for instance, in which case you could say scanning those individual files was pointless as they're robust. But the folders containing them? Less so, I reckon - obvious place to hide the nasties!

To be fair,

Microsoft specifically say File Locking not just system performance, and to be equally fair, Trend Micro mention possibilities in the future.

I would take this as an opportunity for both parties to come together and resolve the current problem of sporadic system freeze and future potential risk, after all, this what consumers of both products would wish for, seemless integration.

Segregation of duties

It seems to me basic that you should not use a security mechanism provided by supplier X to address security vulnerabilities originating from the same supplier. Microsoft do not seem to have understood this.

Microsoft's first anti-virus product, MSAV, was rubbish. I can't speak to the quality of this one, but however technically good it may be at detection, it has now, I believe, been utterly compromised by this extremely bad advice. The only way out, I feel, is for Microsoft to improve the performance to the point where thay can publicly rescind that advice.

Paris, because her performance is never in doubt. Can't speak about vulnerability to infection though...

Old news...

At least going back to NT 4/Exchange 5.5 Microsoft have often recommended not scanning certain files with A/V products as they may corrupt them or make the system very slow. I'd say this is more an issue for A/V vendors. Certain files like transaction logs should never be scanned with file-level A/V as it will corrupt them beyond repair if it attempts cleaning/removing malicious software.

This might not be that big a deal ...

Remember, all executables and libraries in any Microsoft designated directories will be digitally signed by MSFT. A minor change to the virus scanner could be to simply scan all directories for files that are not digitally signed by Microsoft.

If any exes were altered by viruses, the sig would become invalid, thus flagging it to the virus scanner.

Signatures on files - Wonderful idea... But not on windows

That would have been a wonderful idea on a Unix system where locking is advisory and you can always read a file.

However, on a windows system in order to read the file sig you still have to read the file itself which is an implicit read-lock. You also have to compute the file checksum so you can see if the sig is valid.

Both operations may in fact be comparable to a legacy AV scan in terms of performance.

Infecting files? Who still does that?

"These files are not at risk of infection,".

Most malware in past years doesn't even infect files anymore. They drop files on the system and either directly, or via compromised program (browser, document reader, etc), inject an entry in the registry/start up to have the dropped file/malware auto-executed by Windows or another program. And guess what? The file/malware can be named anything, not just .exe or .dll.

MS' advice? Should be accompanied with a bright, blinking, in-your-face warning, doing so is like pointing a loaded gun at your foot with finger on the trigger.

Real time scanning and file extension exclusions

(Please note that I advocate no exclusions at all for off-line scanning such as manual or scheduled scans. In these cases performance is not as much of an issue as with realtime scanning.)

As of today, files with a .log extension are not executable under Windows and I don't see that changing very soon. As such .log files pose no direct threat to the security of any windows computer.

An interesting experiment would be to create a windows shortcut to an executable file and call it 'tst.log'. See if you can manage to execute the original executable file by means of 'tst.log' alone.

If these files were to be used as payload containers for illicit code, they would still need a loader/executer/interpreter to be effective. This loader/executer/interpreter would necessarily be contained in a executable file which can and will be inspected by ao anti-virus software.

Hence there is no actual benefit for the malware writer to use .log files as payload containers unless he would endeavour to create a loader/executer/interpreter that would be too generic to be detected by explicit virus definitions and not generic enough to be detected by heuristic rules. I consider it highly unlikely that such software could succesfully be made and escape detection from all realtime scanners.

Therefore I would indeed recommend to exclude any .log files from realtime scanning. In fact I would advocate to add exclusions for many more extensions: .txt, .cpp, .obj, .bmp and *.cfg to name but a few.

The main benefit is of course reclaiming the lost performance due to realtime scanning of files for which realtime scanning offers no security benefits.

That's not the complete story...

You are partly right, executable files renamed with a .log extension remain executable from the command prompt. However, it is not possible to execute this 'hidden' application via windows explorer.

Activation of malware in this way requires either:

case 1: an explicit command entered by the user on the command line

case 2: a .bat or .cmd file which contains a command line to invoke the software

case 3: a loader application that would invoke a system call to create a new process, giving it the name of the .log file as application name.

I would argue that the first case is out of scope here, the user is presumably master of his machine and can already do whatever he wants whenever he wants. Case in point, if he does 'format c:\' or 'del /f/s/q c:\*.*' his PC will be messed up regardless if realtime virus scanning is active or not.

For the second and the third case one could argue that this is exactly the kind of activity a realtime scanner could detect, but then again we only need to scan the .bat or a .cmd file, not the .log file. (IOW detect the loader/executer/interpreter, not the hidden payload).