Article View: comp.sys.amiga.tech
Article #11218Re: Viruses
From: Daniel Yaron Kimberg
Date: Sat, 28 Jan 1989 19:19
Date: Sat, 28 Jan 1989 19:19
64 lines
4511 bytes
4511 bytes
I hope people don't mind another go-around on virus protection. I think
it's a good thing to keep talking about.
In article <31622@vax1.tcd.ie> rwallace@vax1.tcd.ie writes:
>Two suggestions: First, is there any general way to check if a virus is in
>memory? Obviously any given virus can be detected but then your virus kiler
>will be obsolete as soon as the next strain of virus comes out. The general
>idea might be to inspect ExecBase, DOSBase, trackdisk.device and the like
>for alterations but they're not guaranteed to be the same from machine to
>machine.
...
>Or for a really far out idea, how about analyzing the startup code of each
>program that gets loaded to see if it looks like it's going to modify files
>and put copies of itself onto them.
These problems, unfortunately, are probably as complicated as the problem
of artificial intelligence. If you want a program that won't be obsolete
with each new virus, it would have to be able, essentially, to read code
and browse system structures and tell what they're doing. In essence, a
virus is just like any other program, which is to say that the only really
reliable way to tell if something is a virus or not is to check to see what
it does. The fact that there are more trivial ways to detect the current
viruses (even without knowing the specific virus) is misleading in this
respect - it can lead you to draw the conclusion that viruses can be detected
by heuristics. Even if that were 99.9% true, it would be a very dangerous
assumption.
Earlier in the message:
>The old boot block viruses were easy enough to protect against but now we've
>got viruses that put themselves in program files, it's time to give some
>serious thought to virus protection. Some schemes have been suggested recently
>about getting programs to check themselves, which as was pointed out is no
>good because by the time the program code gets to run the virus has done
>its dirty work anyway. Having another program do the checking is more sensible
>but the problem is once the virus is in memory it can intercept any attempt
>to read a program file and make it look like the file is uninfected.
As has been repeated frequently, the only really acceptable way to protect
yourself from viruses is to take the responsibility yourself (insert
analogies with AIDS here). Easier said than done. If you buy some software
from a software house you never heard of, who knows what it does to your
system? Probably the big ones aren't immune either. Another problem is
that you really have to put a lot of trust into your front line defenses.
Current viruses are detectable once they've entered your system, but future
viruses may be better at making themselves invisible. Being able to
detect viruses after they've infected your system is nice, but it's not
something you'd want to count on. I think the best
approach would really be to have all virus protection under user control,
but with help from software tools. For instance, it would be nice to be
able to maintain a list of all the executables you've decided to allow on
your system, along with their vital statistics. It would also be nice to
have a set of analytic aids to do things like check out the status of your
system, or try a range of clever heuristics on new programs. And frequent
use of write-protect switches and tabs would be important. It isn't enough
to just let viruses bounce around in your system, and hope your tools can
detect them. Once you've run an unfamiliar executable, whether you got it
from the net or in shrink-wrap from electronic arts, you've opened your
system. Anyway, the upshot of all this is that I think the best way to
go about virus protection is to develop useful preventative tools not of
the sort that sit in the background and do your checking for you whenever
you decide to run an executable, but of the sort that you can use to decide
what executables it's safe to run.
-Dan
Technical Details
Message-ID:
<5882@phoenix.Princeton.EDU>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!dykimberReferences:
<31622@vax1.tcd.ie>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!dykimber From: dykimber@phoenix.Princeton.EDU (Daniel Yaron Kimberg) Newsgroups: comp.sys.amiga.tech Subject: Re: Viruses Message-ID: <5882@phoenix.Princeton.EDU> Date: 28 Jan 89 19:19:38 GMT References: <31622@vax1.tcd.ie> Reply-To: dykimber@phoenix.Princeton.EDU (Daniel Yaron Kimberg) Organization: Princeton University, NJ Lines: 64