>
>Eicar is a test virus to test your antivirus program.
>
>http://www.eicar.org/
Remember someone was afraid his virus checker wasn't finding viruses
on download? Not emails but downloads. This address, or more
specifically,
http://www.eicar.org/anti_virus_test_file.htm
has various files to download to test if yours is working. Read at
least the last two paragraphs, and if advisable, download all 4.
Thanks, Deuce.
Meirman
If emailing, please let me know whether
or not you are posting the same letter.
Change domain to erols.com, if necessary.
>Well mine picked them up "AVG free version"
All four! I hadn't tried when I posted but my AVG free version only
got one of them! I"m using ver. 4.0.461. Is your version higher?
It didn't get either zip file. Neither of my AV's did.**
And the txt file was picked up only by NAV AutoProtect. (I run both
AVG and NAV, but for some reason AVG gets them first. When AVG gets
them, NAV never sees them, but if I "Disable Resident Shield" in AVG,
then NAV finds them.) NAV caught the text file both when I downloaded
it, and when I just clicked on it and displayed it a browser window.
I got exactly parallel results when I was deleting each of these from
the folder I put them in. But I used Power Desk (in place of
Explorer), and I usually get a virus alert from AVG just by
highlighting the directory. Here it didn't happen even when I
highlighted all 4 files or the .com file.
** So why do you suppose my AVG didn't get the zip files? I read the
help file and it says it can do this but I have to have the option
checked. But the option is checked.
I'm not really complaining that NAV didn't get the zip files. I'm
still using NAV5, 4 or 5 years old, and I see it has "scan within
compressed files" only for the manual scanner. For Auto-Protect, it
just has All Files and I guess that doesn't include expanding zip
files, although until now I never knew that, since I've never gotten a
virus in a zip file. That's the point of test viruses, so the test
worked!
It's very interesting. I deleted them all and started again. Using
Netscape 4.79. (Maybe you're using another browser?)
Eicar.com alerted twice the first time, once for the cache and once
for the folder; and then three times the next time, once for the
folder, once for the cache, and once for the folder again. I guess
the first alert was when it checked the folder to see if this would be
a duplicate copy. All alerts by AVG.
Eicar.com.txt on download alerted once, with NAV5, the first time;
twice subsequent times.
The zip files, nothing. How come it catches yours?
Try unzipping them. Lots of AV's don't catch something inside a .zip until
you try to extract.
--
- relic -
Resident Psychic: alt.os.windows-xp
Next time there's a war in Europe, the loser has to keep France!
>And the txt file was picked up only by NAV AutoProtect. (I run both
>AVG and NAV, but for some reason AVG gets them first. When AVG gets
>them, NAV never sees them, but if I "Disable Resident Shield" in AVG,
>then NAV finds them.) NAV caught the text file both when I downloaded
>it, and when I just clicked on it and displayed it a browser window.
To follow-up my own post, a while back someone in another win98 group,
and I think someone here also told me that Norton warned against
running two antiviruses.
Someone asked why I would want to. This illustrates exactly why. For
whatever reason, forseeable or not, AVG didn't catch the .txt file.
And a few weeks ago, when I applied each AV separately, manually, I
have had an occasion where AVG caught something that NAV didn't.
It's understandable that if NAV has had problems running at the same
time as other virus programs, they would warn against it. But that's
one problem *I've* never had, nor false positives as they warn
against.
And even if I did, I would much rather have a false positive than miss
a positive. And it's easy enough after a potential false positive to
test a file with one AV only. To assume an AV would ever miss a virus
is to assume it's perfect and that I always got new definitions at the
earliest time possible.
So...everything would be perfect if I could figure out how to make NAV
test the files before AVG does. NAV loads before AVG does. Maybe it
would be better ? if it loaded second, but I don't know how to arrange
that either.
>Remember someone was afraid his virus checker wasn't finding viruses
>on download? Not emails but downloads.
Unless there's something odd about your download app, it should be
merely creating a file *as* a file on the hard drive, without
auto-running it. As long as an underfootware av is scanning
newly-created files it should catch it before it runs, and if you
download into a "suspect" subtree and point an on-demand av at that
subtree (e.g. QuickLaunch shortcut) that should catch it too.
Contrast this with email application behaviour, as per...
http://users.iafrica.com/c/cq/cquirke/empath.htm
...and you can see why I'd expect download scanning to be a non-issue
in the same way that email scanning is a problem.
Caveats:
1) Make sure the av scans everything
Most on-access scanning is compromised in the name of efficiency, e.g.
only some known-to-be-dangerous .ext scanned, with or without embedded
OLE/DDE info checking, not scanning inside archives, etc.
So even if you are using an underfootware av, there's a case to be
made for a "suspect" subtree and on-demand shortcut to scan it.
typically one can set on-demand ("manual") and on-access
("auto-protect") settings differently, and thus use a "dumb"
scan-everything mode for the on-demand scan.
2) Remember that av can't scan inside all archive types
If archives is an oddy, e.g. RAR, or password-protected, then manually
extract the files first, scan these files, and only then "run" things.
It's fairly trivial to use less-common archivers to create
self-extracting .exe files that are more difficult to extract without
running them, and which can hide the contents from av.
3) Avoid oddball downloaders
Dumb-ass downloader behaviour can bypass your av, e.g. if it doesn't
create downloads as files but hides them in some proprietary internal
format, or if it "helpfully" auto-runs them for you after download.
I don't know that any such badly-designed crapware exists, but given
the lack of clue in the sware industry, it's only a matter of time.
4) Pre-filter the av scanner with your own judgement
Think of av as your "goalie of last resort". If your own judgement
makes you suspect a file, then don't "open" it, no matter what the av
says about it. There will always be some malware missed by av.
>---------- ----- ---- --- -- - - - -
[x] Always trust Microsoft
>---------- ----- ---- --- -- - - - -
>>And the txt file was picked up only by NAV AutoProtect. (I run both
>>AVG and NAV, but for some reason AVG gets them first. When AVG gets
>>them, NAV never sees them, but if I "Disable Resident Shield" in AVG,
>>then NAV finds them.) NAV caught the text file both when I downloaded
>>it, and when I just clicked on it and displayed it a browser window.
The difference may be:
1) Scope: AVG not set to scan .txt files, but NAV is
2) False negative: AVG missed genuine malware
3) False positive: NAV mis-detected spurious malware
>To follow-up my own post, a while back someone in another win98 group,
>and I think someone here also told me that Norton warned against
>running two antiviruses.
Yep; that's good general advice. I prefer one or none on-access av
plus any number of on-demand av, where the latter are used serially so
that at any time only two av are involved.
In your case, it seems as if the two av are properly serialized, i.e.
AVG is always scanning first. You could get a "deadly embrace" effect
if the two process overlap, where neither can complete until the other
completes; no clean way out.
The impact of underfootware av goes about latency and failure to exit.
The process that they are patching into does not expect the extra
latency, which becomes massive if the av stops to put up a dialog box
so that the process descends into human timescale. If the av kills or
blocks the file, then the process it is patched into may crash, fail
to work, throw up errors (best-case scenario) or abort.
If the two av are not properly serialized, then you may get a crisis
when the first av deletes or blocks what the second av is trying to
scan. For example, let's say one av extracts files from a compressed
file and begins to scan them, then another av does the same. The
second av extracts the files in a different order or is faster,
detects a problem before the first one, and blocks or deletes the
parent file. The first av then hits an unexpected condition (the
unavailability of the file it's working on) and poos out.
>Someone asked why I would want to. This illustrates exactly why. For
>whatever reason, forseeable or not, AVG didn't catch the .txt file.
The point is, multiple av is far less effective than layering one av
on top of alternate av strategies, such as risk management.
All av will be prone to fail in the same conditions, so they mesh
poorly as multiple protection layers. For example, a custom-written
attack, or too-new-to-detect malware, will waltz right through every
av layer; the sender's PC, the sender's ISP, your ISP, your multiple
on-access av, and your multiple on-demand av. But if it was dependent
on a manageable risk that you had blocked, that would stop it dead.
Don't expect to hear this from av vendors, but the truth is; your av
should be but one component of your overall anti-malware strategy, and
the "last resort" one at that. If you feel warm and safe when
unexpected av alerts pop up, then you are missing the point; every one
of those alerts means your other strategies had FAILED and you were
exposed to a risk that should never have arisen.
>To assume an AV would (n?)ever miss a virus is to assume it's
>perfect and that I always got new definitions at the earliest time possible.
Quite. But when Slammer goes global in 10 minutes, your "I'm safe
because I update my av daily" asertion falls apart.
>So...everything would be perfect if I could figure out how to make NAV
>test the files before AVG does. NAV loads before AVG does. Maybe it
>would be better ? if it loaded second, but I don't know how to arrange
>that either.
It doesn't go about which av loads first, though it may go about which
is installed first. It goes about how and where they patch into the
OS's file handling code.
But no-one's talked about scope issues, i.e. whether either or both av
are set to scan everything. I'd rather have one av with broad scope
than a whole bunch of lazy av that let through "safe" files unscanned.
>-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -
AntiVir does. As soon as you access the directory... ALARM BELLS!!! It even
detects viruses in zip files within zip files.
Download these and try yours...
http://www.eicar.org/download/eicar.com
http://www.eicar.org/download/eicar.com.txt
http://www.eicar.org/download/eicar_com.zip
http://www.eicar.org/download/eicarcom2.zip
If you want to read about those files first, go here:
http://www.eicar.org/anti_virus_test_file.htm
Then try this...
--
AntiVir (R) personal edition - free for personal use only
From H+BEDV Datentechnik GmbH
http://www.avup.de/personal/en/avwinsfx.exe
>On Thu, 13 Mar 2003 21:05:56 -0500, meirman <mei...@invalid.com>
>>In symantec.support.win95.nortonantivirus.general on Thu, 13 Mar 2003
>
>>>And the txt file was picked up only by NAV AutoProtect. (I run both
>>>AVG and NAV, but for some reason AVG gets them first. When AVG gets
>>>them, NAV never sees them, but if I "Disable Resident Shield" in AVG,
>>>then NAV finds them.) NAV caught the text file both when I downloaded
>>>it, and when I just clicked on it and displayed it a browser window.
>
>The difference may be:
>
>1) Scope: AVG not set to scan .txt files, but NAV is
No, I checked that before I posted.
>2) False negative: AVG missed genuine malware
Yes, I'm sure that's the case, but the question is, How come his
caught it and mine didn't. I said I was using ver. 4.0.461, and
asked if his version was newer. Now I see mine is date 2/26/03 so I
don't think his version can be newer. (Now I remember. That was the
time the automatic definion download said the new definitions wouldn't
take effect until I restarted Windows. That's because it updated the
program too, not just the defs.)
>3) False positive: NAV mis-detected spurious malware
>>To follow-up my own post, a while back someone in another win98 group,
>>and I think someone here also told me that Norton warned against
>>running two antiviruses.
>
>Yep; that's good general advice. I prefer one or none on-access av
You're right that personal preference is important. I would not want
to rely on on-demand. Although I don't have it set to virus check on
open, copied, or moved, I do have it set to check on Run, Created, or
Downloaded.
Hmmm. These are norton classifications, and all of a sudden I'm not
so sure what they mean. When one copies a file from A to B, I have
it set not to check when it is opened for copying, but what about when
the destination file is created a second later. Doesn't it check that
for viruses, since I have "Created" checked?
>plus any number of on-demand av, where the latter are used serially so
>that at any time only two av are involved.
>
>In your case, it seems as if the two av are properly serialized, i.e.
>AVG is always scanning first. You could get a "deadly embrace" effect
>if the two process overlap, where neither can complete until the other
>completes; no clean way out.
So wouldn't the worst thing that could happen be the need to
cntl-alt-delete, or to press reset? And any viruses dl'd in that
batch wouldn't be disposed of, and that batch of email would have to
be processed again. But if this happened more than once, I'd probably
stop running both.
>The impact of underfootware av goes about latency and failure to exit.
>The process that they are patching into does not expect the extra
>latency, which becomes massive if the av stops to put up a dialog box
>so that the process descends into human timescale. If the av kills or
>blocks the file, then the process it is patched into may crash, fail
>to work, throw up errors (best-case scenario) or abort.
>
>If the two av are not properly serialized, then you may get a crisis
>when the first av deletes or blocks what the second av is trying to
>scan. For example, let's say one av extracts files from a compressed
>file and begins to scan them, then another av does the same. The
>second av extracts the files in a different order or is faster,
>detects a problem before the first one, and blocks or deletes the
>parent file. The first av then hits an unexpected condition (the
>unavailability of the file it's working on) and poos out.
>
>>Someone asked why I would want to. This illustrates exactly why. For
>>whatever reason, forseeable or not, AVG didn't catch the .txt file.
>
>The point is, multiple av is far less effective than layering one av
>on top of alternate av strategies, such as risk management.
What do you mean by layering, and would it apply to automatic scanning
of files about to be saved.
>All av will be prone to fail in the same conditions, so they mesh
>poorly as multiple protection layers. For example, a custom-written
>attack, or too-new-to-detect malware, will waltz right through every
>av layer; the sender's PC, the sender's ISP, your ISP, your multiple
>on-access av, and your multiple on-demand av. But if it was dependent
>on a manageable risk that you had blocked, that would stop it dead.
>
>Don't expect to hear this from av vendors, but the truth is; your av
>should be but one component of your overall anti-malware strategy, and
>the "last resort" one at that. If you feel warm and safe when
>unexpected av alerts pop up, then you are missing the point; every one
>of those alerts means your other strategies had FAILED and you were
>exposed to a risk that should never have arisen.
What strategy should have preceded getting an alert when an attachment
to an incoming email contains a virus?
>>To assume an AV would (n?)ever miss a virus is to assume it's
>>perfect and that I always got new definitions at the earliest time possible.
>
>Quite. But when Slammer goes global in 10 minutes, your "I'm safe
>because I update my av daily" asertion falls apart.
I never asserted that. In fact I was saying that one couldn't count
on an AV program to catch every virus and that was why the chance a
virus would be caught would be higher if he used two AV's.
>>So...everything would be perfect if I could figure out how to make NAV
>>test the files before AVG does. NAV loads before AVG does. Maybe it
>>would be better ? if it loaded second, but I don't know how to arrange
>>that either.
>
>It doesn't go about which av loads first, though it may go about which
>is installed first. It goes about how and where they patch into the
>OS's file handling code.
Thanks.
>But no-one's talked about scope issues, i.e. whether either or both av
>are set to scan everything. I'd rather have one av with broad scope
Both are. Like I said (or intend to say above), I didn't have
heuristic testing turned on for AVG -- I thought of it as always
secondary and then didn't revise that setting until now -- but I do
know.
>than a whole bunch of lazy av that let through "safe" files unscanned.
Thanks
>
>>-- Risk Management is the clue that asks:
> "Why do I keep open buckets of petrol next to all the
> ashtrays in the lounge, when I don't even have a car?"
>>----------------------- ------ ---- --- -- - - - -
>>>>And the txt file was picked up only by NAV AutoProtect. (I run both
>>>>AVG and NAV, but for some reason AVG gets them first.
..)
>>The difference may be:
>>1) Scope: AVG not set to scan .txt files, but NAV is
>No, I checked that before I posted.
OK. It may be that the av's internal scan logic applies only some
scans on files or a particular type, even if scanning that type - this
is more likely on on-access scanning, which is more performance
sensitive. To clarify that, I'd get out of Windows and from DOS mode,
rename the file to an active type (e.g. .exe), making sure the file's
location wasn't such that it would automatically run (in prctice, I'd
move it another location in case some runpoint entry pointed to it).
Then back in Windows, I'd re-test or re-scan.
>>2) False negative: AVG missed genuine malware
>Yes, I'm sure that's the case, but the question is, How come his
>caught it and mine didn't. That was the time the automatic definion
>download said the new definitions wouldn't take effect until
>I restarted Windows. That's because it updated the program too)
There you are :-)
>>Yep; that's good general advice. I prefer one or none on-access av
>You're right that personal preference is important. I would not want
>to rely on on-demand.
You'd choose "one" rather than "none" on-access scanner, in that case
:-)
I'm comfy with on-demand only, as my frontier is well-defined.
I'm the only system user, my web browsers don't run scripts or active
content, I'm rarely online (dial-up with "pick-a-card" variable IP
address), my email app doesn't auto-run anything, incoming attachments
are created as files on download, and there's no P2P or messaging
applications running to bring stuff in.
So it's easier for me to manage what risks there is - all I need are
twoi QuickLaunch shortcuts, one to scan/kill A: and one to scan/kill a
Suspect subtree to which incoming emaul attackments and downloads are
directed. But this is very much a best-case risk-management scenario.
For most folks - those with poor or absent risk management, using crap
email sware that hides attackments and autoruns content, as well as
those where multiple users share a PC - I'd advise an underfootware av
set to scan everything (if system can tolerate the performance impact)
But in preference to adding further underfootware av, I'd apply risk
management instead. The two strategies mesh better.
>Although I don't have it set to virus check on open, copied, or
>moved, I do have it set to check on Run, Created, or Downloaded.
>Hmmm. These are norton classifications, and all of a sudden I'm not
>so sure what they mean. When one copies a file from A to B, I have
>it set not to check when it is opened for copying, but what about when
>the destination file is created a second later. Doesn't it check that
>for viruses, since I have "Created" checked?
The other problem is that some of these activities are not
"primatives". Where a single monitorable API is involved, you have a
true primative that can be watched; I suspect "run" may be such, where
raw code is concerned, as may be "created", but "download" is unlikely
to be unless the av patches into the modem data stream.
Various apps may download differently, so if the av defines "download"
as "via IE, Netscape and a handful of other known downloading apps",
other processes may download but not be monitored. Even using an
unfamiliar (to the av) download accelerator may have that effect.
Hacking is about exploiting assumptions and exceptional circumstances,
which may abound when it comes to scaling back from "scan all file
types on all forms of access". My gut feeling is one up-to-date av
scanning everything may be better than multiple avs scaled back from
scanning everything in the interests of tolerable performance.
>>In your case, it seems as if the two av are properly serialized, i.e.
>>AVG is always scanning first. You could get a "deadly embrace" effect
>>if the two process overlap, where neither can complete until the other
>>completes; no clean way out.
>So wouldn't the worst thing that could happen be the need to
>cntl-alt-delete, or to press reset?
Well, that's way bad enough for me. I aim to make that never happen,
and chasing up malware is a part of that quest... also, a bad exit
midway through dealing with malware can be a Really Bad Idea, as it
may seed the startup axis and then *force* a bad exit to activate this
>And any viruses dl'd in that batch wouldn't be disposed of, and
>that batch of email would have to be processed again.
But this time, they may be active - and once active, the role of
convenient Windows-based av is ended, IMO.
>>The point is, multiple av is far less effective than layering one av
>>on top of alternate av strategies, such as risk management.
>What do you mean by layering,
No particular technical meaning; just what it sounds like - adding
multiple layers of protection that a malware would have to pass
through. Each layer is leaky; the trick is to prevent all the gaps
lining up so that there's benefit to each layuer added.
Else you end up with a thick, performance-sufforcating blanket with
tunnels drilled right through from one end to the other - not even a
tisue-paper cover to have to push through.
>>All av will be prone to fail in the same conditions, so they mesh
>>poorly as multiple protection layers. For example, a custom-written
>>attack, or too-new-to-detect malware, will waltz right through every
>>av layer; the sender's PC, the sender's ISP, your ISP, your multiple
>>on-access av, and your multiple on-demand av. But if it was dependent
>>on a manageable risk that you had blocked, that would stop it dead.
>>Don't expect to hear this from av vendors, but the truth is; your av
>>should be but one component of your overall anti-malware strategy, and
>>the "last resort" one at that. If you feel warm and safe when
>>unexpected av alerts pop up, then you are missing the point; every one
>>of those alerts means your other strategies had FAILED and you were
>>exposed to a risk that should never have arisen.
>What strategy should have preceded getting an alert when an attachment
>to an incoming email contains a virus?
Any strategy that robs the malware of the oxygen it needs to survive,
or breaks the assumptions on which it is based. Examples:
1) Engine dependencies
Malware written to be interpreted by a particular engine can't run if
that engine is absent. For "engine", think both in terms of
intentional engines such as WSH (WScript.exe, CScript.exe),
SHSCrap.sys, MSHTA.exe, email apps that auto-run scripts, MS Office
apps, Command.com etc. as well as software flaws that act as de facto
engines, e.g. IE's MIME hole and others.
2) Other assumptions
For example, default path names such as C:\Windows, "C:\My Documents"
and that sort of thing. This is a "weak" protection layer, in that
it's near-trivial for the clueful to dodge these issues. But as it's
often the least-clued attention-starved kiddies who use the heaviest
payloads, it's worthwhile, and it's free.
3) Entry points
Never assume your frontier will be solid; plan on secondary defence
against post-entry escalation as well. Goes about data hygeine (so
intrusions can be spotted as the only .exe where none should exist,
etc.) and secondary entry points from which code can be auto-run; not
using "View As Web Page" or active desktop, not processing AutoRun.inf
on hard drive volumes, not write-sharing C:\ or Windows subtree (i.e.
not exposing the startup axis) and so on.
To re-state the approach differently:
1) That which you don't need to risk, wall out
- if you don't use scripts, kill scripting engines
- if you don't use .bat, ?kill Command.com
- if you don't use .hta, .hlp, .shs, .shb, kill their engines
- avoid hole-y software; where you can't, then patch
2) That which you may need to risk, assess first
- make sure the systerm does not bypass your control
- make sure you get the info you need (e.g. don't hide .ext)
- upgrade yourself on "safe hex" skills
3) That which you decide to risk, av-scan first
- with a well-defined frontier, can go on-demand only
- but for most users, on-access is recommended
4) Don't be an asshole, i.e. don't expose others to risk
- practice "safe hex" when sending attachments
- don't use commonly-exploited sware
- don't auto-hoard email addresses ("auto-add to addybook")
- don't use To: or CC: for multiple address lists
- be responsable if using constant-IP, always-on broadband
>>Quite. But when Slammer goes global in 10 minutes, your "I'm safe
>>because I update my av daily" asertion falls apart.
>I never asserted that. In fact I was saying that one couldn't count
>on an AV program to catch every virus and that was why the chance a
>virus would be caught would be higher if he used two AV's.
The word "your" doesn't apply to you in particular.
Were it not for the fact that I never make that assertion either, I
might have used "our" instead :-)
>>But no-one's talked about scope issues
One of the classic penetration strategies is to break up activities
into small parts that lack recognisable intent, then sneaking each
component though in different ways.
For example, raw code within a .txt file cannot run, so even if set to
"scan everything", an av may not scan for that type of risk, as it
doesn't represent a primary threat. However, it becomes a secondary
(or post-penetration) threat if something else gets to rename the file
later, and that something else can be a one-off whisp of fluff that's
too small and generic to show up on radar.
Attempts to be "smart" have left a littany of embarrasments in the
history of av software; the ever-increasing bad .ext list, the
exclusion of "Recycled" from scanning, etc. There's no doubt that the
av industry adds value to the defence of the infosphere, even if it
amounts to palliative debulking surgery rather than a cure, but you
can't just leave your defense to av sware alone.
So far, av vendors have remained focussed on the auto-spreading
malware, in keeping with the "anti-VIRUS" brief. They generally turn
a blind eye to commercial malware in particular. But as the rise of
spam shows, an equivalent risk may arise from a launcher-and-bot
distribution model, where the malware encountered in the field does
not contain any spreading capability.
This differs from the usual cross-platform model, where the idea was
to create malware that could spread accross platforms, as if the
differences between these did not exist. What I forsee is malware
that exploits these differences to leverage each platform in different
ways, e.g. spreading through a backbone of exploitable fat-bandwidth
servers and attacking consumer systems from there.
With all the spreading code on the server, this launcher could vary
the attack bots in ways that cannot be anticipated from analysis of
the bots themselves. In fact, if in control of a fat-bandwidth
server, the launchers themselves can be augmented by additional logic
from off stage. The av vendors can't analyse what they don't have.
>----------------- ----- ---- --- -- - - - -
Clippit Millennium says:
"It looks like you're writing a virus. Need some help?"
>----------------- ----- ---- --- -- - - - -