[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3FFE1CD3.25941.2D1C5AFA@localhost>
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