Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA21390; Thu, 7 Jun 90 14:15:14 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA14414; Thu, 7 Jun 90 14:15:10 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA03804; Thu, 7 Jun 90 14:14:17 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa15922; 7 Jun 90 15:54 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:05:24 BST Message-Id: <$TGVGDBVHCNXX at UMPA> Subject: Virus-L vol 0 issue #0616 Virus-L Digest Thu, 16 Jun 88, Volume 0 : Issue #0616 Today's Topics Re: The Intruder Versus the Hacker Re: a few points Re: hidden files on VM/CMS Re: a few points Re: hidden files on VM/CMS Re: virii on large(r) machines forwarded review from Ted Shapin Re: a few points Christmas-card EXEC forwarded comments on compiler virus Rumor VM/SP: Two-files-in-one from reader Re: Sent VM/CMS viruses RE: Re: The Intruder Versus the Hacker Re: Sent VM/CMS viruses PC Anti-Viral Programs some more points Banish the List reply to "Banish The List" ------------------------------ Date: Thu, 16 Jun 88 00:46:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: WHMurray@DOCKMASTER.ARPA Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: WHMurray@DOCKMASTER.ARPA Subject: Re: The Intruder Versus the Hacker In-Reply-To: Message of 15 June 1988 14:15 edt from MALCOLM%JVAX.CLP.AC.UK at CUNYVM.CUNY.EDU > Well, he's got a point. Once someone's got a taste of the havoc they > can cause with their very own virus, would *you* trust them to look after > your systems? I can conceive of the circumstances under which I might. But the author of such an assignment has a much more difficult problem. He must trust fifteen or so people, all of whom have the pride of authorship that he has given them, never to let their creation out of the sterile environment. That is a much less sanguine situation. I might be willing to trust three people who were mature and informed, but to trust fifteen, at least some of whom are young, and about whom I can have at best a limited knowledge would be at least risky. Given the destructive potential of a virus, it is clearly unprofessional. ____________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) Ernst & Whinney ARPA: WHMurray @ DOCKMASTER 2000 National City Center MCI-Mail: 315-8580 Cleveland, Ohio 44114 TELEX: 6503158580 FAX: 203-966-8612 21 Locust Avenue, Suite 2D Compu-Serve: 75126,1722 New Canaan, Connecticut 06840 ENVOY 100: WH.MURRAY -------------------- Date: Thu, 16 Jun 88 00:58:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: a few points In-Reply-To: Message of 15 Jun 88 11:57 EDT from "me! Jefferson Ogata" The XMASCARD EXEC was reported in the Wall Street Journal and has been dicussed in this forum and in RISKS. It originated in BITNET where it was fairly benign, but passed into VNET via a gateway. When executed it displayed a greeting to the user and sent a copy of itself to everyone in the user's maillog and NAMES file. In VNET, where the number of users known to the typical user is numbered in the high tens to low hundreds, the number of copies created saturated the net. As to the exposure that you raise, it relates to DISKDUMP rather than to PUNCH. It has been fixed. The fix is very expensive. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 -------------------- Date: Thu, 16 Jun 88 09:44:06 CET Reply-To: Virus Discussion List Sender: Virus Discussion List From: Peter Vons Subject: Re: hidden files on VM/CMS In-Reply-To: Message of Wed, 15 Jun 88 14:17:57 EDT from Receiving multiple files with receive, where you only see one file in your reader is common practice within VM/CMS. Those files are generated with DISK DUMP with continous spooling of the punch. There is even a warning in the DISK DUMP help text about this. Even worse is that Receive only warns you if the visible file is already on your disk. The other (invisible) files are overwritten on existing files without any notice. I once got a PROFILE EXEC from somebody in this way without noticing. The next time I logged in again it was executed. I was lucky that it was not harmfull. I know that there are programs around on some Listservs which can signal this kind of readerfiles. Peter Vons (SOND0008@HASARA11) -------------------- Date: Thu, 16 Jun 88 11:45:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: a few points > One possible infection mode I've seen for VM/370 mainframes is an > EXEC I've seen that spools two punch files together to some user. > Only the first file appears in the header information, and there > is only one spool file. The result is that a user can transmit an > innocuous file to another person with some other file tacked on the > end. When the innocuous file is received, the other file is > received also. Don't ask me how it works.... Indeed this is (at least was) true. You can DISK DUMP two files together in a documented way, and only the first one will be announced in the header. The rest are only announced in the body itself. As I recall, if you DISK LOAD them back, you do get the list. This feature of DISK is actually useful, since it allows you to package up and send large collections of CMS files in one spool file. However, the RECEIVE command, as part of being 'user friendly', suppresses all output from the underlying functions it calls, and then you don't know if files have been overwritten. Don't know if this has been fixed in the mean time. I always used to DISK LOAD to an empty disk just to be safe. Michael -------------------- Date: Thu, 16 Jun 88 11:53:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: hidden files on VM/CMS > It uses disk dump format ... The only file that shows up to > RDRLIST or Q RDR is the first disk dump. It IS possible to check > whether the number of lines in the file matches with what a Q RDR > says, but how many people do that? More to the point, it is possible to find out what sort of reader file you have in your reader, and handle DISK DUMP files more carefully. I think the ipf RDR command will tell you this (but I don't remember the details). Michael -------------------- Date: Thu, 16 Jun 88 13:28:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: Re: virii on large(r) machines Hi folks, in his message from 06/15/88 O'Brien mentioned the topic of mainframe viruses. He writes that nothing is known about infections of mainframes or mainframe viruses itself. Thats not correct. Fred Cohen started his experiments with computer viruses on mainframes. The first virus was written for a VAX 11/750 system running UNIX (Ultrix?). The following experiments were carried out on a UNIVAC 1108 (running a Bell- LaPadula system), on a Tops-20, on a VAX running VMS and on a VM/370 system. So you can see that the first viruses were mainframe viruses and *NOT* PC-based viruses. But it seems to me that Fred Cohen was not the first one to implement self- reproducing code on a computer. I want to mention the work of J.Kraus from the University of Dortmund 1980/81 (3 years before Cohen). The title of the paper was "Selbstreproduzierende Software (self-reproducing software)". He gives a very complete theoretical background of selfreproducing software and some examples of such code in a real assembler language (SIEMENS assembler language; the same assembler language as the IBM/370 system but with a different operating system - but also a mainframe). Interesting note: You cant get the orignal work from 1980 but just a modified (and I think "moderate") version from 1981. Someone wants to keep things secret. :-( I wrote a replacing virus for a IBM 30xx running MVS/370 a year ago. Its about 600 lines long. Because my account on that machine is restriced to "harmless" applications after the system manager realized what I am working on, I was not able to improve the virus... What about "non-academic" virus infections on mainframes? I never heared of any case that was verified to be a virus infection. But there are some rumors about that. The first one I knew is related to the events in Berlin, January 1986. On Jan. 23,1986 some students at TU (technical university) Berlin announced a strike for better payment. These students are employed by the university to support younger students in their studies at the department of computer science. So the striking students are very knowledge- able of the IBM 4381 running VM. What happend? On Jan.31,1986 the mainframe performance was bad as never before. It was impossible to use the computer. The system managers noticed that many parts of the operating system and most application programs spend a lot of time to increase a counter and then to decrease the counter again before they start their normal execution. This "increase/decrease of useless counters" increases with time so some people expected to find a virus. Did they found one? I dont know. The mainframe was disconnected from all networks for 14 (!!) days and everything was analysed by computer stuff from IBM and the university. They "solved" the problem by generating a very new system and to "erase" all application programs. So if you want to know more about it I think you have to ask the TU Berlin, Department of Computer Science or IBM.... There are two or three more rumors about virus on mainframes but much less is known about the circumstances so I dont want to mention them here. All the best to you all, Bernd. +--------------------------------------------------------------------+ I "Beam me up, Scotty. There is no intelligent life down here..." I +--------------------------------------------------------------------+ -------------------- Date: Thu, 16 Jun 88 08:58:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded review from Ted Shapin From: Ted Shapin Subject: Review of IBM Protection Programs This file is IBMPROT.DOC. Reviews of Virus Protection Programs Please feel free to add to this list. Version 1, 6/15/88, T. Shapin ==================== Class 1 are programs that warn of changes to system files after the fact. These methods either compute some sort of CRC or hash sum, or compare a file against a copy of the file. While it is theoretically possible for a particular CRC to be forged, each program seems to use a different algorithm for the computation so that different values are obtained. Furthermore, each version of DOS will give a different values, so I doubt that the signature can be forged practically. ==================== CHKSUM.ARC, contains: CHKSUM.C, CHKSUM.DOC, CHKSUM.EXE, CRC16.C, STOI.C. From: Bob Taylor, compiled using Turbo C 1.5. What it does: Computes a redundancy check (CRC) for any file, (including system and hidden), and compares a computed CRC for a file with a specified one given as a parameter to the program. Wildcard file names and more than one filename can be supplied as parameters. Either gives a warning message or optionally sets a return code. On a vanilla 4.77 Mhz PC, it takes about 7 seconds to check all three system files. Evaluation: Fast and very useful. [T.S.] - - - - CHECK-OS.ARC, contains: CHECK-OS.DOC, CHECK-OS.EXE, CHECK-OS.PAS. From: R.J. Bartlett & Erik Ch. Ohrnberger Compiled with Turbo Pascal version 4.0. What it does: It checks the Filesize, File Date/Time (last updated), and Checksum of COMMAND.COM, AUTOEXEC.BAT, and CONFIG.SYS. Will also check system files. Evaluation: On my system it would not handle the "FCBS=" parameter in my CONFIG.SYS file. It needs some work. [T.S.] - - - - CHKUP14.ARC, contains: CHECKUP.DOC, CHECKUP.EXE, REGISTER.DOC. From: Richard B. Levin. BBS's: (215) 969-8379 or (215) 635-5226 Compiled Microsoft BASIC v.6.0 What it does: Compares a target file's size, its incremental checksum, and its total checksum. Evaluation: While the method of computing hash sums would be difficult to forge, it prints lots of messages when it runs, and there is no provision for returning error codes that can be tested in a batch file. I find the the lack of source code a minus and the appeals for money obnoxious. [T.S] - - - - CONDOM.ARC, contains: CONDOM.BAT, CONDOM.DOC, CPY.C, CPY.EXE, DIF.C, DIF.EXE, READ-ME.NOW. From: Charlie Ros5e [sic], Boulder, Colorado, BBS Fido Node 104/23, Account Name: Charlie Rose; and Gerry Williams, Albuquerque, New Mexico, BBS Fido Node 15/1001. DIF.C and CPY.C, were compiled with Aztec C86, Version 3.40b, Manx Software Systems. What it does: CPY makes a reference copy of any file, including system, or hidden. DIF compares a current file to the reference copy and sets an error return code that can be tested in a batch file that indicates what happened. Evaluation: Very useful for checking system files for any changes. [T.S.] - - - - FILECRC.ARC, contains: COMPARE.CHN, COMPARE.COM, COMPARE.PAS, FILECRC.COM, FILECRC.DOC and FILECRC.PAS. From: Ted H. Emigh, Department of Genetics, North Carolina State University Box 7614, Raleigh, NC 27695-7614, emigh@ncsugn.uucp, NEMIGH@TUCC.BITNET. Compiled with Turbo Pascal 3.0. What it does: FILECRC creates a list of all the files on the default drive along with creation date, file size, and a CRC (cyclic redundancy check) for each file. When FILECRC is run again the new list is compared with the old list. Evaluation: I tried it on two systems and it didn't work. They both hung and I had to reboot. [T.S] - - - SYSCHK1.ARC contains SYSCHK.EXE and SYSCHK.DOC. From: Terratech, 19817 61st Ave. S.E., Snohomish, WA 98290 What it does: Performs checksums of the first and second files in the root directory and the COMSPEC file. These are the three system files. The first time the checksums are displayed. If they are given as parameters, they are compared against the current values. Error levels are set so a batch file can test the results. Evaluation: Works well. This is shareware, with donation information only given if you request it with "SYSCHK /?". [T.S.] - - - - VACCINE.ARC, contains VACCINE.EXE, VACCINE.DOC. From: BBS (616)361-7500 What it does: A compiled BASIC program that will give the size, time and date of a supllied file name. If these are given as parameters, it will compare the current values with the parameters and print a message that they agree or disagree. It will not read files with the system attribute. Evaluation: Probably not very useful. [T.S.] - - - - VIRUSCK.ARC contains: LICENSE, README, VIRUSCK.DOC, VIRUSCK.EXE. From: Matt Cohen, PO Box 10589, State College, PA 16805-0589 Written in Turbo or Microsoft C Source code: 83 lines What it does: It runs a program and reports any changes in its size or date after it is executed. Evaluation: Not recommended. [T.S.] ==================== Class 2 programs terminate and stay resident and attempt to stop undesirable activity. ==================== C-4.COM, INSTALL.EXE From: Interpath, 4423 Cheeney St., Santa Clara, CA 95054, (408) 988 3832. What it does: This is a commercial product that costs $40. It makes itself resident, hooking vectors 9, 13, 21, 22, 26 and 2F. A message pops up if any forbidden disk activity tries to take place and gives you the option of allowing or aborting the action. It protects against any program that attemots an interrupt level write ti a disk, or any program that attempts to modify or rename an EXE or COM program or CONFIG.SYS. Evaluation: It does not warn of batch file modifications. The vendor has cooperative in modifying the program when indesirable interactions with other TSR programs were found. Useful in a situation where existing applications are being run. Probably not suitable for use where programmers are busy developing new programs. (These people seem to operate the National BBS Society, too.) [T.S.] - - - - DPROTECT.ARC contains: DPROTECT.COM, DPROTECT.DOC, READ.ME. From: Gee M. Wong for Public Domain use ONLY. What it does: It installs itself as a resident program, and monitors the use of the BIOS level interupt 13H to protect one or more disks. If it detects a write request to a protected disk, it will warn you and then reboot your PC. Evaluation: Not very practical. I need to be able to write to my hard disk. [T.S.] - - - - STOP1.ARC contains: NEWSTOP.ASM, NEWSTOP.COM, STOP.DOC. From: Carey Nash, The Programmer's Forum, (818) 701-1021 What it does: TSR that hooks interrupt 13H used for ALL low level disk I/O. If write or format is requested, it will not allow interrupt 13 to perform the command, but instead, it return a value to tell the calling program that the write, or format was successful. It also uses interrupts 9 and 1C. It can be turned on and off from the keyboard. Evaluation: When I tested it with a program that modifies sector 0, it an error message saying A: was write protected. It might be useful in particular circumstances with unknown programs, but I would not recommend it for general use. [T.S.] - - - - HDSENTRY.ARC contains: HDSENTRY.ASC, HDSENTRY.ASM, HDSENTRY.COM, and README.1ST. From: Andrew M. Fried, 895 Cynthia Drive, Titusville, Fla. 32780 (305) 268-4500 What it does: It will enable you to run any program on a floppy drive undisturbed, but prevent most programs from accessing the hard disk for any type of destructive call. Nondestructive calls such as reading or resetting the drive are permitted; formatting and writing to the disk are trapped and prevented from occuring. Interrupt 26h, the absolute disk write interrupt, is also effectively removed from the system by this program. Hooks interrupt vectors 13h and 26h. Evaluation: Useful. It prevented a program from changing sector 0 on my hard disk, although the program ran to completion and thought that it did. [T.S] - - - - BOMBSQAD.ARC contains: BOMBSQAD.COM, BOMBSQAD.DOC. (Version 1.3) From: Andy Hopkins, 526 Walnut Lane, Swarthmore, PA 19081. BBS: 302-764-7522 What it does: It hooks interrupt vectors 13 and 70, intercepts calls, displays what is going to happen, and asks if you want to continue Evaluation: It did stop calls to write to a sector on my hard drive, but it also interfered with being able to read from A: when it should have allowed that operation. [T.S.] ==================== Class 3 Combination programs. These combine a check of system files with a TSR part that watches for dangerous disk activity. ==================== FSP-12.ARC contains: $READ_ME.1ST, $TOC, FLUSHOT.DAT, FLU_POKE.COM, FLU_REG.FRM, FSP.COM, FSP.TXT, F_FEED, HARDWARE.TXT, MY_OWN.CPY, PRINT.BAT, RAMNET.TXT, REWARD.FRM, REWARD.LST, THE_COOP.TXT, UPDATES.TXT. [Flu_shot+] From: Ross M. Greenberg, 594 Third Avenue, New York, N.Y. 10016 BBS:(212)-889-6438. What it does: After performing a check sum of the three system files, it installs itself as a TSR COMMAND.COM copy, hooking interrupt vectors 8, 9, 13, 20, 21, 26, 27 and 28. It reads a data file that tells how you wish files to be protected, e.g. no read, read only, no EXE or COM or BAT files, etc. When any program attempts to do something forbidden, a pop-up window tells you and lets you abort or allow the operation. Evaluation: Although PC Magazine, June 88 recommended it, a number of people have reported serious bugs that have not yet been fixed by the author. At this time, this version is *not* recommended. ==================== Miscellaneous ==================== CHK4BOMB.EXE ("Check for Bomb"). From: Andrew M. Fried, 895 Cynthia Drive, Titusville, Fla. 32780 (305) 268-4500 What it does: It reads a .EXE of .COM program file from disk and attempts to spot dangerous code and suspicious messages. Evaluation: Useful for displaying text strings in program files, but of almost no usefulness for virus protection. [T.S.] - - - - VIRU-SIM.TXT, VIRU-SIM.EXE. From: National BBS Society/ICUG, 4423 Cheeney Street, Santa Clara, CA 95054. Voice - 408 727 4559, BBS - 408 988 4004 What it does: VIRU-SIM is a program that simulates characteristic activities that .COM and .EXE infector viruses use for replication. It also simulates some of the destructive activities used by viruses to destroy disk information. It does not simulate the infection techniques of boot infector viruses (such as the Pakistani Brain Virus). VIRU-SIM may be used as a tool to test the effectiveness of anti-viral measures and as demonstration tool for viral replication activities. VIRU-SIM is available free of charge from the BBS Society's Homebase bulletin board, or is available on diskette for a $3.00 mailing and handling fee. Evaluation: Useful for testing protection programs. [T.S.] ==================== Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: -------------------- Date: Thu, 16 Jun 88 16:29:48 +0300 Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Y. Radai" Subject: Re: a few points The message "a few points" from "me! Jefferson Ogata" mentioned both an EXEC virus for VM/370 mainframes and a virus which survives recompilation even though no trace of it remains in the source program. Several people have commented on Jeff's first point. I just wanted to remark that an excellent article describ- ing the second type of virus can be found in ABACUS, Vol. 4, No. 4 (Summer 1987), pp. 7-25. Y. Radai Hebrew Univ. of Jerusalem RADAI1@HBUNOS.BITNET -------------------- Date: Thu, 16 Jun 88 09:42:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Christmas-card EXEC Nit: the file was named "CHRISTMA EXEC", not "XMASCARD EXEC" (as Bill Murray has referred to it once or twice). Just to keep things as clear as possible... Dave Chess, IBM T. J. Watson Research Center (Affiliation given for identification purposes only) -------------------- Date: Thu, 16 Jun 88 10:24:12 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on compiler virus These comments on a compiler virus come to us from Martin Ward: From: Martin Ward Date: Thu, 16 Jun 88 10:44:59 +0100 One way to get around the C-compiler virus (which exists only in the executable and copies itself into any new version of the C compiler it compiles) is to write a "quick and dirty" C _interpreter_ in C. This can be safely compiled by the infected compiler (since presumably it can't recognise and infect an interpreter), then you use the interpreter to interpret the (clean) compiler source code compiling itself to generate a (clean) compiler executable. I have heard of a more insidious version of such a virus which lived in the C compiler executable and the login executable. The login executable allowed anyone who typed in a certain userid to log in as root without needing a password, the compiler executable recognised that it was compiling "login" an inserted the extra code - it also recognised if it was compiling a C compiler and inserted the recognition code in that! Thus no trace of the virus appeared in any source code. Totally unconfirmed rumour has it that these executables actually made it out on a release tape, the implication being that if large parts of AT&T became infected then after the next release the virus author would have a back door into any UNIX system which had the new release. Martin. My ARPANET address is: martin%EASBY.DUR.AC.UK@CUNYVM.CUNY.EDU JANET: martin@uk.ac.dur.easby BITNET: martin%dur.easby@ac.uk UUCP: ...!mcvax!ukc!easby!martin Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: -------------------- Date: Thu, 16 Jun 88 13:03:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joseph Sieczkowski Subject: Rumor >I have heard of a more insidious version of such a virus which lived in the >C compiler executable and the login executable. The login executable >allowed anyone who typed in a certain userid to log in as root without needing >a password, the compiler executable recognised that it was compiling "login" >an inserted the extra code - it also recognised if it was compiling a C >compiler and inserted the recognition code in that! Thus no trace of the >virus appeared in any source code. I believe that the rumor that you are speaking of is that of the first C compiler. Supposedly the authors (Kerningham and Ritchie) put this little chunk of code in so they could log into any unix system. If the processes were listed, someone was running login (in actuallity, they were floating around the system.) This problem was quickly fixed with the next version. joes@scarecrow.csee.lehigh.edu PS: Fred Cohen briefly mentioned in his thesis that the NSA was rumored to having something like this floating around on various systems. As to its truth, I have no idea. -------------------- Date: Thu, 16 Jun 88 13:39:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: 15 Jun 88 11:57:09 EDT From Jefferson Ogata From: Otto Stolz +49 7531 88 2645 Subject: VM/SP: Two-files-in-one from reader This is an old topic to people concerned with data integrity in VM/SP systems :-( . I always had hoped, it would not become known too widely. There exists a clean version of the MODULE internally called by RECEIVE and other commands, which won't accept partitioned files. As far as I know, it is available to node administrators only from their respective NETSERV nodes. Regards Otto Stolz -------------------- Date: Thu, 16 Jun 88 13:32:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: Re: Sent VM/CMS viruses It seems to me that it is easy enough to BROWSE or PEEK at an incoming file before RECEIVEing it. In such a situation, shouldn't the extra files also be shown if one searches far enough through the file listed in RDRLIST? Another point, the hidden second (or third - is this possible?) file would have a certain number of lines. Is this not included in the number of records listed in RDRLIST? As far as I can see, the possibility of such a thing being allowed to happen is enough to convince me that that particular part of VM/CMS is BROKEN and needs to be fixed in a hurry. You want to see some quick action? Send a malignant virus through such a method to IBM. If it infects them, then solution will be on the table within days, that is if IBM dares to admit that they had been infected. ____________________________________ Arnold Gill | If you don't complain to those who | Queen's University at Kingston | implemented the problem, you have | gill @ qucdnast.bitnet | no right to complain at all ! | ------------------------------------ -------------------- Date: Thu, 16 Jun 88 11:27:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: DAVIDLI@SIMVAX Subject: RE: Re: The Intruder Versus the Hacker William Huhg Murray writes: >MALCOLM%JVAX.CLP.AC.UK at CUNYVM.CUNY.EDU writes: >> Well, he's got a point. Once someone's got a taste of the havoc they >> can cause with their very own virus, would *you* trust them to look after >> your systems? >I might be >willing to trust three people who were mature and informed, but to trust >fifteen, at least some of whom are young, and about whom I can have at >best a limited knowledge would be at least risky. Given the destructive >potential of a virus, it is clearly unprofessional. Please define "mature and informed". Relate your definition to readers of this particular list. Then demonstrate how "youth" with this knowledge are any more risky than the "mature and informed". When you have done that, please relate the study of the creation and destruction of a computer-virus with the study of computer security issues. Finally -- justify your own "right" to read and/or post to this list, in view of the fact that the information posted here may [or may not] be useful to those seeking to circumvent computer-virus protection measures. After you have done so, I may listen to such specious argumentation as has appeared on this list ever the past week or so. -------------------- Date: Thu, 16 Jun 88 14:05:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Sent VM/CMS viruses In-Reply-To: Message of Thu, 16 Jun 88 13:32:00 EST from >You want to see some quick action? >Send a malignant virus through such a method to IBM. If it infects them, >then solution will be on the table within days, that is if IBM dares to admit >that they had been infected. You may well see a whole lot more than just action by doing that. No, that is *not* a good idea to encourage. I believe that William Murray pointed out that the bug in VM/SP has already been fixed anyway. Getting attention in the above manner is, I repeat, *NOT* a good idea. Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: -------------------- Date: Thu, 16 Jun 88 10:51:12 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: PC Anti-Viral Programs It would be easy for a virus to avoid "online" detection by many of the anti-viral software now available-- Simply have the virus check the INT 13h vector before it does any disk work. If the vector does not go directly to DOS, then abort and remain undetected. Now the virus has been stopped from propagating, (and even fooled by a legitamate TSR that has put its own hook in), but it still remains undetected. Another way around the use of interrupts would be to do its own low-level disk I/O, but this would probably restrict it to one particular brand of PC- hardware differences may prevent it. I suppose the best way would be to make a table of all the INT 13h vectors for each release of the DOS, and use that. Unless MS-DOS loads the read/write handlers into different places depending on how the machine is booted up, the virus is shooting at stationary targets. Andy -------------------- Date: Thu, 16 Jun 88 14:55:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: some more points > From: Bill Fenner > That doesn't dignify a response. Hmm...curious. Then what were you doing? > From: GILL@QUCDNAST > Subject: Re: Sent VM/CMS viruses > It seems to me that it is easy enough to BROWSE or PEEK at an > incoming file before RECEIVEing it. In such a situation, shouldn't > the extra files also be shown if one searches far enough through the > file listed in RDRLIST? Another point, the hidden second (or third - > is this possible?) file would have a certain number of lines. Is this > not included in the number of records listed in RDRLIST? The other files are not visible to BROWSE or PEEK. The number of lines will differ between PEEK and Q RDR however. Many people (I, for one) ALWAYS PEEK incoming files before RECEIVEing them. It's the handiest way I know of deciding whether the file warrants your disk space. For example, I PEEK incoming VIRUS-L mail. :-) The suggestion about infecting IBM is a very bad one I think. > From: Andrew Vaught <29284843@WSUVM1> > Subject: PC Anti-Viral Programs > It would be easy for a virus to avoid "online" detection by many of > the anti-viral software now available-- Simply have the virus check the > INT 13h vector before it does any disk work. If the vector does not go > directly to DOS, then abort and remain undetected. Why abort? The virus can just take note of the vector, install a new vector straight to DOS, and restore the old one when it's finished. Alternatively it can just make direct calls to DOS without using the interrupt vector at all. - Jeff -------------------- Date: Thu, 16 Jun 88 19:43:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Banish the List I am proposing this just as a possibility. Suppose the VIRUS-L list became a source for would-be virus-writers? There has been a lot of information on the list that may help one write a virus. If I were interested in creating viruses, would I not surely subscribe? Perhaps this is a reason for the list to be moderated/ censored. Perhaps this is cause to abolish the list. Feel free to flame if you must, my bit-bucket is industrial size. -David- *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ~ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | | or: david@wubios.wustl.edu | *----------------------------------------------------------------------* -------------------- Date: Thu, 16 Jun 88 22:11:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: reply to "Banish The List" > I am proposing this just as a possibility. Suppose the VIRUS-L >list became a source for would-be virus-writers? There has been a >lot of information on the list that may help one write a virus. >If I were interested in creating viruses, would I not surely >subscribe? Perhaps this is a reason for the list to be moderated/ >censored. Perhaps this is cause to abolish the list. Feel free >to flame if you must, my bit-bucket is industrial size. >-David- > Bitnet: C04661DC@WUVMD.BITNET > Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU > or: david@wubios.wustl.edu I don't think much good could be done by banishing the list. For one thing, if you're coming to this conclusion only now, it seems to me to be a case of closing the barn door after the cows have escaped....This is because A. From what I've seen zip through my mailbox on here in just 1 day, I could wreak some pretty heavy havoc in a number of places, were I the twisted, childish type of person that goes in for that sort of "fun", so as far as banishing the list from that standpoint, hey, the damage has already been done, we might as well keep it up to protect ourselves. B.A lot of whats been floating around recently have been discussions of old virii and their related cures, so anybody wanting to glean virus-writing hints from here is going to have to lookm a lot harder elsewhere. Besides, if they're THAT determined, they'll do it without our "help", and are probably capable of more insidious things than what they read. Granted, we do want to keep this out of the hands of 13-yr old pimple faces and others who haven't the maturity to keep from writing these little beasties, and I'm not saying we should post the source to XMAS EXEC or (c)BRAIN on the list, but it seems to me that if somebody wants to write a virus bad enough, they'll do it....I've amazed myself a number of times at the coding solutions I've come up with to various problems(NOT, **NOT** Virii) over the years, and I'm sure that there are people out there who are a hell of a lot more clever than me..not that we should throw our arms up in the air either and wait for the next sicko to come down the | (pipe :), but use the list for what I believe it ewas started for..to share and communicate information about virii and ways of stopping them... Steve - ----------------------------------------------------------------------------- Flames, comments,lawsuits,etceterizations to: Steve Okay (ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source) "UNIX is a registered footnote of Bell Labs" -------------------- *** end of Virus-L issue ***