ClamWin is reporting the following today on a scan of my (Dad's) 'C' drive.

There's another thread here:

https://forums.clamwin.com/viewtopic.php?p=11710

... on Trojan.Agent-142482.

Have ClamWin set to report only, but would like some advice on how to proceed... or whether these are false positives.

Thanks Very Much.

Peter B.

-----

Scan Started Sun Feb 28 09:39:09 2010
-------------------------------------------------------------------------------

C:\I386\NOTEPAD.EX_: Trojan.Agent-142482 FOUND
C:\Program Files\Dell\DBRM\osmedia\I386\NOTEPAD.EX_: Trojan.Agent-142482 FOUND
C:\Program Files\Spybot - Search & Destroy\Updates\advcheck165.exe: Trojan.Dropper-24449 FOUND
C:\Program Files\Spybot - Search & Destroy\Updates\advcheck165.zip: Trojan.Dropper-24449 FOUND
C:\WINDOWS\NOTEPAD.EXE: Trojan.Agent-142482 FOUND
C:\WINDOWS\system32\notepad.exe: Trojan.Agent-142482 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 723717
Engine version: 0.95.3
Scanned directories: 4039
Scanned files: 38845
Infected files: 6

Data scanned: 12470.29 MB
Data read: 9234.34 MB (ratio 1.35:1)
Time: 2012.078 sec (33 m 32 s)
--------------------------------------
Completed
--------------------------------------

Neither VirusTotal nor Jotti found anything in either:

Trojan.Agent-142482

Trojan.Dropper-24449

... as reported by ClamWin.

Tried to submit the affected files as false positives to ClamAV DB, but the server wasn't cooperating.

Peter B.

-----

Both these are false positives.

Whereas I can understand having an occasional false positive on an executable file that is not related to the windows operating system (advcheck165.exe), a false positive on clean files (e.g. notepad.exe) from the windows operating system could be prevented if only the db maintainers would run test scans against known clean, and patched-to-date, windows test systems prior to releasing DB updates.

There is very little excuse for a false positive from a production database on clean files against a Windows OS that is current.

Whereas I understand the desire to get updates out fast, there's no reason to rush these to public without making sure they scan correctly (e.g. no false positives) against the OS files from clean systems of:

Windows XP
Windows Vista
Windows 7

Keeping 3 machines patched and isolated for testing the Windows directories of these systems with new DB releases prior to public release would:

1. Eliminate false positives on the OS files that can cause end-users horrible problems with their OS (the previous userinit.exe is a recent example)
2. Thereby, assure end-users that the AV software is sound

Furthermore, no AV software is capable of 100% protection of anyone's OS these days because the hackers are much, much faster at releasing the bugs (zero day/hour bugs) than the AV software labs are at identifying them. That's been true for some time now. So, taking an extra hour or two to run tests to verify that DB updates are not returning FALSE POSITIVES in the above manner prior to releasing these database updates would seem to me a reasonable requirement.

Thanks!

ClamWin uses the Clam AV scanning engine and signature database, and every signature produced by the Clam sigmaking team is checked for false positives before it is released. However, the "good" programs used for checking the signatures do not include every Windows program/file. Every time Microsoft has a patch (I get patches even when it's not patch Tuesday), some Windows programs may change. Clam got another server a few days ago, and it is expected that will help reduce false positives some, as they put more "good" programs on it.

With all that said, however, Clam AV is designed for and is used primarily by Linux email servers. If Clam comes up with a signature that spots a virus on the servers, it has fulfilled its purpose. Other parties, including ClamWin, also freely use Clam's source code and signature database and, in my opinion, these parties have some responsibility for what happens when they are used in their environments. ClamWin does not have the resources to do much, but at a minimum it needs to minimize any false positive damage to Windows system files and facilitate the submission of false positives to Clam. This could be achieved by warning about (not quarantining/removing) infected file detections on Windows system files, providing a script (VirusTotal's for instance) to aid users in checking them out, and perhaps another script to submit actual false positives to Clam for correction.

Finally, a good number of contributions to either/both Clam or ClamWin might also help the false positive situation.

Regards,

Hey Bob,

Yeah, I use ClamAV as the scanning engine on a bunch of e-mail servers in the Chicago metro area, both with qmail-scanner and amavis. Been using it for over 6 years. But, ClamAV as a mail scanning engine is not the issue here.

For ClamWin, the most recent examples of false positives that I'm noting on Windows files have been on files that have not changed, e.g.:

userinit.exe
notepad.exe

Userinit.exe has not changed since it was released with XP SP3. notepad.exe has also not had a recent update. Again, making sure that ClamWin scans correctly against the Windows directories of the 3 current patched Windows OSes would seem advisable, and a simple precaution prior to releasing ClamWin db updates to the public.

Granted, the ClamWin side of the project is not the primary focus, and I have no doubt that you're taxed, however, there are a lot of people using ClamWin based on its reputation. Presumably the desire is for people to continue to use it. So, whatever methods are used to prevent the initiation of false positive IDs on clean Windows files, clearly needs to be re-evaluated, using whatever methods might be appropriate to prevent these.

And to clarify, I'm certainly not trying to minimize the level of effort involved in combating the bot/virus/trojan threat phenom, nor your personal efforts in any way. However, as a long-term public participant in and user of the ClamAV and ClamWin projects, I am concerned, both for my deployments and those of others, as well as for the long-term health and viability of these projects.