AV does more to confuse than to clarify. I don't mind if they redefine these
things, but they should do it by consensus and not have every company
using a different definition.
Part of the problem is the dated mindset that a malware is entirely
one or another type of entity. This dates from when malware
(especially viruses) were written in low-level languages that took a
great deal of effort to do the smallest things.
Also, these early malware tended to work in spite of the environment,
rather than making use of it. This in turn reflected the nature of
DOS, which generally loaded a program into RAM and then left it alone.
Today, it's easy to get existing software to do malicious things for
you - so instead of having to do everything by hand, you can use a
high-level language to strap together existing functionalities in
interesting ways. Think of it as the difference between
cut-and-pasting up a picture in Photoshop, with drawing that picture
by hand by setting each pixel value, one at a time.
The original archetypes were:
- boot virus, infexcting pre-file-system code that boots disks
- file virus, infecting existing code files
- worm, a la the Morris worm on UNIX
- trojan, a la PKZIP300 or AOL4FREE
The original trojans were entirely passive, and leveraged the
pre0Internet BBS scene. They would be posted up to Bullitin Board
Systems to look like interesting downloads, and so folks would
download them. Because PKZip hadn't been upgraded for years since
2.04g, , "PKZip 3.00" was very plausible SE. AOL4FREE also looked
sensible, given this online service provider's perchant for
limited-time free offers.
Nowadays, it's way more complicated. One malware may infect existing
code files yet also retain a dependency on a stand-alone "mother"
malware file that's integrated into the OS's startup axis. It may
drop itself as a tempting download within the shared folder of a
peer-to-peer file sharing app, much in the tradition of the original
trojans. And it may automate its spread over the Internet, thus
exhibiting worm-like behavior. Every stand-alone file is likely to
have a misleading name; that's trojan-like behaviour, etc.
How is something a backdoor 'trojan' if there is no opportunity
for the user to take part in the decision whether or not to
execute the program?
The SE applies to post-infection attempts to clean the system. Many
malware exist purely as stand-alone files that are integrated into the
OS, one way on another, and often they can be dis-integrated and
deleted with one's bare hands. While malware such as this do have the
opportunity to defend themselves, they often don't; instead, they rely
on cameoflage, so the user things they are legitimate parts of the OS.
installed backdoor is a backdoor - not a 'trojan backdoor virus'
as some scanners will report.
Ah, av reporting often blows chunks out both ends.
The primary unique value that av brings to the party, is the
below-the-eyeball ability to detect and clean intrafile malware, i.e.
viruses that infect the inside of existing files. That is the type of
hammer they are, and to that mindset, everything looks like a nail.
Reporting is automated, of course, and usually by fairly simple
algorithms that take a stock phrase like "VIRUS!!" and insert a
malware-specific name into it.
So you get inapporopriate messages based on yesterday's assumptions,
such as "UNABLE TO CLEAN %malwarename% VIRUS!!" whereas what's really
happening is, a self-contained malware has been found that has no
original non-malware context to be preserved, and thus should be
deleted rather than "cleaned".
Same goes for 100%-malware archives, as common lately. A
"document.zip" that contains a single 100%-malware file
"document.doc.pif" should be deleted entirely, but most av still fuss
about "not being able to clean infected files within archives".
McAfee's been in the business a long time
Well, that's where old mindsets come from
They define "virus" starting with "A computer program file..." yet
a boot sector virus might not have anything to do with files at all.
Quite. It's easy to forget boot code viruses exist - some observers
hint it's acceptable for av not to bother detecting them anymore - as
it's assumed impossible to infect NT with them.
Well, Witty demonstrates that it is quite possible to write directly
to raw disk, even from NT on NTFS. The "impossibility" is not,
therefore, in infecting the HD's pre-OS code, but in having that code
survive into NT after boot.
The assumption there is that a virus will want to survive in order to
spread, and has to do so at an atomic level - i.e. the same code that
lives as a BSV has to survive and spread.
These days, a BSV is more likely to be dropped from the bomb bay of a
file-level malware, than infect from booting an infected disk. Why
bother with pre-OS code at all? To defend the malware presence, take
punitive action against attempts to clean it, or hatch a payload.
I'm not picking on McAfee here, most AV vendors sites as well
as other virus related sites are just as bad about this.
True, but on a related issue - consistent unique names for specific
malware - they do have my sympathy.
When a new malware appears, the following has to happen:
- av vendors get a sample
- av vendors reverse-engineer the sample to detect it
- putative detection is tested for errors
- av vendors reverse-engineer the sample to clean it
- putative cleaning is tested for errors and side-effects
That's the raw code stuff; then there's this:
- is it a commercial software program?
- is it a known malware?
- is it a variant of an existing malware?
- what should we call it?
Then there's this:
- get the fixes into the next av update
- get the av update onto the site for download/push
- get it from there into client's installations
The problem is, av vendors may not have checked with each other to
ensure name consistency by the time the fix goes out, or they may
later discover a new malware is in fact a variation of an existing
one, or that what was thought to be a variation is brand new.
Should availability of detection and fixes be delayed to make sure the
name is spot-on? I don't think so
---------- ----- ---- --- -- - - - -
On the 'net, *everyone* can hear you scream
