From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Show me the Virrii!

Valdis.Kletnieks@...edu replied to me:

> > I think anyone who thinks they'll break into contemporary mainstream 
> > antivirus research (which is very heavily dependent on access to huge 
> > repositories of malware samples) by side-stepping such issues is  
> > severely deluding themselves...
> 
> "Research" isn't what you're doing when you're planning to figure out how to
> stop the *next* new attack by studying the terabytes of examples of how that
> idea didn't stop the attack last time.

I largely agree with you (more later), but you're also wrong to the 
extent that many products do in fact have a fairly high degree of 
success at detecting many previously unknown things.

And, of course, your comments hold just as much for all the IDS 
"researchers" who are not really doing research devising (hopefully) 
pre-emptive detectors/blockers and all the behaviour analysis 
"researchers" who are devising (hopefully) pre-emptive analysers/ 
blockers and so on.

> What you're doing there is milking a cash cow rather than finding a new way to
> actually fix the problem right.

Yep.

Trouble is, to some (fairly large??) extent, it seems the cow is happy
-- perhaps even desperate? -- to be milked.  Fred Cohen showed years 
and years ago (in the process of doing the research for his Ph.D.) that 
the virus detection problem is fundamentally intractible in real time 
(it reduces to the Halting Problem) and suggested that the only kind of 
functionality we could build into, or add onto, operating systems to 
make them fairly virus-tolerant was something of the general form of 
Jason Coombs' posted code.  IIRC, Cohen called these "Intergity Shells" 
and although he made one after graduating, as I recall he couldn't make 
it marketable.  (With the benefit of hindsight we can see that he had 
the disadvantage of trying to do it in a personal computer market where 
memory usage, disk latency and CPU churn just from managing the moment 
to moment (single-tasked!) operation of the computer were nearly 
crippling.  He also faced the serious technical disadvantages of the 
target OS not having any file system access controls and it all being 
designed not only without memory protection but for a CPU that had no 
hardware support for the same.)

Anyway, all the very early "antivirus" products (they didn't by any 
means all use that term to classify themselves back then) followed his 
basic lead with what were essentially "integrity assurance" approaches. 
Very few of these products enjoyed any significant market success, but 
some fairly strong market forces swung the antivirus developers to 
using "known virus scanning" approaches (and flung most who refused to 
adopt the approach from the scene).  It turned out that in the rough 
and ready pioneering days of DOS -- well before the notion that "a 
computer on every desk" may one day be the norm and, in fact, when even 
a computer _terminal_ on most desks was pretty rare apart from in 
universities, research labs and some government departments -- people 
wanted to play fast and loose with "unknown code".

And they did not want to be asked questions about what their programs 
should do!  Developers of several early behaviour monitor/blocker 
products quickly discovered that the Halting Problem applied to them 
too and to avoid horrendous false positive rates that would have had 
their products quickly dropped entirely, they resorted to asking the 
"Are you sure?" an awful lot, rather than "automatically" protecting 
the user (as the user expected).  This tactic probably delayed the 
dropping of their products for an average of several days to several 
months, depending on the thickness of their users' hides...

Another thing the early AV developers noticed was that, rather than 
being very cautious with unknown code, most (early) PC users seemed to 
prefer to take the (generally very small) risk of possible infection 
(or damage from a Trojan), but if they did become infected they really 
wanted to know _what_ it was that had hit them.  I guess it's part of 
our intellectual wiring, but very early in the piece antivirus 
developers were clearly told by a significant proportion of their 
customers that they wanted (even needed) to be told what had hit them.  
To _me_ (a bona fide techie) it is most odd, but it seems most computer 
users, given the choice between being told some unknown danger had been 
averted because an unauthorized low-level disk write had been blocked, 
and being told _after_ the event that their last two weeks work (which 
of course they had not backed up) was deleted by the "DiskKiller virus" 
[whatever...], _preferred_ the second option.

You know what they say -- there's nought as queer as folks...

So, as much as we can point out the glaring technical deficiencies in 
known virus scanning, the fact so much of it sold today is largely tied 
to the historical fact that it is what was preferred yesterday.  This 
is, of course, much the same reason we have the Wintel monopoly...

...

Anyway, back to my opening comment.  Several years ago now (in 2000??) 
I presented a paper at the Virus Bulletin conference titled "Why you 
should stop using virus scanners".  It pointed out that, as you say, 
the "addictive update model" ((C) Rob Rosenberger) is milking a cash 
cow (and unnecessarily so from the corporate customer's perspective).  
At least, that is the case in the corporate sector.  I strongly suspect 
that virtually all home users and most small (even most small-to-
medium) businesses do not have the IT skill (or at least the foresight) 
to provide a sufficiently systems-oriented approach to running their 
computers to be able to successfully use integrity management-oriented 
replacements for virus scanners.  Those dependent on consultants to act 
as their sys-admins could pay a little more for up-front for setup and 
system configuration, but then easily save as much per year in reduced 
site visits, support calls, etc.  (Of course those consultants aren't 
going to cut off a tidy little earner by recommending a better solution 
if their clients are already married to the notion that when it comes 
to AV you have to suck it and see...)

Of course, Jason's nifty little hack is not complete -- to really work 
well it would have to handle all manner of other file types that can 
contain programmable code, such as embedded macros, interpreted scripts 
and so on (and just handle those parts of such files that represent the 
program code).  However, it is an interesting starting point for anyone 
wishing to play around with some kind of integrity management system as 
there are precious few such tools out there, at least for Windows 
systems (I'm always interested in hearing of any such systems, 
commercial, GPL, freeware, etc...).


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

Powered by blists - more mailing lists