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 VIRUS-L@IBM1.CC.LEHIGH.EDU (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: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: 30 Mar 91 03:44:32 +0000 >From: gallo@cs.albany.edu (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 gallo@cs.albany.edu. Thank you. Andy Gallo ------------------------------ Date: Sun, 31 Mar 91 01:54:00 -0800 >From: mrs@netcom.com (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=:\COMMAND.COM... It speeds up your system, too! (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..." -- mrs@netcom.com, ms@gnu.ai.mit.edu - ------------+ ------------------------------ Date: Sun, 31 Mar 91 02:05:00 -0800 >From: mrs@netcom.com (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. -- Morgan Schweers +----- "Don't believe a word this man says. He's insane." -- mrs@netcom.com "Everything he says is true. He's the only sane person." -- ms@gnu.ai.mit.edu 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: srutledg@yoda.eecs.wsu.edu (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%tccslr.dnet@uvs1.orl.mmc.com (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: p1@arkham.wimsey.bc.ca (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 p1@arkham.wimsey.bc.ca | You realize, of Institute for Robert_Slade@mtsg.sfu.ca | 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 Subject: More reviews on archives Chris McDonald, , 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 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" 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: Highland@dockmaster.ncsc.mil - ------------------------------------------------------------------------------ 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