VIRUS-L Digest Monday, 5 Aug 1991 Volume 4 : Issue 137
Today's Topics:
Infects on ANY access?
Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16
Re: ME
Re: Proposal for standard virus signatures notation
Re: Info re viruses in shrinkwrap software?
Floppy Door Close TSR? (PC)
Viral operations in brief
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: Mon, 05 Aug 91 10:49:00 +1000
>From:
[email protected]
Subject: Infects on ANY access?
In trying to get myself upto speed on anti-viral techniques I came across the
following.
I quote from "The Complete Computer Virus Handbook", Price Waterhouse, Issue 2,
September 1989 - Appendix 1, Page 19.
Re the boot sector virus "Search" = "Den Zuk" = "Venezuelan".
DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....."
Now it may be just my understanding and usage of english words, but have I
really missed something about how DIR accesses a floppy disk?
[email protected]
------------------------------
Date: 26 Jul 91 01:01:40 +0000
>From:
[email protected] (Andrew McKendrick)
Subject: Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16
Will it possible to request a copy of the transcript of the this
conference after it has finished????
Andrew@fido
- --- LED 1.00
* Origin: 520StE... Is Modula-2 wirth it?. (3:681/854.3)
------------------------------
Date: Sat, 03 Aug 91 17:22:58
>From:
[email protected]
Subject: Re: ME
>From:
[email protected]
>I was somewhat taken back with Ross Greenberg's abraisive response
>(issue 125) to my posting (issue 119) about the anti-virus product
>review in the UK magazine PC Plus. Without plumbing the depths of
>personal abuse I would like to defend myself and respond to a couple
>of the 'criticisms' made.
Sorry: when someone attacks the professional integrity of a man I have
respect for and of a journal I further have respect for, it ticks me
off.
> My discussion was of the review in PC Plus, not of the similar review
> recently in the Virus Bulletiin. However if you are interested; Edward
> is certainly aware of our product but he did not request a copy for
> review. In fact the subject has never come up in our occasional
> conversations.
Hmmm. So, then you were aware of activity in the area, had made
Wilding aware of your package but didn't get around to sending him one
for review? Wilding probably should have requested a copy, but you
should certainly have sent him a copy. If you want to be included in
reviews, this is a good practice to start following.
>>Ah, but what you write *does* suggest that you have a problem with
>>either Hamilton's credibility or VB's or both.
>My intention was to raise awareness of magazine readers of the possible
>partiality of magazine reviews. Having seen all issues of VB, and even
>having contributed (at a time when I had no other commercial interest in
>the subject), I have had 2 years to form an opinion. However I shall
>not force this on anyone, but rather respect that other people's range
>from Ross's unstinting praise (well almost) to outright incredulity.
Not unstinting. I've had many a complaint about VB, but not about its
integrity. As for the potential problems with the accuracy of a
review in any pub, I would assume that most readers of this list have
seen many a review of a product in some publication that was totally
off base. That accuracy is based upon the individual reviewer as
edited by the editor; I've seen some factual errors in VB, but not
incorrect slants.
>I was present at one event that Hamilton subsequently reported on, and
>my recollection differed from his report in only one area; the behaviour
>of Hamilton himself and the subsequent response. This only underlines
>the lesson I learnt from seeing events and names mangled in local
>newspapers, seek corroboration of any news item that may affect you.
I've been in a pub and witnessedd Mark spill a pint on himself. That
does not somehow reduce his integrity.
Ross
------------------------------
Date: Mon, 05 Aug 91 12:27:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Proposal for standard virus signatures notation
[email protected] (Jan R. Terpstra) writes:
> After lengthy discussions with a number of people, three independant
> authors of virus scanning products and myself (as the keeper of the
> VIRSCAN.DAT virus signature file) have agreed upon a standard notation
> for virus signatures...
Good. A nice wee standard. Now watch someone come along and complicate
it! :-)
I didn't see anything about where the name comes into it. How about
having any line starting with a "#" giving the virus name(s) for the
signature string in the line (or lines) below. Furthermore, the first
name following the hash could be a hashcode (I gave the definition of
my method of hashcodes for boot sectors a while ago - I'll post the
updated algorithm and format, which now includes all sorts of file
types as well as boot sectors and MBR's as soon as possible).
And a "#" in a signature line could allow end-of-line comments.
Also, it might be useful to extend the signatures by including an "@"
to indicate absolute positions, with respect to the start of the file
of boot sector, or offsets from the initial instruction, or the end of
the file, etc. Such things might not be important now, but could be
in the future, and could make scanning a lot faster.
example...
# This is an imaginary signature file, by
[email protected]; 05-aug-91
#05BXP7B.E1R, "Stoned (variant 7a)", "PORTUGESE STONED"
@00:00@017B:B40206CD130914
#0TEEGYB.RB0, "Not harmful, MS-DOS 3.3 immunised by V-Basher 1.2"
17675A6C34D0@007E:17FFFF000023
#X587BG6.37Z-1280, "Dim Revenger virus"
19A6????53CD21ABBADABBAD00
##IF OS=OS/2
- -147:AC??55C9129B # for code segments >64K
##ENDIF
(What this means is...
*The first line identifies the file; it is taken as a comment, since there are
no signature lines before the next # line. It would be nice to finish each
first line with a date, since some methods of transferring files from computer
to computer cause the date-time stamp to be changed.
* Each field in the hash lines finishes with a comma and one of more spaces,
except the last.
* If a hashcode is given, it is straight after the "#", otherwise you would
have a space or spaces (no comma) before the first "name" field. I like to
leave 17 bytes for the whole hashcode field, so the first name field will
always start at column 20.
* The first name field is the main, preferred, easily understood, name.
* All name fields are enclosed within quotes (char 34), and end with a comma.
Probably it is okay having a comma within the quoted field. Most high level
languages should be happy with that.
* The first letter of the hashcode indicates the type of file -
0 - F indicate boot sectors,
G indicates a general file infector - could have any extension
I indicates an invisible-file (IO.SYS, etc) infector
M indicates an MBR (Master Boot Record, = Partition Table) virus
O indicates an overlay file infector (okay, these are rare)
P indicates a program infector (.COM or .EXE or .PRG or .BAS or whatever)
R indicates a string to search for in RAM, rather than on disk
S indicates a .SYS (system device driver) file
T indicates a text file infector (such as .BAT, or some application
data files)
W indicates a worksheet (spreadsheet) infector of some sort
X indicates a virus that only exists in .EXE files
* Any line starting ##IF specifies a block of signatures, etc to skip unless
a given environment variable has a given value. If environment variables
"TOM" (for Top Of Memory), "VER" (for O/S true version number), or "HIDOS"
aren't found, the program should make up a sensible value for them.
Note that is doesn't hurt if a simple scanner simply ignores any line starting
with "#", or a not-so-simple scanner remembers the last "#" line as a comment
to emit whenever it comes across a file matching a signature. But ultimately,
the signature file's format should remain useful for a long time, and scanners
based on such files could be made to run very fast (by applying a limited range
of scan patterns to some files, for instance, and by working on positional
information).
Comments on my comments are welcome, of course.
TTFN,
Mark Aitchison, Physics, University of Canterbury, New Zealand.
------------------------------
Date: Sat, 03 Aug 91 17:22:58
>From:
[email protected]
Subject: Re: Info re viruses in shrinkwrap software?
>From:
[email protected] (Greg Broiles)
>
>The latest issue of Byte has a cover story on viruses and security software -
>a rather disappointing article, truth be told. They do some rudimentary
>testing of a few antivirals and come up with a simplistic little
>reccommendations-box. Blech. :(
I did a tech article for BYTE on viruses a coupla years ago. Well,
that is I *wrote* a tech article. What appeared in print was some
horrid random assortment of words with verbs and nouns and everything
except any accurate statements. What was printed was a "co-authored"
piece, except that the co-author took what I wrote, pulled out things
she didn't understand ("Vectors? They only have direction and
speed...why would an interrupt have a vector?"), wrote a bunch of
inaccurate stuff about Mac's, changed code sequences I used to
identify one virus, decided that she, in her infinite wisdom, would
never have a need to show me the article she destroyed, and printed
it.
My coplaints rose high up into the BYTE masthead -- to the top -- and
were never responded to except with a "Gee, that's something that will
never happen again". No retraction. No apology.
Forget about BYTE's technical accuracy, at least with regard to viruses.
Ross
------------------------------
Date: Mon, 05 Aug 91 11:58:47 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Floppy Door Close TSR? (PC)
>From:
[email protected] (Jesse Chisholm AAC-RjesseD)
> Is there a TSR program available that scans a floppy whenever
>the floppy door closes? Is it even possible to write one? Are any of
>you all working on one (McAfee, Padgett, ...)?
Considered this but think it would not be the "best" solution. Unlike
the MAC, a PC does not execute anything merely by vitue of the door
being closed. Executables have to be invoked by the user (even ANSI
bugs are just designed to induce the operator to issue a command that
was not intended - an executable still has to do the work).
Consequently, there are two choices available that would have
approximately equal value:
1) Detect that a new disk has been placed in the drive & do a full checkout.
(time-consuming)
2) Examine executables as requested (includes warm-booting).
(relatively little performance impact)
For the above reasons, I personally prefer #2 and one of the layers on
my personal machines is McAfee's* VShield. As far as I know (& am sure
someone will correct me if wrong), this is the only currently
available software that will trap a warm boot and scan relevant
structures for known viruses before permitting the boot to continue as
well as checking anything requested from the disk.
Since my PCs are running DOS 5.0, I can afford the 25k for three
different anti-viral TSRs that IMHO give me ample protection from
malicious software, known & unknown, no one being considered
sufficient. Just FYI, one goes resident during the BIOS load, one from
CONFIG.SYS, and one from a .BAT file at startup (some other
checking/reporting goes also on but this is not resident).
Since a program to do this already exists and am still on negative
free time, what time that is available is reserved for software that
does not exist (yet).
Padgett
Disclosure: * is one of the lines the company I am associated with
handles. (properly worded, disclosure notices can provide free
advertising, no?)
------------------------------
Date: Sun, 04 Aug 91 20:36:27 -0700
>From:
[email protected] (Rob Slade)
Subject: Viral operations in brief
FUNGEN2.CVP 910804
Viral operations
Although the "original" definition of computer viral programs
refers to reproduction by attaching to other programs, viri that
act in this manner having been less successful than those that
use other means. In the personal computer world, boot sector
infectors have been much more effective. (Examples in the
MS-DOS community are the BRAIN and Stoned viral programs.
Examples in the Mac realm are not as clear, but the WDEF virus
could be said to be a type of boot sector infector, as the WDEF
resource is one that is run automatically as soon as any Mac
disk is inserted, although this has changed under System 7.)
In larger systems, mini and mainframe computers, network and
mail viral programs have, so far, had the greatest impact. The
Morris/Internet/UNIX worm managed to spread and reproduce using
the facility of networked machines to submit programs to each
other. (A VMS program, WANK, used many of the same techniques.)
The CHRISTMA EXEC used mainframe mail commands, and the ability
to submit programs by mail, in order to reproduce copies which
eventually flooded the network.
Network and mail viral programs carry, in a sense, their own
payload. The reproduction of the programs themselves uses the
resources of the hosts affected, and in the cases of both the
Morris and CHRISTMA worms went so far as to deny service to
users by using all available computing or communications
resources.
Most other viral programs seem to be written "for their own
sake". A kind of electronic graffiti which writes itself on
further walls. However, even these can do damage, as with the
Stoned virus, which overwrites sections of the FAT with the
original boot sector. Some appear to be written as pranks, and
others as a kind of advertising, although the potential for
damage from even "benign" viri cannot be considered funny, and
the "advertising" viri probably don't engender much goodwill.
Relatively few viral programs carry a deliberately damaging
payload. Those which do attempt to erase infected programs or
disks are, fortunately, self limiting.
The last payload, or function, which a viral program may carry,
is some kind of intelligence to enable it to evade detection.
So far the various kinds of evasive action; self-modification,
multiple encryption and "stealth" activity; have not proven to
have any advantageous "survival" characteristics. In one sense,
this is to be regretted, as it demonstrates that the majority of
computer users are not taking the most elementary precautions to
defend against viral programs.
copyright Robert M. Slade, 1991 FUNGEN2.CVP 910804
=============
Vancouver
[email protected] | "If you do buy a
Institute for
[email protected] | computer, don't
Research into (SUZY) INtegrity | turn it on."
User Canada V7K 2G6 | Richards' 2nd Law
Security | of Data Security
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 137]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
