VIRUS-L Digest Tuesday, 15 Oct 1991 Volume 4 : Issue 190
Today's Topics:
re: Virus-writing course for teenagers
Re: Azusa Virus hits University of Kentucky (PC)
Ohio Virus #5 (PC)
Re: Hardware/Software/Safe Machines
Hardware
Manners
Theory
Interesting?
Gymnastics
15xx virus info??
SafeMBR v1.3 (PC)
What damage does the Jerusalem virus do? (PC)
Re: Forget Turing...
Re: Hardware, hardware...
A new version of virus (PC)
Bontchev paper finally available in ASCII now
Version 84 of McAfee anti-virus programs now available (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Sat, 12 Oct 91 00:22:06 +0000
>From: Rotan <
[email protected]>
Subject: re: Virus-writing course for teenagers
On 10 October Y. Radai observed the syllabus of a science for yourth
program which proported to include: (Comments from radai@hujivms)
> Assembler. In this language you'll be able to acquire tools for things
> which cannot be done in any other language, like: how to 'create
> viruses', how to write protection programs and how to crack them.
Furthermore, it is stated that:
> Needless to say, the matter has been brought to the attention of the
>program director, and it is expected that the above applications will
>not actually get mentioned when the course is presented. It has also
>been suggested that part of each course be devoted to a discussion of
>computer offenses and rules of ethics.
I don't see how avoiding mentioning such matters would avoid the
further proliferation of virus-like entities. To deny our most able
members of society the knowledge of such matters is a form of
censorship that, frankly, I cannot accept. Certainly, I accept the
worries that to afford people the knowledge of how such "viri" are
constructed would possibly invite further development of the offending
viri. But denial is not the correct manner or civilized way in which
the problem should be tackled. To co-present the techniques of virus
construction with the ethical considerations is perhaps the most
desirable approach. Personally, I think the "course" as described,
was so presented to attract a large audience with the heightened
"mystique" of the latest and most pertinent problem concerning
computer professionals. To do so, I think, was not correct. The motive
may have been to encourage more people to attend the course. If this
is the sole motive, then such a presentation is unjustified.
Nevertheless, the virus problem is with us today. It should not be
ignored. The most able people should be given the knowledge to tackle
this problem. I suggest that such courses in "virus construction" be
given. However, it is essential that this knowledge not be misused.
Therefore careful guidance in the ethics is required. Sadly, in a
world which seems to belittle the rights of software/hardware
developers, it is hard to find any ethical foundation amongst the
computing community (except where there is an obvious or potential
financial risk). The medical community have established reasonable
ethical frameworks. Isn't it time the computer community did likewise?
Let's not hear any more about cencoring information about viri and
concentrate more on ensuring that the people who compose our community
are more responsible with the knowledge that is given to them. In
times past, knowledge of a computing technique was always considered
beneficial, now such knowledge has the potential for harm. The
circumstances in which the computer professional finds h**self have
changed. It is time we changed too, and stopped trying to deny the
apparent reality which surrounds us.
Rotan Hanrahan,
Department of Computer Science, Belfield, Dublin 4, IRELAND.
------------------------------
Date: Sat, 12 Oct 91 01:11:46 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: Azusa Virus hits University of Kentucky (PC)
[email protected] (Tanu Kartawiria) writes:
>The Azusa virus was also found in Long Beach State University Lab,
>SCAN and CLEAN found it, HOWEVER, VSHIELD doesn't seem to be able to
>block it.
Hello Tanu,
VSHIELD will prevent you from rebooting the system off of an
Azusa-infected disk (or a disk infected with any other boot sector
virus that it recognizes), however, if a student were to cold boot the
system off of his/her infected disk and then access the hard disk, the
virus would transfer to it. VSHIELD would not report it's presence
until the next time it was run.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Sat, 12 Oct 91 04:14:45 +0000
>From:
[email protected] (Chris Miller)
Subject: Ohio Virus #5 (PC)
Does anyone know anything about a virus called the Ohio Virus #5? It
supposedly affects the boot track on msdos machines.
Our entire dos lan at school is supposedly infected with this virus,
and I would very much like to know how to detect it and eliminate it .
If you know anything about this, I would appreciate some E-mail from you.
Thanks in advance,
- -Chris Miller
------------------------------
Date: Sat, 12 Oct 91 12:42:00
>From:
[email protected]
Subject: Re: Hardware/Software/Safe Machines
In his reply to Fred Waller (virus resistant machine)
Henk de Groot writes:
>He forgets that some data-files are also program files (not for the
>cpu but for a program on the program-disk) and a virus written in the
>interpreted language can infect all the other "data" files of this
>interpreter.
>(...)
>(...) but if I write a virus in his spread-sheed language and put it on
>his machine, then after usage all his spread-sheeds are infected. If it
>is a distructive virus than I may distroy all his spreadsheeds on
>friday the 13th.
I admit that Fred's machine won't make any sort of virus impossible -
but that's not needed. They are like biologic germs: if they aren't too
contagious, not very destructive or easy enough to cure, you can live
with them.
I think Henk's `interpreter-viri' would be much easier to live with
than the machine-code-viri of today:
1) As today's viri need only a compatible Operating System to infect a
computer, there are a lot of potential victims for them. Interpreter
viri need `their' interpreter *running* on the target system, so the
density of infectable computers is much lower in space/time. This
would slow down the spreading speed of this viri.
2) A machine code virus uses the instruction set of the OS/BIOS, which
is specially designed to do things like deleting, formatting, bending
interrupts... An e.g. `spreadsheet virus' would have to do with the
instruction set of the spreadsheet's interpreter language, designed
for totally different tasks. While it might be possible to write
self-propagating destructive programs in such a language, the coding
of such neat things as stealth techniques would be quite difficult.
The Antivirus-programs could still use all of the (BI)OS's services
for their task and so the fight would be no longer `software vs.
software' but `machine level program vs. high level language' -
much better, compared with today!
Axel
************************************************************************
* Axel Gutmann, UH2M@DKAUNI2 Internet:
[email protected]*
************************************************************************
------------------------------
Date: Sat, 12 Oct 91 08:57:25 -0700
>From:
[email protected] (Fred Waller)
Subject: Hardware
Writes
[email protected] (David Conrad):
> Yes, a write-protect tab will stop all viruses. It will also
> stop all application programs which write any data to the disk.
> In fact, it renders disks almost useless for storage, except
> for invariant programs and data.
If we could, just for a moment, stop and think, and not get
carried away by impulse (or habit), we'd realize that the simplest
hardware devices offer us, already completed, the solutions that
software producers have been promising us for years...
If the humble write-protect tab presents problems as well as
a solution, why not try to work around the problem, rather than
throw away the baby with the bath water..?
Fred Waller
[email protected]
------------------------------
Date: Sat, 12 Oct 91 08:58:17 -0700
>From:
[email protected] (Fred Waller)
Subject: Manners
The thread is lost to me but someone wrote not long ago:
> This whole thread is rediculus.
> -------..... -------.....--------
> I hope this will stop this stupid converstion.
The subject of hardware protection is not ridiculous nor is the
series of articles on it a "stupid conversation". If a given
subject is of no interest to someone, s/he can always skip it.
Or marshall argument, if not agreeable.
However, qualifying someone else's postings as "ridiculous" or
the articles as "stupid conversation" is not likely to cause the
targeted author(s) to stop writing or to change their mind. In
fact, it's almost guaranteed to have the opposite effect.
Mature persons do not reject contradiction; they handle it.
Inability to face contradiction is a sign of immaturity.
Fred Waller
[email protected]
------------------------------
Date: Sat, 12 Oct 91 08:59:25 -0700
>From:
[email protected] (Fred Waller)
Subject: Theory
Writes
[email protected]:
> Cohen has described a hardware mechanism that cannot be
> subverted by software. It is called the application machine.
> It is a computer such as...
I would hope that just because Cohen has described it, it isn't
the *only way* to do things... :-)
> We recognize that progammability is too valuable to give up
> simply in the name of resisting viruses.
For some users, that may depend on how many viruses they end up
meeting, or how frequently, or how valuable data integrity is for
them. But no one has asked to give programmability up yet. What
may be necessary, however, is to give up certain habits and modes
of hardware implementation, the same ones that have made the virus
threat possible. Such changes are related only moderately to ease
of use, or flexibility, or data interchangeability among users.
(*my* understanding of "moderately", of course...)
It may also become necessary to modify certain programming habits/
methods.
Ultimately, nothing is free. To ask for protection and be unwilling
to sacrifice any freedom is quite unrealistic. Neither software nor
hardware will ever give us that.
Fred Waller
[email protected]
------------------------------
Date: Sat, 12 Oct 91 08:56:27 -0700
>From:
[email protected] (Fred Waller)
Subject: Interesting?
Writes
[email protected] (David.M.Chess) on hardware
protection:
> Sure, no one's disputing that. The point is, though,
> that that fact isn't really interesting.
I think that depends on the direction of one's interest. If one
is mainly a theorist and seeks ultimate (or at least very basic)
theoretical justification, the statement may seem unattractive
at first if it wasn't presented in a theoretically-attractive form.
But if one is a practically-oriented person who seeks to solve
problems on a day-to-day basis, the statement may seem very
attractive and interesting. The reason is simple: hardware
protection DOES stop viruses. In reality.
> It doesn't, for instance, imply that a hardware-based
> protection method would keep a system free of viruses
> in the real world.
The fact is, it has done that. In practice. Hardware protection
doesn't need taxon-specificity and the large amount of constant
disassembly work that this, in turn, requires. Hardware protection
can be implemented at lower long-term cost than software protection,
in part because it's of a more general nature. Hardware protection
*doesn't care* what variety of bug is coming your way, or what it's
name is, or whether it's ingenious or not - it just stops'em!
All these are good reasons.
> A virus can't defeat hardware protection by itself; on the other
> hand, it will invariably have help, because people always want to
> run new software on their systems, or otherwise want to open up
> the software-space of their storage media for writing now and then.
But doesn't the same reasoning apply to software protection? Users
can defeat both hardware protection and software protection just as
easily. However, while activated, hardware protection is more nearly
totally invincible than any software scheme I know of.
Fred Waller
[email protected]
---------------------------------------------------------------------
Eppur si muove!
---------------------------------------------------------------------
------------------------------
Date: Sat, 12 Oct 91 09:01:10 -0700
>From:
[email protected] (Fred Waller)
Subject: Gymnastics
Writes
[email protected] (Gene Spafford):
> The problem comes about when trying to reduce the
> frequency of these errors to an acceptable threshold,
> and to be sure that no Type II errors occur. Picking
> any arbitrary levels of confidence may result in an NP
> problem, but not an intractable one.
That is so true. As we engage in mental gymnastics trying to
determine whether Fred Cohen does or doesn't understand his own
theories, one thing tends to be relegated to the background:
physical reality.
Viruses have become, more than anything, a practical problem. If a
practical solution is stumbled upon, we can forgive the stumbling
and adopt the solution. At least, I certainly can.
The modified computing machine described in Fred (Waller's) reply
to Jay Skeers works. It works at stopping incoming viral infection,
and it works at restricting spread of infection after it has started.
No software product is capable of doing that.
It works better, longer and more reliably than any software antivirus
product known. It is not a perfect solution, perhaps because there
are no perfect solutions to any problem.
Like any other protection, it can be disabled. Yes, a user can flip
the switch OFF and disable it. But the same user can also disable
any software protection with the same ease. There is no inherent
vulnerability in hardware that software is not also vulnerable to.
In fact, software has a great many more vulnerabilities than even
the simplest hardware protection scheme.
> So, could we please stop claiming that it has been proven that
> no perfect virus detector can be built, or that finding viruses
> is an intractable problem?
I've seen this claim of a "perfect antiviral detector" over and
over here. Many people make this claim, and many have announced it
- but NOBODY is able to produce such marvel. As soon as someone
writes an antiviral program that is as effective as a write-protect
switch at stopping virus infection IN REALITY (not just in theory),
I'll stop suggesting that such dream cannot be achieved.
In the meantime, we can continue saying: while no viral attack
is known that cannot be defended against with software, the reverse
is also true: no antivirus exists that cannot be subverted, also by
means of software. It's an endless merry-go-round.
You say it isn't so? Then prove it. In practice.
> It's not surprising, really, as the concepts of Turing
> machines and intractability are not well understood --
> especially by systems hackers. :-)
Well... let's keep in mind that all programmers are hackers. They
explore and learn to use (more or less well) the machines that
hardware designers create, build and make available to them :-)
Fred Waller
[email protected]
------------------------------
Date: 12 Oct 91 18:21:07 +0000
>From:
[email protected] (Thomas Oates)
Subject: 15xx virus info??
Can anyone give me any information on the 15xx (1591/1575) virus? My
computer was just infected with it. I found it the same day that it
was infected and got rid of it using Clean, but I would still like
info on it.
E-mail is ok.
Thanks,
Thomas Oates
PS: if this is a FAQ, please let me know.
- --
***********************************************************************
** Thomas Oates
[email protected] **
** Georgia Institute of Technology - ICS(CS) Undergrad **
***********************************************************************
------------------------------
Date: Sat, 12 Oct 91 17:59:50 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: SafeMBR v1.3 (PC)
Version 1.3 of SafeMBR (FreeWare) now checks to see if it has been
already installed to prevent multiple installations from overwriting
the original MBR code. It is still recommended that the MBR be backed
up to floppy before installing SAFEMBR just in case.
Padgett
------------------------------
Date: 12 Oct 91 22:38:46 +0000
>From:
[email protected] (David Wright)
Subject: What damage does the Jerusalem virus do? (PC)
Sorry to ask a naive question to this group, but I don't know where else
to find the info I need. I don't have FTP access so I can't go find the
latest and greatest virus info list even if I knew of one.
A friend has a PC on which "Characters slide off the screen when
running Wordperfect and you have to hit some keys twice. I think
we've got that Friday 13th virus, and I don't know how to get rid of
it". Fortunately they had a disk that came on one of the PC mags with
an old version of the McAfee anti-viral kit (v61), plus an old DOS
system disk, which unlike most of their floppies were write-protected,
so we scanned and cleaned their disk. Scan said it was the Jerusalem
virus, and clean [Jeru] removed 127 infections from 20 odd different
files (as you'll know, Jerusalem merrily re-infects files). I'll go
over it again when I next see them with a more up to date package, but
I think the system is clean now.
However, their copy of Wordperfect no longer works - the machine
crashes with "Illegal Instruction Trap". The latest McAfee Virus
Characteristic List shows that Jerusalem "corrupts program and overlay
files" but I can't find more details. Possibly clean did the damage -
the documentation does warn that it can truncate files that use
overlays. But it is also possible that the virus had started
currupting things.
They were probably running the machine over a month with the virus
(given the likely source) and that included Friday 13th September.
What is Jerusalem likely to have done to their system, and
particularly to their files?
Technical details of machine - early 386DX with 32M disk (all one
partition) running DOS 3.3. CHKDSK shows no errors.
Please reply by mail as most readers of this news group will either
already know or not be interested - I'll summarise if anyone wants me
to.
Thanks,
David Wright BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA, UK
[email protected] <or> ...uunet!mcsun!ukc!stl!dww <or> PSI%234237100122::DWW
------------------------------
Date: Sun, 13 Oct 91 19:15:00 +0300
>From: Y. Radai <
[email protected]>
Subject: Re: Forget Turing...
Gene Spafford writes:
>What Cohen proved in his thesis was that a program to exactly detect
>all viruses on a Turing machine was an intractable problem. That is,
>you cannot write a program that will run on a Turing machine and will
>print "infected/not infected" with 100% accuracy for any arbitrary
>program on that same Turing machine.
.....
>#2. The proof shows that you cannot build a perfect detector on a
>Turing machine. However, the proof depends on the fact that the
>theoretical Turing machine has unbounded space for programs/data, and
>has unbounded time to run. If you bound either, the proof no longer
>holds.
.....
>Now, consider that real machines have bounded time and space for
>execution of programs. The intractability result DOES NOT hold on
>these machines.
First of all, a terminological point. Infallible detectability of
viruses, the halting problem, equivalence of programs, truth in formal
systems, etc. have been proved *UNDECIDABLE*, not "intractable". The
term 'intractable' means something quite different. Informally, it
means *computationally infeasible*, i.e. the problem is solvable, but
the amount of time (or of space) required is too large to be practi-
cal. A classic example of an intractable problem is factoring a very
large number, say 200 digits long. This is possible, but apparently
intractable because the currently fastest general-purpose algorithm
(PPMPQS) on the fastest computer (Cray 3) would require hundreds of
thousands of years.
The formal definition used in computability theory, complexity
theory, and modern cryptology goes something like this: For each
solution there is a function giving the amount of time required for a
given length of input. Then an intractable problem is defined as one
for which there is no solution for which this function is bounded by a
polynomial. (In particular, if the best solution is exponential, the
problem is by definition intractable.) In this sense, factoring by
an algorithm such as PPMPQS is intractable, independently of the size
of the number and the computer used.
Now to the main point: Cohen's theorem shows that whether a given
program is a virus or not is undecidable. I.e., there cannot exist a
procedure which inputs an arbitrary program or program segment and
always correctly decides whether or not it is a virus, where a virus
is a program which infects other programs (Cohen adds: "by modifying
them to include a possibly evolved copy of itself", but the definition
of 'infect' is not essential to the proof). The proof (which was
obviously inspired by the well-known proof that whether a program
halts is undecidable) is extremely simple: If there were such a
decision procedure D, we could write a one-statement program P:
If D(P) = non-virus then infect something.
If D(P) = non-virus then P infects, so D is wrong. If D(P) = virus
then P never does anything, so again D is wrong.
Note, however, that the proof depends on the fact that a virus is
defined, not as a program which *contains* viral code (and which is
therefore only *potentially* a virus), but as a program which *actual-
ly* infects other programs in some cases. Moreover, Cohen states that
what has been shown by the above proof is that determination of a
virus *by its appearance* is undecidable. (He claims that determina-
tion by behavior is also undecidable, but he does not draw that con-
clusion from the above proof alone.) But given these two assumptions,
it is easy to see that the result is true even *without* resorting to
Cohen's proof. For if P contains a statement of the form "If
<condition> then infect" where <condition> is something that can be
determined only at *run* time, then it is clear that D, by merely
examining the *appearance* of P, cannot tell whether or not that
condition is sometimes satisfied or never satisfied. Moreover, the
proof *does not depend on the assumption of a Turing machine*.
That leaves the possibility of D's decision being based on the
*behavior* of P instead of on its appearance. I'm willing to suppose,
purely for sake of argument, that in this case, the fact that an
actual computer is not a Turing machine *might* allow the possibility
of a correct decision procedure *in principle*. However, I'm sure
that if such a solution exists, it would be *extremely impractical*.
We agree that Cohen's result need not discourage us too much. How-
ever, the reason is simply that a procedure which never has any Type-
II errors and only very rarely gives a Type-I error is not ruled out
by his theorem and would still be very useful. However, I do not
agree with your main thesis that the distinction between a Turing
machine and an actual computer is significant here. I think almost
anything you can say about a Turing machine is also true of an actual
computer if you add the phrase "for all practical purposes".
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Sun, 13 Oct 91 19:19:00 +0300
>From: Y. Radai <
[email protected]>
Subject: Re: Hardware, hardware...
Henk De Groot writes:
> If you claim that a virus can not go
>resident on your system than that implies that your system is clean.
>If your system is clean you can not infect a floppy, protected or not!
I am not going to get involved in the hardware issue per se; I only
wish to take exception to the above statement of yours. Haven't you
heard of the Vienna virus (with its 42 variants)? of DataCrime? of
1260 and the other V2P* viruses? These are *direct-action* viruses,
i.e. they spread on execution *without going resident*. Even if you
haven't heard of them, I think you should have taken into account the
possibility of their existence before you started throwing around
phrases such as "rediculus" and "this stupid converstion" [sic].
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Sun, 13 Oct 91 16:17:11 -0400
>From: Bhanu M. Kuchibhotla <F26BB%
[email protected]>
Subject: A new version of virus (PC)
Hi folks,
I recently heard from a friend of mine who says ther is new virus
on the prowl which changes its signature fron time to time (frequency unk-
nown). Is this true? If at all this is, then the all the virus detection
software which rely on signature detection ( I guess all detection software
do) will prove futile. I guess it would be very hard to detect such viruses.
Any comments or discussion welcome.
Bhanu MK
------------------------------
Date: Tue, 15 Oct 91 10:50:12 -0400
>From: Kenneth R. van Wyk <
[email protected]>
Subject: Bontchev paper finally available in ASCII now
Special thanks to Axel Gutmann for TeXing Vesselin Bontchev's paper,
"The Bulgarian and Soviet Virus Factories," and sending me the .DOC
file! The paper is now available in TeX, PostScript, and ASCII
document formats on cert.sei.cmu.edu in the pub/virus-l/docs
directory.
Ken
------------------------------
Date: Fri, 11 Oct 91 18:23:16 -0700
>From:
[email protected] (McAfee Associates)
Subject: Version 84 of McAfee anti-virus programs now available (PC)
I have uploaded to SIMTEL20 and Garbo:
pd1:<msdos.trojan-pro>
SCANV84.ZIP Scans standalone and networked PC's for viruses
CLEAN84.ZIP Virus removal program for PC's, LAN's
VSHLD84.ZIP Infection-prevention TSR for PC's
NETSCN84.ZIP Scans network file servers for viruses
NEW RELEASE OF McAFEE ASSOCIATES SOFTWARE
Version 84 of the VIRUSCAN, VSHIELD, CLEAN-UP, and NETSCAN programs
has been released in order to detect a new virus that has been
reported from Eastern Europe. The new virus, named DIR-2, is a
stealth virus that uses a new way of infecting files that required
this rewrite of the software in order for it to be 100% effective
against it. The only other change to the software is that the VSHIELD
program can now be loaded into high memory on systems running DOS 5.
Beginning with this release we have compressed the software in order
to save disk space and file transfer time.
The validation information is as follows:
CLEAN-UP V84 (CLEAN.EXE) S:68,283 D:10-04-91 M1: 35DE M2: 0AAC
NETSCAN V84 (NETSCAN.EXE) S:50,345 D:10-07-91 M1: 04F9 M2: 1773
VIRUSCAN SCANV84 (SCAN.EXE) S:51,870 D:10-07-91 M1: 9008 M2: 03A7
VSHIELD VSHLD84 (VSHIELD.EXE) S:33,819 D:10-07-91 M1: EC7E M2: 0334
Aryeh Goretsky
McAfee Associates Technical Support
- - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 190]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
