VIRUS-L Digest Monday, 1 Apr 1991 Volume 4 : Issue 51
Today's Topics:
Request for information - Robert Morris Internet worm (UNIX)
Re: "Six Bytes" (PC)
Re: Taking out A: & USSR BBS
Stoned & Yale virus (PC)
"Six Bytes for Virus Detection" paper available (PC)
Anti-viral contact list (PC)
More reviews on archives
Call for papers - SIGSAC
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: 30 Mar 91 03:44:32 +0000
>From:
[email protected] (Andrew Gallo)
Subject: Request for information - Robert Morris Internet worm (UNIX)
I am writing a paper to analyze the effects of the Robert T.
Morris Internet worm of 1988. I am collecting information and
opinions from system managers on the following topics:
o What effect did the attack have on your computer system. How long
was your system effected? What was the estimated damage in
dollars?
o How was the worm removed from your system? How was information
about the "cure" shared within the network community?
o What effect, if any, did the attack have on your perception of
computer security? What measures have you taken to prevent
further attacks?
o Robert Morris was convicted and ordered to pay $10,000 and serve
400 hours of community service. Was this ruling fair? What
effect has this ruling had on deterring further computer
crimes?
Any and all information you can offer is appreciated.
Please respond via email to
[email protected].
Thank you.
Andy Gallo
------------------------------
Date: Sun, 31 Mar 91 01:54:00 -0800
>From:
[email protected] (Morgan Schweers)
Subject: Re: "Six Bytes" (PC)
Greetings,
Actually, an extremely simple method of generic 'virus detection'
for viruses which infect on execute (or open) is to create a program
that records the FREE DISK SPACE, then opens a file named 'TEST.COM'
and fills it with 8192 copies of 'INT 20h', then spawns out to execute
it. The free disk space is loaded again, and compared against the
original minus 16384. (8192*2 bytes of code.) This should
successfully handle all cluster-sizes, etc. If the values aren't
equal then there is Something Wrong(tm).
Admittedly, it won't work on all viruses, but it sure will handle
the large majority of them. Another useful trick is to have your
CONFIG.SYS SHELL your COMMAND.COM from a different filename, and load
it over to a RAMDISK in your AUTOEXEC.BAT... Then (of course) set
COMSPEC=<ramdisk>:\COMMAND.COM... It speeds up your system, too!
<Grin> (It helps against some of the Stealth viruses, but only a
little...)
There are dozens of little precautions you can take to protect
your system from viruses. None of them will work in all cases (the
most difficult being the direct action viruses... Stopping them
easily is *ANNOYING*) but they do provide a modicum of security.
I'll point out that Padgett Peterson has a reasonably correct idea
in stating that the place to start from *IS* from the boot sector, or
the partition table. It's a cleaner environment down there, and can
be checked *MUCH* easier.
A total system checkout is feasible, as frisk has suggested. If
you have a memory resident virus, it *CAN* be detected. Period. For
it to work *WELL*, you have to know your system. If you don't know
what's on your computer, it's tough for an AV product to accurately
tell you what's *NOT SUPPOSED* to be there.
In relation to that, I'll put in my two cents about the six
bytes... For a technician helping out a non-PC-literate user, it's
probably a good thing. For a technician helping out a user with lots
of specialized drivers, and/or unusual partitioning stuff, etc., it's
can lead one down the wrong path entirely, if used as the FIRST check
on a system.
-- Morgan Schweers
P.S. It sounds strange, I suppose, but if you're the type of person
who takes precautions about possible 'new' virus infections,
then you're a lot less likely to be the kind of person who GETS
new virus infections.
+------------
"The views expressed within are the opinion of the author only. Nobody
could possibly be crazy enough to support these views. My memory may be
faulty, or could even have a parity error..."
--
[email protected],
[email protected]
- ------------+
------------------------------
Date: Sun, 31 Mar 91 02:05:00 -0800
>From:
[email protected] (Morgan Schweers)
Subject: Re: Taking out A: & USSR BBS
Greetings,
I recently recommended to a network site that they lock their 'A'
drives with a network boot diskette in them. Their 'B' drives should
remain unlocked for data transfer. There are many companies that make
disk drive door-locks, and this is a much 'nicer' solution than
removing the drive entirely. In fact, one could lock the drive doors
WITHOUT a disk in them, thus forcing a boot from the HD, and still
allowing access to the B drive by anyone (and access to the 'A' drive
by the computer-manager).
The person commenting on the 'USSR BBS's' was SPECIFICALLY (as I
recall) talking about the 'pro-virus' BBS's in the USSR. This is why
they commented on the possible increase in virus spreading rates. The
actual number of BBS's available from outside of the USSR is
statistically insignificant for the tracking of viral spread.
Moreover, as was said, BBS's are a very *RARE* way for viruses to
spread (with the exception of BBS's dedicated to viruses). In fact,
the current leader in virus statistics is the Stoned virus, a virus
that is NOT INFECTIOUS through BBS's without hard work. <Chuckle>
-- Morgan Schweers
+-----
"Don't believe a word this man says. He's insane." --
[email protected]
"Everything he says is true. He's the only sane person." --
[email protected]
The contents of this message are the authors opinion, which (obviously) varies
with many random variables. Everything is true, nothing is permissible.
- -----+
------------------------------
Date: Mon, 01 Apr 91 01:33:21 +0000
>From:
[email protected] (rutledge shawn d - CS250)
Subject: Stoned & Yale virus (PC)
Can someone tell me what the stoned virus does exactly? Its been
going aroung and I've heard things from overwriting text files with
"Stoned Stoned..." to "messing" with the FAT. Can someone confirm
this. Also I would apriciate a description of the messing part. What
does it really do?
Second, what is the Yale virus. I have no clue on this one. It
showed up using IBMs freeware scanner. I find no mention of it in
SCAN documentation, although I have not tried to actually run SCAN on
an infected disk to see if it comes up under some alias.
------------------------------
Date: Fri, 29 Mar 91 16:35:24 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: "Six Bytes for Virus Detection" paper available (PC)
[Ed. This is the beginning of Padgett Peterson's paper, "Six Bytes for
Virus Detection in the MS-DOS Environment". The complete paper is
available by anonymous FTP on cert.sei.cmu.edu in pub/virus-l/docs
under the filename six.bytes.padgett.]
WARNING: The method depicted in this paper will not detect every conceivable
virus, to do so would take far more than six bytes. What it will
do is to detect all currently "common" viruses for a knowlegable user,
however, CHKDSK can do the same thing if intelligently applied. A
short .COM file following these principles will make a good "first
check" before using a scanner to determine if something unknown
might be resident.
Some viruses revealed immediately include Brain, Yale, Datalock,
Stoned, 4096, Fish-6, Flip, Whale, Joshi, MusicBug, and Azusa.
TSR viruses such as the Jerusalem, Sunday, and 1701/1704 variants
will also be revealed if the user is knowlegable about the system.
Padgett Peterson, 3/29/91
Six Bytes for Virus Detection
in the
MS-DOS Environment
A. Padgett Peterson, P.E.
Orlando, Florida
Introduction
Concerning the size of the population (over fifty million MS-DOS
platforms at last estimate), to the macro, the 240+ known viruses
represent a relatively small statistic. In the micro however, they
can be devastating.
With the growth in size of fixed disks and applications, often
backups are obsolete or incomplete where proper discipline has not
been established. Unfortunately, this seems to include the majority
of the non-power users.
Since the number of known viruses appears to be doubling each
year, the threat is not diminishing, yet the most accepted utilities,
John McAfee's SCAN & CLEAN, rely on detection of known infections.
While there are some products that actually perform integrity
management of a system (Certus International CERTUS, Enigma-Logic
VIRUS-SAFE and PC-SAFE, Fischer International PC-WATCHDOG, Dr. Panda
BEARTRAP), most are oriented to file protection rather than system
protection.
To adequately protect a machine that possesses no native
integrity management requires a layered approach of user management,
files/applications management, and systems management. We have a good
handle on the first two but the question of systems integrity,
something so pervasive in mainframes that it is taken for granted,
does not currently exist for the PC.
Until recently, a large enough population did not exist of not
only successful but also unsuccessful viruses to draw any inferences
concerning their viability in the general population. At the close of
1990, however, certain characteristics of "successful" viruses, those
listed as "common" in Patricia Hoffman's Virus Summary, have become
clear:
1: Become resident in memory following infection
2: Allocate memory to themselves
3: Redirect part of the operating system (not necessarily interrupts)
Each of these elements is easily detected, often in more than
one way, yet few people or programs bother to look. Some years ago,
this author wrote three simple assembly language programs, each
about 1k bytes long. The first tests file integrity, the second tests
disk integrity, and the third tests system integrity. Taken together
these still detect every "common" virus, not because they "know" all
viruses but because they "know" an uninfected system. There is
nothing magical involved, merely a knowledge of how the architecture
operates.
This paper does not address those viruses that attach themselves
to programs or files specifically, rather consideration is made to
those that attack elements of the operation system. That these
infections may later attack programs or files is incidental. Rather,
a description is provided of the third of these routines.
------------------------------
Date: Mon, 25 Mar 91 12:32:47 -0800
>From:
[email protected] (Rob Slade)
Subject: Anti-viral contact list (PC)
A second version of the list of contacts for PC antiviral products.
Again, I have included the notation "product not available" to indicate
that I have not received review copies from the companies involved. I
have not included this notation after a number of very recent additions
to the list.
[Ed. Again, for space considerations, the remainder of this text can
be obtained by anonymous FTP from cert.sei.cmu.edu in
pub/virus-l/docs/reviews under the filename slade.vendors. This is
probably a good time to point out that email access to this and other
VIRUS-L/comp.virus FTP archive sites is achievable - please refer to
the monthly archive site update (April's should be available shortly)
for instructions.]
=============
Vancouver
[email protected] | You realize, of
Institute for
[email protected] | course, that these
Research into (SUZY) INtegrity | new facts do not
User Canada V7K 2G6 | coincide with my
Security | preconceived ideas
------------------------------
Date: Mon, 01 Apr 91 11:21:01 -0500
>From: Kenneth R. van Wyk <
[email protected]>
Subject: More reviews on archives
Chris McDonald, <
[email protected]>, has graciously given
us a series of product reviews which he has written on various
anti-virus products for both the PC and the Mac. The reviews are all
available by anonymous FTP on cert.sei.cmu.edu in
pub/virus-l/docs/reviews. The following files are currently
available:
mcdonald.avsearch - AVSEARCH, version 2.23 (PC)
mcdonald.disinfectant - Disinfectant, version 1.5 (Mac)
mcdonald.fprot - F-PROT, version 1.14 (PC)
mcdonald.norton - Norton Antivirus, version 1.0 (PC)
mcdonald.sam - Symantec Anti-Virus for Mac, version 3.0 (Mac)
mcdonald.virexmac - VIREX, version 3.0 (Mac)
mcdonald.virexpc - VIREX, version 1.1a (PC)
mcdonald.virucide - VIRUCIDE, version 2.01 (PC)
mcdonald.viruscan - VIRUSCAN, version 6.3V75 (PC)
Ken
------------------------------
Date: Mon, 01 Apr 91 10:42:10 -0500
>From: Kenneth R. van Wyk <
[email protected]>
Subject: Call for papers - SIGSAC
I received the following Call For Papers from Dr. Harold Highland. In
order to save space, I've removed the list of the competition
committee members from this Call. The complete text is available by
anonymous FTP on cert.sei.cmu.edu in pub/virus-l/docs under the
filename call.for.papers.sigsac
Ken
=====
Date: Sun, 17 Mar 91 15:19 EST
>From: "Dr. Harold Joseph Highland, FICS" <
[email protected]>
Subject: Call for papers - student paper competition
- ------------------------------------------------------------------------------
Dr. Harold Joseph Highland, FICS
Distinguished Professor Emeritus of State University of New York
Managing Director of Compulit Microcomputer Security Laboratory
Editor-in-Chief Emeritus of Computers & Security
Telex: +1-650-406-5012 MCI Mail: 406-5012 Voice: +1-516-488-6868
Electronic mail:
[email protected]
- ------------------------------------------------------------------------------
CALL FOR PAPERS
Student Paper Competition: Computer Security, Audit and Control
Sponsored by ACM/SIGSAC
The purpose of this paper competition is to increase the awareness of security,
audit, control and ethics as they apply to the computing field. SIGSAC will
award $1,000.00 to the student or junior faculty member whose paper is selected
by the review committee as the outstanding contribution of the year.
The contest is open to all full-time undergraduates, graduate students and
junior members of the faculty of a recognized or accredited institution of
higher learning. Only those who have not previously had a paper published in
a referred journal in which he or she was the lead or sole author will be
eligible for the award.
----------------------------------------------------------------------
| Papers must be received by the SIGSAC Competition Committee Chairman |
| on or before October 7, 1991
|
----------------------------------------------------------------------
SIGSAC reserves the right to publish any submitted paper, whether selected for
a prize or not, in SIGSAC Security, Audit and Control Review. Author will be
notified about acceptance of his or her paper for publication within 90 days
after the announcement of the contest winner.
SUGGESTED TOPICS
Access/authentication control
Administrative policies, standards and procedures
Audit concerns for data communications
Auditing in computer security
Banking industry security
Communications security
Computer crime
Computer law
Computer security audit techniques
Computer viruses and other threats
Contingency planning
Crypto systems and encryption
Data integrity and security
Database security
Distributed systems security
Dynamic signature verification
Education for computer security
E-mail systems security
Electronic funds transfer
Ethics and security
Expert systems in security
Formal specifications and verification
Information system security
Key management
Local area network security
Logging and accountability in security
Medical databases and security
Microcomputer security
Modeling security requirements
Multi-level security
Network design for security
Network security issues
Office automation security
Open communications and security
Operating systems security
Operational assurance in security
Passwords: management and controls
Penetration testing as an audit tool
Physical security
Privacy and security
Protecting programs and data
Risk analysis and assessment
Risk management
Smartcards and security
Telephone intrusion threat
Tokens as a security tool
Trusted systems
Use of microcomputers in an audit environment
User authentication
INSTRUCTIONS TO AUTHORS
[1] The manuscript must be typed double-spaced on one side of the page with
one-inch top, bottom and side margins. All illustrations must be in
camera-ready form. An abstract [maximum of 100 words] should be included on
the first page. Style and format of the paper should follow the form used in
Communications of the ACM.
[2] Manuscript is limited to a maximum of 25 double-spaced typewritten pages.
[3] The author's name, address and any references to a university must not
appear in the paper. Acknowledgements, if any, must appear on a separate page.
[4] Five (5) copies of the paper [quality photocopies will be accepted]
should be submitted together with a covering letter and the additional
information requested as contained in this announcement.
[5] A floppy disk [3 1/2" or 5 1/4" standard or high density format],
preferably in DOS ASCII format, should also be included.
[6] All copies should be sent prior to October 7, 1991 to:
Dr. Harold Joseph Highland, FICS
SIGSAC Competition Committee
562 Croydon Road
Elmont, NY 11003-2814 USA
Telephone: [+1] 516-488-6868 Telex: [+1] 650-406-5012
MCI mail: 406-5012 E-mail: Highland -at dockmaster.ncsc.mil
- --------------------- Author Information Entry Form ------------------------
[Please reproduce in typewritten form and submit with paper]
Title of paper .....................................................
Author's full name .................................................
Full name of school ................................................
Author's home address ..............................................
Author's school address [if applicable] ............................
Telephone number ...................................................
E-mail address .....................................................
Name of faculty advisor<1> ..........................................
Full address .......................................................
Telephone number ...................................................
E-mail address .....................................................
Degrees held or year at college ....................................
Previous publications [if any]; list title(s), publication in which
article appeared and date .........................................
- -------
<1> For junior members of faculty, please list department chairman
- -----------------------------------------------------------------------------
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 51]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253