Microsoft AV advice may aid attackers, researcher warns

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 …

[Anonymous Coward]

Common practice

We have to exlude certian files at work, due the fact, that if we do scan them , the systems just become doorstops.

The other problem with a/v yes you can say limit it to "5% cpu", but it still thrashes the crap out of your drives, so when you try to load anything, it just grinds to a halt.

We done tests with most A/V products.

With no a/v, app takes less 15 seconds to load. With A/V on 1+ minutes. So that's how much it can cripple performance.

So instead of lampooning MS for porviding a workaround, maybe the problem shopuld be resolved by the vendors?

[ElReg!comments!Pierre]

Resolved by the vendors???

I assume you mean the AV vendors, which is strange. Let's try and not lampoon MS then. So the AV vendors should make their scanners faster because:

-the system needs to be scanned, due to Windows being as tight as a piece of crochet work after an encounter with a mob of hungry moth.

-the OS is so bloated that some huge "system" files will take forever to scan, bringing the system to its knees.

No, you're right, I don't see how MS can be blamed for either of these points. Clearly the AV vendors need to put their act together and come up with a solution for intrinsic Windows problems.

[Anonymous Coward]

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!

/sarcasm

[Cliff]

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!

[Dale 13]

Wouldn't know his arse from his elbow.

"we are concerned by the fact that this was released publicly."

It may be news to David Sancho, but Microsoft and other vendors, notably Computer Associates, have been providing advice on how to exclude particular files for years.

Why should I be surprised though? David' work experience has basically been Trend Micro and Burke Formación.

[Neal 5]

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.

[Martin Taylor 1]

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...

[Barry Tabrah]

What to do about MSE

And I had such high hopes for it. Let's hope the microsoft techies working on Microsoft Security Essentials aren't following the same principles.

[Anonymous Coward]

Blogger didn't read MS article properly

It specifically says:

"Do not exclude.... based on the file name extension. For example, do not exclude all files that have a .dit extension"

It also has numerous warnings including lots of advice for protecting the domain controller.

[Kevin7]

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.

[tenorwoody85]

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.

[Anton Ivanov]

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.

[seatrotter]

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.

[ErikCumps]

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.

[Anonymous Coward]

The title is required, and must contain letters and/or digits.

"As of today, files with a .log extension are not executable under Windows"

Wrong.

Below is a 'somewhat edited' (removed user name info) command prompt session that began after I copied mp3info.exe to my desktop:

Desktop> rename mp3info.exe mp3info.log

Desktop> mp3info.log

MP3Info 0.8.5 Copyright (C) 2006 Cedric Tefft and Ricardo Cerqueira

MP3Info comes with ABSOLUTELY NO WARRANTY. This is free software, and

...

Seems to execute just fine to me!

[ErikCumps]

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).

[jeanX]

ms AV

The last thing I remember was signing up for something that would make the file scanner quicker.

It did not.