========================================================================= Date: Fri, 22 Jul 88 07:37:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Presentation by F. Cohen On Wednesday, July 20, 1988 at the IBM Watson Research Laboratory at Hawthorne, New York, Fred Cohen gave a lecture titled "Models of Practical Defenses Against Viruses." The lecture drew well from both within the lab and from among the members of this forum. I enjoyed both the content and style of the lecture. I was disappointed, but not surprised, that he had no magic to offer. I am sure that others will want to report on what Fred said. I can only report on what I heard. He began by repeating his definition of a virus from an earlier presentation in the same forum. He also gave his general purpose virus program which contains the line "IF "trigger-pulled" THEN DO "damage." He suggested that most defenses for viruses are combinations of the following: * detect by appearance * detect by behavior * detect by change He asserts that detection by appearance is undecidable. Detection by behavior involves too many false positives and false negatives; it is disruptive. He asserts that detection of change may be costly, untimely, easy to forge, and at any rate, fails to deal with all attacks. He suggested that ultimately we deal with viruses by a combination of limiting sharing, limiting transivity, and by limiting functionality and generality. He suggests a world comprised, mostly, of application machines. In such a world we can enjoy most of the benefits of computers while limiting the inherent risk. Specifically, he recommends that we limit methods of interpretation. [Comment: Your reporter has long promoted such a strategy [ Computers & Security 2 (1983) 16-23, "Computer Security: Observations on the State of the Technology," ] To put it another way, Von Neumann was wrong; that is, programs are not like other data, should not be modifiable, and should not share storage with modifiable data objects. For example, in the IBM System/38 programs are strongly typed data objects. The type, program, cannot be changed. Modifiable data types cannot be executed. A program may be replaced in toto, but that results in a change in its fully qualified name. This tends to make surreptitious changes to the program difficult indeed. This is not an assertion that S/38 is not vulnerable to viruses, but rather an example of how restricting generality can reduce the vulnerability or increase the attackers work factor and increase his requirement for special knowledge. A counter example might be the inclusion of BASIC or REXX language interpreters in a system, not restricitng access to them, while not treating their input as executables.] Cohen proposes a strategy which he calls "Complexity Based Integrity Maintenance." He asserts that programs must check things upon which they rely, and which are subject to change. This includes their data, their own content, the operating system, micro-code, hardware and physics [in order of increasing stability]. The check function must be hard to identify, locate, and forge. The check function must verify everything, most things, relevant things, or "however well we can do." Of course, the check function computes a short, but difficult to reverse, function of the object to be checked . He demonstrated a checker called ASP (Automatic Software Protection). It checks the boot block, OS files, and dependencies. It detects and reports all changes. [My inderstanding is that it works in a manner similar to that of Vaccine by FoundationWare (not to be confused with other programs of the same name.)] Questions focused on the windows of vulnerability in the demonstration system. Of course, Cohen only promised defenses, not perfect security. There was some suggestion that "trusted" systems would improve the effectiveness of Cohen's defense, ease its implementation, and reduce its cost. Of course this assumes that "trusted" systems are easier to achieve and cheaper than Cohen's strategy; undecidable. Fred Cohen demonstrated both comprehension and wit. I am satisfied that his description of the problem and the solution is both informed and useful. We will find that whatever strategy we adopt to deal with viruses, if deal we must, will have been anticipated by his work. 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: Fri, 22 Jul 88 09:54:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: HDSENTRY Not knowing much about actual MS-DOS specifics, I can present some conjecture on the operation of the "hardware write-protect tab" you mentioned. In many operating systems, disk allocation tables and directory information are kept in RAM. After a disk write, the updated directory info is written to the disk. If some program disables all write access to a disk without informing the OS, the OS is likely to be unaware that its disk writes are failing. The practical upshot is that while a directory listing from the OS indicates some files have been changed or erased, the actual contents of the disk have not been altered. The OS's dir is based on its belief of what is on the disk. When the machine is rebooted, it will reload the directory info from the disk, which will still contain the old data. I imagine that MS-DOS keeps the hard drive directory info in RAM with periodic updates. Note that floppy dirs get checked all the time in case you switched disks while the machine wasn't looking. I still prefer the CP/M method of dealing with floppies: if you switched the disk, it's R/O until you type a ctrl-C. The niceness about this is that the OS doesn't have to look at the disk every time you ask for a directory, it just spouts off what was there the last time. - Jeff ========================================================================= Date: Fri, 22 Jul 88 13:32:39 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Password Snatchers. In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 21, 88 at 6:09 pm >>The basic idea behind our snatcher.com was to have a terminal appear >>to be unused and let the Victim "log in" there. We simulated the system >>password request mechanism and When the person typed in his/her username and >> ... >This attack belongs to the class called spoofs. It is well known and >documented. Along with eavesdropping, it is one of the reasons that >re-useable passwords should be limited to systems in which the terminal >and link are dedicated to the application and in which there is no user >programming (yes, Virginia, there really are such systems.) In other >systems serious consideration should be given to the use of one-time >passwords. (While there are other defenses against such attacks, they >all rely upon knowledgeable and diligent users. These are known to be >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 > On the other hand, there are systems that detect a loss of DTR (pin 24) and can log out a user who tries this spoof. We have used such systems for some time now. When a user tries to set up a trap like this, the new user can only be nailed if he or she does not turn off the terminal before logging in. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Fri, 22 Jul 88 08:22:18 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: VM/CMS viruses In-Reply-To: Message of Wed, 20 Jul 88 12:57:17 SET from >I fear that there is a "good" chance that (almost) all PCs get infested from >the public ones - not necessary by deliberate action. It could come from a >user who caught a virus by accident and uses the public PC to copy some >diskettes. At Miami we found that PC's serving software on LAN's were resistant to infection. Frequently LAN software offers access features like execute only. It would appear to be a bit more difficult to spread a virus accross a LAN set up to serve software with no write access. Perhaps your LAN propagation could ammelorate your other concerns. ========================================================================= Date: Sat, 23 Jul 88 07:02:26 mdt Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was From: Bill Kinnersley Subject: Amiga Viruses Does anyone out there have any experience with viruses on the Amiga? ========================================================================= Date: Sat, 23 Jul 88 12:48:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Steve Hyatt Subject: RE: Amiga Viruses Bill, I have some experience with them. Which virus are you having problems with? Steve Hyatt Bitnet Address: SGHYATT@UALR ========================================================================= Date: Mon, 25 Jul 88 17:54:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: ROM Bios What is ROM Bios? What are legitimate reasons for a program using it/them? What are illegitimate reasons for the same? Enquiring minds want to know... ========================================================================= Date: Mon, 25 Jul 88 18:14:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Back off man, I'm a scientist..." Subject: Rom Bios > What is ROM Bios? What are legitimate reasons for a program using it/them? > What are illegitimate reasons for the same? Enquiring minds want to know... Rom Bios stands for Read Only Memory Basic Input Output Services. Basically, Bios contains the routines that run all of your PC's I/O devices, inc luding the Monitor, and Disk Drives... DOS also supplies functions that do many of the same things. I suppose "Illegimate" uses are the nasty low-level programs we've been talking about... Frank ========================================================================= Date: Tue, 26 Jul 88 09:59:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: request for opinions on future... Greetings all, As the virus world seems to have quieted down (at least here in the Academic community) over the summer, I'm interested to hear what people think will happen in the Fall and subsequent semesters as far as viruses are concerned. Do you think that all the publicity has enticed some would be wrong doers into working on some super duper virus over the summer, only to be released upon their return to college? Or is this too cynical an outlook? Have we seen the end of viruses? Perhaps all of the potential virus writers have decided to change their ways? A lot of people who I've spoken with feel that a lot of virus writing efforts are taking place this summer; I hope that they're wrong. Opinions? Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Tue, 26 Jul 88 12:18:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: request for opinions on future... In-Reply-To: Believing all would-be virus writers have changed their ways is optimism indeed. I just hope that someone is writing a super virus buster this summer at the same time. Does anyone think this forum has helped/hindered the cause of anti-viral warfare, or has it done nothing? Personally, I'm a LOT smarter for having participated in this. Not that I was that smart to begin with... (8*-) ========================================================================= Date: Tue, 26 Jul 88 18:11:00 -0500 Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: converted from NETDATA format at UOFMCC From: Steve Morrison Subject: request for opinions on future... In-Reply-To: <270*b1morri@ccu.UManitoba.CA> The scenario could be a mad-hacker, plugging away at a keyboard in the back of a dimly lit office, creating a virus like no virus ever seen before. Viruses are going to be like methods of cheating at cards or on your spouse. The analogy would be having mice evolve into a bigger species to defeat mouse traps - unless the traps are built bigger, the mice will win. Thoughts from someone who was out in sun today.... Devo_Stevo aka Stephen D. Morrison B1Morri@CCU.UManitoba.CA ========================================================================= Date: Tue, 26 Jul 88 19:24:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Rom Bios In-Reply-To: >Basically, Bios contains the routines that run all of your PC's I/O devices, i n >c >luding >the Monitor, and Disk Drives... > >DOS also supplies functions that do many of the same things. > So why is there this apparently redundant duplication of services in the IBM PC world? Is this the case with other operating systems as well? This seems to make (as has been pointed out before by others) DOS a really leaky way of running a safe computing environment. Mind you, how could the deveopers know that people would conceive of viruses? ========================================================================= Date: Tue, 26 Jul 88 11:16:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: youndts@GTEWD.ARPA Subject: Virus List I'm a system programmer at a sight that supports probably 200 Macintoshes of all types. Is there a list of programs, both comercial and public domain, that are known to contain viruses. By the way, I'm new to my job and the idea of worying about viruses, so if this a dumb question, please answer it anyway. Thanks, Stephen M. Youndt -- youndts@gtewd.arpa "Hacker at Large" ========================================================================= Date: Tue, 26 Jul 88 12:39:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: youndts@GTEWD.ARPA Subject: RE: request for opinions on future... One things for sure, open discussion has made virus writers either give it up or become much more clever. Let's hope the next generation of information-immunologists are up to the task of combating the new viruses. Stephen M. Youndt "Hacker at Large" (Not the bad type of Hacker) ========================================================================= Date: Tue, 26 Jul 88 12:01:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Shawn V. Hernan" Subject: summertime virii >As the virus world seems to have quieted down (at least here in the >Academic community) over the summer, I'm interested to hear what people >think will happen in the Fall and subsequent semesters as far as viruses >are concerned. Do you think that all the publicity has enticed some >would be wrong doers into working on some super duper virus over the >summer, only to be released upon their return to college? Or is this >too cynical an outlook? Have we seen the end of viruses? Perhaps all >of the potential virus writers have decided to change their ways? A >lot of people who I've spoken with feel that a lot of virus writing >efforts are taking place this summer; I hope that they're wrong. >Opinions? >Ken __________________________________________________________________________ Speaking from the students point of view, I believe that if there are virus writers working over the summer, they are not students. Several years ago, this may have been the case. However, given the publicity that viruses have received, it has become almost taboo among college students (at least the sample I know). I believe college students in general lack sufficient motivation to spend time writing a virus. There isn't any target (like a government or rival corporation) as is the case with a small number of virii. Also, there is a limited access to computers during summer for many students. I believe if virii are being written, it is not by students, but by the more educated (less responsible?) "adult" hackers with too much time on their hands. Shawn Hernan University of Pittsburgh ========================================================================= Date: Tue, 26 Jul 88 15:34:47 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: request for opinions on future... In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 26, 88 at 12:18 (noon) > >Believing all would-be virus writers have changed their ways is optimism >indeed. I just hope that someone is writing a super virus buster this summer >at the same time. Does anyone think this forum has helped/hindered the cause >of anti-viral warfare, or has it done nothing? Personally, I'm a LOT >smarter for having participated in this. Not that I was that smart to >begin with... (8*-) > I will be submitting a memo to the faculty here at UWM telling them how to prepare for the inevitable virus attack. I would like to post it here tomorrow for suggestions and for you all to steal and use if you would. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Wed, 27 Jul 88 00:00:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: BIOSes and ROM BIOSes Originally a BIOS was merely intended to abstract the hardware from the operating system. The BIOS would supply procedures for the operating system that were independent of the hardware involved. A case in point: CP/M (again). To have a CP/M machine, you need only supply about 30 different functions in the BIOS. These are primitive I/O functions such as console input, disk seek, et alii. The CP/M operating system itself is the same program in all CP/M computers from Osbornes to Kaypros to Altairs. As for the ROM aspect, it is just one way of handling the problem of where to keep the BIOS. Many CP/M computers keep the BIOS along with the CP/M shell on a boot track on disk. The whole shebang gets sucked in by a boot program on powerup. Others just keep the shell on disk and store the BIOS in ROM onboard the computer. The disadvantage of ROMing your BIOS is that it becomes very difficult to alter it. In my CP/M days I found a number of hacks to my machine's BIOS that improved its perfor- mance. In addition, putting BIOS in ROM in a CP/M computer is of dubious utility. If there were any CP/M viruses, they would probably live in the shell, not in the BIOS, which varies from machine to machine. In the MSDOS case we have BIOSes in ROM consistently. Many if not all clones are designed to be hardware compatible with IBM PCs as far as is possible. Thus frequently the BIOSes are interchangeable. But here my knowledge of MSDOS is quite fuzzy. But if clones had BIOS on disk, they might be more susceptible to virus infection at the BIOS level. Putting the BIOS in ROM restricts infection to the operating system level. I seriously doubt IBM had this in mind when they designed it though. Maybe someone with a good knowledge of the MSDOS details can provide more specific information. Happy trails, - Jeff ========================================================================= Date: Wed, 27 Jul 88 07:51:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: BIOSes and ROM BIOSes In-Reply-To: Message of Wed, 27 Jul 88 00:00:46 EDT from Jeff Ogata had a real good explanation for the ROM BIOS being the intermediary between the operating system and the specific hardware. In the CP/M world this was extremely important because hardware varied from machine to machine, thus all standard CP/M programs used only the operating system I/O facilities so that they could be sure to work on any standard CP/M computer. The end user need only supply his/her terminal specific escape codes (clear screen, reverse video, etc.) to install the program. Then along came the IBM PC and hardware compatability. It didn't take long for the software developers to realize that both the BIOS and the actual hardware *should* be the same from machine to machine as long as it (the machine) is IBM PC compatible. By bypassing the MS-DOS (PC-DOS) I/O calls and going straight to the BIOS or even the hardware, a middleman was eliminated, and the resulting program worked a lot faster. This practice also weeded out the partially compatible machines rather quickly... An anti-virus program can trap the operating system I/O calls (INT 21H) very easily. It's also rather easy to trap the BIOS routines in the same manner. It's not too simple to trap a program from working directly with the computer's hardware (such as the hard disk controller). And, since the actual memory of the PC is alterable by any program (i.e., not protected memory), it's real tough to assure that even any traps of the operating system and BIOS remain intact. Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Wed, 27 Jul 88 09:33:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: reply to virus-l of 880727 >>As the virus world seems to have quieted down (at least here in the >>Academic community) over the summer, I'm interested to hear what people >>think will happen in the Fall and subsequent semesters as far as viruses >>are concerned. Do you think that all the publicity has enticed some >>would be wrong doers into working on some super duper virus over the >>summer, only to be released upon their return to college? Or is this >>too cynical an outlook? Have we seen the end of viruses? Perhaps all >>of the potential virus writers have decided to change their ways? A >>lot of people who I've spoken with feel that a lot of virus writing >>efforts are taking place this summer; I hope that they're wrong. >>Opinions? >>Ken __________________________________________________________________________ >Speaking from the students point of view, I believe that if there are virus >writers working over the summer, they are not students. Several years ago, >this may have been the case. However, given the publicity that viruses have >received, it has become almost taboo among college students (at least the >sample I know). I believe college students in general lack sufficient >motivation to spend time writing a virus..... > > Shawn Hernan > University of Pittsburgh Speak for yourself, but I feel that the worst has yet to come. We have several known hackers around here(banished from the system ages ago) who are probably busily hacking away at the very such things you think college students are beyond...In a sort of half-twisted way, I hope they succeed, it'll give us the one final excuse the university needs to expel(sp?) them. Plus, we are ready for them, I think. After a terrible BRAIN attack in the spring, our User Services and Support group mobilized, and everyone is quite aware of viruses and the damage they can do. Has this list been of any use??---yes, I myself know a hell of a *LOT* more about virii than I did back in May, and I know it has helped wake up a lot of people at both my jobs. Thanks to all of you who have helped us separate the hype from the truth, and what needs to/can be done about it all. ------------------------------------------------------------------------------- Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source "Disclaimers???---We don' need no STEENKING disclaimers!!" ========================================================================= Date: Wed, 27 Jul 88 09:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: JJ_KRAME@FANDM Subject: Macvirus mailer I am preparing a disk/document mailing to all the departments at my school. The topic on hand is viruses, specifically those connected with the macintosh. There seems to be a lot of dis information pertaining to viruses around the school, and I suppose someone should set the record straight (or at least into a well-fitted curve). The reason I am sending a letter to this mailer is to get feedback on what I should include. I am including Apple's own virusRx, Thurman's 'Interferon', virus detective DA, and Vaccine. I need information to draw from for the document I will be sending along. Any help would be appreciated. Joe Kramer Consultant-- Franklin and Marshall College Bitnet: JJ_kramer@Fandm ========================================================================= Date: Wed, 27 Jul 88 10:12:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Rom Bios In-Reply-To: Message received on Tue, 26 Jul 88 23:44:43 EDT ========================================================================= >> Basically, Bios contains the routines that run all of your PC's I/O devices, >>inclding th Monitor, and Disk Drives... >> >>DOS also supplies functions that do many of the same things. > >So why is there this apparently redundant duplication of services in >the IBM PC world? Is this the case with other operating systems as well? >This seems to make (as has been pointed out before by others) DOS a really >leaky way of running a safe computing environment. Mind you, how could >the deveopers know that people would conceive of viruses? It isn't really a case of "duplication of services". One isn't supposed to call the ROM Bios, instead you are supposed to call DOS which then calls the ROM Bios. This serves to hide the implementation from the programer. The advantage of this scheme is that radically different devices can be accessed with the same logical DOS calls. The disadvantage is that it is slow... ========================================================================= Date: Wed, 27 Jul 88 09:57:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Virus List In-Reply-To: Message of Tue, 26 Jul 88 11:16:00 PDT from >I'm a system programmer at a sight that supports probably 200 Macintoshes >of all types. Is there a list of programs, both comercial and public domain, >that are known to contain viruses. Such a list would not help. Once you get one, you can pretty much bet that everything else you've got has been hit, especially with the Scores virus. >By the way, I'm new to my job and the idea of worying about viruses, so >if this a dumb question, please answer it anyway. No, it's not at all a dumb question. Mac viruses in general don't seem to have been spread by Trojan programs, but by normally innocuous programs which have become infected. The infamous infection of Aldus was supposedly due to an infected copy of the program "Mr. Potato Head." There have been stories of late that infected copies of StuffIt have been uploaded (whether maliciously or not, I can't say) to private bulletin boards. PLEASE note that neither of these programs is a virus spreader! They are simply victims of this plague. I don't really know of any programs that are specifically virus "vectors". YTou really have to be careful of everything you get from anywhere other than the original author or an authorized distributor. In fact, it's not a bad idea to run one of the anti-virals on those either. If you need more information on Mac viruses and disinfection programs, order the VIRUSREM PACKAGE from our LISTSERV here at SCFVM. I'll be putting up a documentation stack sometime soon (the next day or two, I hope). --- Joe M. ========================================================================= Date: Wed, 27 Jul 88 11:31:56 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: Macvirus mailer In-Reply-To: Message of Wed, 27 Jul 88 09:42:00 EDT from I have used Apple's Rx and recommend it. It not only looks for common virus signatures in disk files, it will write what appears to be checksum file for comparison at a later date. Rx does not prevent infection, it looks for evidence of infection. Vaccine appears to be reasonably efffective, but only if it is turned on through the control panel. Remember, changes to the Vaccine control check boxes only take effect upon reboot! I don't use virusDective, but it appears to work from the trivial testing I did. ========================================================================= Date: Wed, 27 Jul 88 11:55:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David E. Spiro" Subject: Trapping Direct Disk Write Calls >An anti-virus program can trap the operating system I/O calls (INT 21H) >very easily. It's also rather easy to trap the BIOS routines in the same >manner. It's not too simple to trap a program from working directly with >the computer's hardware (such as the hard disk controller). And, since >the actual memory of the PC is alterable by any program (i.e., not >protected memory), it's real tough to assure that even any traps of the >operating system and BIOS remain intact. > >Kenneth R. van Wyk >Lehigh University Computing Center I remember reading in one of Peter Norton's books that he supports programming that makes DOS (rather than BIOS) calls because then the program should be more compatible with TSRs, window environments, etc. Are there a lot of programs that ask for disk writes directly (i.e. not through DOS)? If not, would it be possible to write a TSR that differentiates between disk write calls from DOS (making them legal) and those that are direct (flagging them as suspicious)? I'm not a programmer, so forgive me if this is gibberish. David Spiro Center for Interntional Affairs, Harvard University Center for International and Comparative Studies, Brandeis University DISCLAIMER: Blame it on my wife. ========================================================================= Date: Wed, 27 Jul 88 13:30:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Wed, 27 Jul 88 11:55:00 EDT from >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. True, from a standpoint of compatability, using DOS calls is much better than bypassing DOS via the BIOS or the hardware. It's also probably a better programming practice (*OPINION*). The only disadvantage is that the DOS calls are horrendously (sp?) slow when compared to the BIOS or hardware calls. For example, writing characters directly to video memory instead of using DOS INT 21 to draw them is at least an order of magnitude faster (!), but won't work on all machines/display adaptors. The end-user will probably prefer the faster program (assuming that it runs on his/her hardware) and it will probably sell better... >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? Not too many bypass DOS on disk activity, but *most* bypass it for screen I/O. Many (all?) TSRs that do disk I/O bypass the DOS interrupts because, being a single tasking operating system, DOS is non-reentrant. This means that no two pieces of code can (or at least *should) use the same interrupt at the same time; so, if program X is doing an INT 21 when a TSR does an INT 21, program X and/or the TSR will die a horrible death. This doesn't hold true for all DOS functions in INT 21, but at least for many of them. >If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? DOS itself must be able to do direct BIOS and/or hardware calls. Like I said, it is possible to trap the DOS I/O calls, so a TSR can look out for them, and examine them to see if they're trying to do something nasty (e.g., write to an executable file). As far as I know, the closest interrupt to the hardware disk I/O level is INT 13H; it, too, can be trapped (it is in the BIOS). Since it is in the BIOS, however, it must be at an absolute memory location (in order for the machine to be truly PC compatible), so any virus should know exactly where to find it in such a way that cannot be trapped by merely stopping disk interrupts. Perhaps there is a way to trap actual hardware level calls that I'm not aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by another program, it's the easiest thing in the world (well almost...) to reset the interrupt pointer to point straight to the BIOS in ROM, perform the interrupt without fear of being watched, and restore the interrupt when done (so as not to leave any traces) and continue. Assuming that the interrupts remain unaltered, it is possible to examine the interrupts return address to see whether it came from DOS or from a user program/virus. This assumes, also, that new versions of DOS use the same locations in memory... Sigh... Hope this answers your questions... Any other comments out there? Ken > >I'm not a programmer, so forgive me if this is gibberish. > >David Spiro >Center for Interntional Affairs, Harvard University >Center for International and Comparative Studies, Brandeis University > >DISCLAIMER: Blame it on my wife. Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Wed, 27 Jul 88 13:25:43 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Macvirus mailer In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 27, 88 at 9:42 am > > I am preparing a disk/document mailing to all the departments >at my school. The topic on hand is viruses, specifically those >connected with the macintosh. There seems to be a lot of dis >information pertaining to viruses around the school, and I suppose >someone should set the record straight (or at least into a well-fitted >curve). The reason I am sending a letter to this mailer is to get feedback >on what I should include. I am including Apple's own virusRx, Thurman's >'Interferon', virus detective DA, and Vaccine. I need information to draw >from for the document I will be sending along. Any help would be >appreciated. Joe Kramer > >Consultant-- Franklin and Marshall College >Bitnet: JJ_kramer@Fandm > If and when you get it done, please publish it here. I am sure that lots of folks would be glad to steal/use with attribution the work you have done. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Wed, 27 Jul 88 15:01:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Guarding against illegal DOS calls. ========================================================================= >>An anti-virus program can trap the operating system I/O calls (INT 21H) >>very easily. It's also rather easy to trap the BIOS routines in the same >>manner. It's not too simple to trap a program from working directly with >>the computer's hardware (such as the hard disk controller). And, since >>the actual memory of the PC is alterable by any program (i.e., not >>protected memory), it's real tough to assure that even any traps of the >>operating system and BIOS remain intact. > >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? When DOS is active, it sets a flag (in_dos). A simple TSR could trap all ROM Bios calls and check the DOS flag. If the flag is set it could allow the interupt and if the flag is not set it could return(error). Of course it is easy to circumvent a scheme like this with a smart virus. Erik Sherk Workstation support staff - University of Maryland ========================================================================= Date: Wed, 27 Jul 88 16:15:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message of Wed, 27 Jul 88 15:01:42 EDT from >When DOS is active, it sets a flag (in_dos). A simple TSR could trap all >ROM Bios calls and check the DOS flag. If the flag is set it could allow >the interupt and if the flag is not set it could return(error). Of >course it is easy to circumvent a scheme like this with a smart virus. Ok, then how about having the virus attach itself (i.e., rewrite) the COPY command? Simple, COPY is *allowed* to alter and move files, so just "instruct" it to append a virus. Obviously, this flag, in-dos, would be TRUE if COPY is doing the work... Oh, and COPY need only be altered in memory, not on disk (in COMMAND.COM). Just have, say, some game alter it a bit. >Erik Sherk >Workstation support staff - University of Maryland Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Wed, 27 Jul 88 13:55:29 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Campus virus letter To the group: I plan to submit this for inclusion in an all campus newsletter this fall. The audience will be faculty and staff who are reasonable, but do not understand computers or computering. Any suggestions or advice would be appreciated. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Potential virus Attacks at UWM UWM has a high probability of having its office PC's (so called IBM compatible machines) struck with a computer virus attack sometime soon, probably before June 1989. If and when it occurs, it is possible that nearly every office IBM compatible machine will fail or lose files on the same day. It will be a very unpleasant time and our professional staff will be overwhelmed by requests for help and will take some time (weeks) to get the recovery process under way. Most of us are unaware of how dependent we have become on these desktop machines and how much we will be affected by the loss of data that will ensue. Not only will the office machines be affected, but the home machines that many faculty now have will also have their files affected by the very same virus, and at the same time. If you are preparing a paper for publication, an exam, or some correspondence, you may well find that your machine readable copies of that material will become unusable both at home and at the office. This will be a very unpleasant experience. This paper discusses some evasive action that you can do now to prepare for the return of your machine to working order. What I am recommending in this paper is no more than good housekeeping and is practice that each of us should do anyhow, with or without the threat of some mysterious computer virus. What I will discuss for the next few paragraphs applies to users who have machines with either a floppy disk drive and a hard disk drive or have two floppy disk drives on their computers. Step one: Locate the original source disks for the operating system you are now using on your computer. This may no longer be the system delivered with your machine, you may well have had an upgrade. DO NOT PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen write-lock tabs and put one on each of the delivery system disks. (When you hold a disk upright the right side of the disk has a 1/4" square notch cut into the black paper jacket. The write-lock tabs are black or aluminum colored gummed paper tags about 3/4" X 1/2" that can be stuck over the edge of the disk covering the front and back of this notch. When that tab is in place it is not possible for the computer to write information onto a floppy disk.) Only after you have write-locked these disks should you put the disk into the computer and compare the system on that disk with the system you are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing the DIR command on an unlocked disk is enough to infect that disk with a virus if your system is already infected and if the disk is not write- locked. I am not kidding. There is a very small probability that your system is already infected. I recommend that you compare the date and size of the file COMMAND.COM on your original source disks and on your working disk or disks to see that they are the same. For my system the results look like this: C> dir a:\command.com Volume in drive A is MS330PP01 Directory of A:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 5120 bytes free C> dir c:\command.com Volume in drive C has no label Directory of C:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 7391232 bytes free Note that both copies of COMMAND.COM have the same date and time of creation (midnight on July 24th 1987) and both are the same size (25,276 bytes). The numbers for your machine may well differ from mine, but both should be the same. When those disks have been found, put them away in a safe place. I recommend that they be put in a plastic storage box not too near your computer. Step two: There are a small number of software packages that you would be lost without. In my case they include WordStar, dBase III, PKARC, Kermit, and Directory Scanner. These packages may well be purchased commercial software (WordStar, dBase III), shareware (PKARC, Directory Scanner), and freeware (Kermit). In each case you should have an original source delivery disk for each of these packages. Find those disks, WRITE LOCK THEM, compare them with the copies you are now using, and put them in a save place. I recommend that they be put with the system disks discussed above. (It is probably true that the creation dates for the running copies of this sort of software will disagree with the creation dates for the delivery disks. Installation of many of these packages entails writing to the program. That is not a problem.) Step three: Using the backup procedure of your choice, perform a backup of the system files on your computer. If I was using a dual floppy based system, I would simply make copies of my working WordStar, dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a computer with a floppy and a hard disk, I would use backup-restore, or Fastback or some other package to back up the directories C:\WS, C:\DB3, C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different names on your system.) Write lock these backup disks. Label them with today's date. Using your backup system compare the disks you have just backed up with the disks you are using to ensure that the backup "took". Put the backup disks in a safe place. This will tie up half a dozen disks, but with disks now costing $0.35 each, you will probably find the $2 investment worth while. Step four: (This applies to those users who hard disk based computers.) Prepare a backup procedure that will permit incremental backups. This will entail backing up the entire system once, and then periodically backing up those files that have changed since the last backup. Perform such incremental backups regularly. After several such incremental backups, the size of the backup set will become quite large. At that time, put the backup set away in a safe place and begin with another set of disks for a full system backup followed by several increments. When the second set is full, put them away and return to the first set. This will afford a very secure set of backup files. I find that 50 disks makes a good backup set. Thus 100 disks would be used for the double backup group. I suspect that most users would need to do a full backup about 4 to 8 times per year, requiring about 1/2 hour of manipulation and should do incremental backups about twice per week, requiring less than 5 minutes. (It is a very good idea to periodically test the backup system with a verification of what you have backed up. Most file backup systems have a Verify command to do this sort of test.) Step five: Go back to your useful work. Recovery from the lost of one or a few files: Sooner or later you will lose some files. They will dissapear without apparent cause and you will blame the problem on a virus. It is my experience that no virus is involved, the loss of files will be due to an operator error. If you have been doing incremental backups, then the simplest corrective action is to use the recover feature of the backup system that you are using and simply restore the latest copy of the lost file(s) to the hard disk. If you have been consciencious then the loss of work will entail just a few minutes or hours of rework. Recovery from the loss of the entire system: It may happen that the entire hard disk seems to be lost. This is serious and is most likely not the result of a virus. Most failures of the hard disk are due to hardware problems. The best solution is to repair the hardware if the technical people judge that that is the problem, and then, after reformatting the hard disk, restore the system from your latest backup. Almost without fail, this will result in a complete return to a normal system. Really bad news, the restore does not work: This may well be the point of this memo. If a virus has been planted in your system and has been set to trigger on some event, then the only way to recover is to rebuild the system from scratch using the write locked set of disks that I advised you to prepare above. If these disks are not write locked, and if you mount them onto an infected system, then the disks will be infected in turn and you may well be unable to restore from a clean, uninfected source. On the assumption that you can build your system again from scratch, you may restore all of the data files from your backup set. (A data file is one that does not have the extension .com, .exe, or .sys.) Any other file should not be able to carry a virus either between systems or over the backup process. Some facts: There is no reason ever to boot the system from a foreign disk. There is no reason why a disk used to transport data between manchines should have a copy of the files io.sys, msdos.sys, ibmio.sys, ibmdos.sys or command.com on it. No system to date has been infected by the transport to it of data files. Only executable files can be used as trojan horses. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Thanks. L. P. L. 7/27/88 ========================================================================= Date: Wed, 27 Jul 88 19:54:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Adsett Subject: RE: Re: Trapping Direct Disk Write Calls >Perhaps there is a way to trap actual hardware level calls that I'm not >aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by >another program, it's the easiest thing in the world (well almost...) to >reset the interrupt pointer to point straight to the BIOS in ROM, perform >the interrupt without fear of being watched, and restore the interrupt when >done (so as not to leave any traces) and continue. Actually it's easier than that. All the program has to do is set up the stack properly and do a direct jump. Of course this assumes that the location of the interupt in the bios and so will not work with all bios's. I don't know of any way to trap this. Robert Adsett Dept. of Phys. Univ. of Waterloo Waterloo Ont. Canada " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III ========================================================================= Date: Wed, 27 Jul 88 20:33:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message received on Wed, 27 Jul 88 17:56:39 EDT ========================================================================= !When DOS is active, it sets a flag (in_dos). A simple TSR could trap all !ROM Bios calls and check the DOS flag. If the flag is set it could allow !the interupt and if the flag is not set it could return(error). Of !course it is easy to circumvent a scheme like this with a smart virus. >Ok, then how about having the virus attach itself (i.e., rewrite) the >COPY command? Simple, COPY is *allowed* to alter and move files, so >just "instruct" it to append a virus. Obviously, this flag, in-dos, >would be TRUE if COPY is doing the work... Oh, and COPY need only be >altered in memory, not on disk (in COMMAND.COM). Just have, say, some >game alter it a bit. >Ken >Kenneth R. van Wyk From the Devil's Dictionary: A virus that is smart enough to hack the resident portion of command.com would probably know about IN_DOS. The TSR scheme I proposed offers a low-level of protection, no much above write protecting your disks. The advantages of it are that it can be kept active all the time with little performance degradation. Erik Sherk ========================================================================= Date: Thu, 28 Jul 88 12:22:55 GMT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Turgut Kalfaoglu Subject: Re: ROM Bios In-Reply-To: Message of Mon, 25 Jul 88 17:54:59 EDT from >What is ROM Bios? What are legitimate reasons for a program using it/them? >What are illegitimate reasons for the same? Enquiring minds want to know... ROM bios is basically a whole slew of routines that are coded into a chip. They provide all kinds of functions from keyboard, to screen, to disk. BIOS calls, like the ones for the screen, tend to be faster than their counterparts in DOS calls, but your program will only run with a system that has ROM bios. ROM BIOS is also usually the cause for 'incompatible compatible computers.' - since IBM's BIOS chip is (C)opyrighted, and cannot be used by other companies freely. Many companies have developped their own chips to provide similar functions. I hear that the Phoenix BIOS is the most compatible, and that the Award BIOS is another popular one.. Legitimate/Illegitimate: I dunno.. You can use BIOS to write directly to a sector on disk, so a virus could use it to destroy something, or to write itself onto a fresh disk.. Maybe that's what you mean by leg/illeg... -turgut ========================================================================= Date: Thu, 28 Jul 88 15:20:35 GMT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Turgut Kalfaoglu (51)18-10-80 Ext:244" Here in Izmir, Turkey, we have a BRAIN version 9.0 on our PC lab. We are trying to get more info on it, and trying to analize its behavior. So far, it doesn't seem to like hard drives - we have not been able to locate one on a hard drive. It jumps from diskette to diskette easily, by simply writing itself to the boot track of the new diskette. We found that the best way to find this virus is to look at the FIRST track of the diskette. It has a message there. We use Norton or PCTOOLS to peek at that sector. We are also working on a program that verifies that track, and the checksums/crc's of the three system files.. I think the computer centers/BBS's, and other similar services should record the sources of the obtained software.. This would intimidate the creep (the virus-writer) on distributing the virus-installing software.. -turgut ========================================================================= Date: Thu, 28 Jul 88 09:34:47 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "James N.Bradley" Subject: Re: Campus virus letter In-Reply-To: Your message of Wed, 27 Jul 88 13:55:29 CDT Leonard - I edit the computing center publications at the University of Houston and we couldn't publish your article as it stands. The use of words like "high probability", virus "attack", and "evasive action" is inflammatory. These words are not going to provoke reasonable reactions from people. You have to be very careful when using powerful and sweeping statements. A better way of beginning your paper would be something like: Some campuses have had problems recently with virus program. A virus program is (etc). There are a number of things you can do to prevent infection...etc If you become infected there are a few things you can do...etc Tone down the dire images unless you know you have a virus on campus. James N. Bradley Information Services Manager University of Houston ========================================================================= Date: Thu, 28 Jul 88 09:48:11 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GARY SAMEK Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Wed, 27 Jul 88 13:30:26 EDT from Hello Net, When a virus gets into command.com, it is very difficult to stop it from spreading if it is well written. It seems that the best way to prevent this type of virus is to keep an eye on the dates on these files. Then, you would probably want a TSR to notify you whenever a DOS/BIOS call to change the date of a file has been requested. This would require a little more attention of the user, but the protection scheme is simpler and fairly reliable. Upon thinking, it would probably be a good idea to keep the output of the DIR command as a disk file, so you could check from time to time, the sizes of the files as they were and as they are now. Anyway, I would like to see a little discussion on a good generic technique on preventing the infection and spread of virus, such as I have given here. Gary Disclaimer - These opinions are my own, and whoever else agrees. ========================================================================= Date: Thu, 28 Jul 88 11:23:01 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 Re: Ken's request for opinions about future virus activity / and "warning lists" about Trojan Horses and viruses "All the data is not yet in" for the question of future virus activity, but here is my opinion from this vantage point.... Several trends are developing, making the situation a "good news and bad news" one. The good news is that it looks like virus attacks on consumer/hobbyist/small instituation computers is leveling off and will most likely drop, with occaisionally outbreaks. One factor for this is that the "fad" is wearing off for those who write viruses for the "thrill". The other, more significant, reason is that many computerists are becoming much more computer security conscious than ever before. he number of files being transfered an many BBS's that I am on has dropped greatly in the past six months. People are getting more careful, slowing the spread of malicious codes.Many have started using some form of general protective/testing software. (No, they are no absolute garauntees, but it is step up from indiscrimate software exchange.) The degree of complexity and sophistication to make a "successfull" (from the perpetrator's viewpoint) virus is being driven upwards. The bad news is the possibilty of specifically targetted virus will increase as various people are seeing the potentials and dangers of this electronic parallel to nanotechnology. This is a concern that the institutions that would be possible targets are already building more secure systems. There is possibility of "spillovers" to the general computing community from any attempted attackes. (In the case of targetted attacks, the result does not need to destroyed files, wrecked boot sectors, and other obvious damage. A subtle data manipultor could do much damage. But enough said for here.) So many institutional computer centers are wise in constantly looking to secure their systems. A related factor in these trends is the matter of accountability and other human factors. Few months ago, Vin McLennen had posted a report in RISKS DIGEST about the various problems with employee accountability in the computer and data management field. This seems to intensified after the US Stock Market plunge last fall; the message given to employees by many companies after thatwas "Produce bottom- line profits or you're out!" (I have seen this message in some of the advertising in computer & telecommunications publications- the appeal to fear.) Even before the virusese, one of the biggest security problems for a company has been disgruntled employees. On a different subject..... Somebody posted a request on this list for information about any "warning lists" of Trojan Horses and viruses. The only one that I know of is the DIRTY DOZEN listing compiled by Eric Newhouse. It is available through LISTSERV@LEHIIBM1 as DIRTY DOZEN. Use the GET command to get it. The latest version is 8b. Eric says that he will coming out will version 9 soon. He will be splitting it up into separate listings for Trojan Horses, Viruses, Pirated and Hacked Programs, etc. The DIRTY DOZEN listings can be obtained also from Eric's BBS - THE CREST BBS in Los Angeles, CA - (213) 471-2518. There is also a message section on the CREST BBS for messages about any newly discovered "bogusware".If neither routes are practical, contact me and I can arrange for a copy (disk or printout) to be sent to interested people by arrangement. J. D. Abolins 301 N. Harrison Str., #197 /Princeton, NJ 08540 (mail only) ========================================================================= Date: Thu, 28 Jul 88 11:24:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Thu, 28 Jul 88 09:48:11 CDT from >It seems that the best way to prevent >this type of virus is to keep an eye on the dates on these files. Not at all true; it's all too simple to alter a file without altering the date. *DO NOT* trust the write date as a virus detection scheme. >This would require a little >more attention of the user, but the protection scheme is simpler and fairly >reliable. It would be simpler alright, but also much simpler to get around. > Upon thinking, it would probably be a good idea to keep the output of the >DIR command as a disk file, so you could check from time to time, the sizes >of the files as they were and as they are now. It's also easy to alter a file without changing the file size as well. Particularly in the case of COMMAND.COM, the code need not even be altered on disk at all - it need only be altered within memory, and that can be done by any program at all since a PC's memory is totally unprotected. Once again, a file can contain a virus without any file size or write date change from the original (uninfected) file. >Gary Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Thu, 28 Jul 88 17:05:54 GMT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Turgut Kalfaoglu Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Wed, 27 Jul 88 11:55:00 EDT from >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? Yes, there are many programs that write to screen. Most programs that 'pop' into view are either writing directly to screen, or using a technique called 'page flipping' - which is similar to turning the pages of a book. (Prepare the next page, then flip the pages) For an example of the difference in performance, try invoking the Norton Utilities with the /D1 option or the /D2 option. (Which I believe are BIOS and DOS calls with ANSI, respectively) Trapping such calls would be difficult - you would have to check for every memory access (there are LOTS of them), to see if they fall within a device's area. For example, to write to screen, you simply send a byte to a location in memory, and the character appears.. -turgut ========================================================================= Date: Thu, 28 Jul 88 11:58:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University A few brief comments on recent activity on this list: Turgut: There are quite a few Brain variations foloating around at this particular moment. We have counted 7. The original Brain Virus ONLY effected floppy 5 1/4 inch disks. And it did no harm. Versions are around that effect hard disks and 3 1/2 inch disks, but they are simply edits of the original. Also damaging versions exixst. One will periodically delete files, the c second will erase your FAST table. (please excuse my typeing, I have no backspace). That should read FAT table. I have now worked on two versions of the Brain virus and am looking for the others. Also, I am curious to nknow who was the first college to dicscover the Brain. I really don't know who isn the US was hit first. Gary: Watching the Dates change means mnothing. It is a very simple function to keep the date from changing. The date change was one of the major reasons we caught the Lehigh Virus in the first place. If it hadn't changed, Chris, Joe and I and Mitch probably wouldn't have realized what was going on for a qhile after that. Whoever wrote the Lehigh Virus made a mistake, and I think any new viruses that crop up will not make that same mistake. JD: I have been trying to compiler a list of viruses. This is very difficult. I have sent mail out to just about everyone and no one is keeping one. We have ome across about 70 viruses now including 4 versions of the Israeli and 7 versions of the Brain. If anyone wants to make a short list of the ones they know3 of, please send it to LKK0@LEHIIBM1 and I will include them in my compilerd list. I will post it when I feel it is sufficeintly done. Virus Growth: I expect a virus explosion of GOOD virues on campuses next year. A bank in upper New Jersey (who I am not allowed to mention othe name otf) called me about 3 weeks ago. They were hit pretty basdly by a virus. I honesty see viruses increasing in hostility and in design. The problem is that theyre is so much publicity about viruses right now that we can't handle the problems cropping up. Another problem I will hate to see, but it looks like it is coming is a virus that runs on PC's and attacheds itself to mainframes when the PC conects to them. It will themn "worm" its way through the mainframes. We've been doing research on this type of virus for a while, and a small one was located in Harrisburg I'm told. I cannot describe it I'm osorry to say. Evey time we do something, we're told to keep quite and not fuel the scare. About not being able to trap diredct disk writes without trapping DOS calls. OUr package ,... first let me say that I am NOT trying to sell it over Bitnet, I just want to point out that our package from Lehigh Valley Innovative Technologies, does just that. And it does it well. We do trap disk calls and check to see whether they came from DOS or directly from the program. And believe me, it works, and it would be very hard for someone to mess with it, unless they want ot disassemble all our code and try to figure out how everything works. One other thing: James Bradley, your english is much mbetter than mine, but I'm afraid there is a VERY high probablyility of ANY college with PC sites to be hit by a virus. Protect yourselves NOW! Loren Keim Lehigh University Provost Staff ========================================================================= Date: Thu, 28 Jul 88 09:30:31 pdt Reply-To: Virus Discussion List Sender: Virus Discussion List From: isbalkits@UCDAVIS Devo_Stevo writes: "The scenario could be a mad-hacker, plugging away at a keyboard in the back of a dimly lit office, creating a virus like no virus ever seen before. Viruses are going to be like methods of cheating at cards or on your spouse. The analogy would be having mice evolve into a bigger species to defeat mouse traps - unless the traps are built bigger, the mice will win." Depicting the virus writer as a gothic/romantic figure (like pirates have been, like gangsters have been, like gang members now are) contributes to the problem. If this discussion is to have any value, any impact, it should be to paint the virus writer as he/she truly is: an emotionally-atrophied individual, a product of negative operant conditioning, a human who has lost contact, isolated in a hyperspace of computer an-architecture, where techical wizardry seems to excuse a lack of common ethics or even common sense. Continuing to fictionalize the virus writer as a mad scientist, a Doctor Frankenstein whose genius gives us a secret thrill, whose lawlessness challenges us, is just the wrong way to go. If this forum really exists as a deterrent to the spread of viruses, one of its functions is the demystification of the criminal hacker. Calling her/him a "creep" is not enough. The consciousness in each of us should be raised that we are contributing to the virus writer's self-image as someone "special" whenever we present the problem in adventurous scenerios such as that above. Ivars Balkits Computing Services University of California - Davis ISBALKITS@UCDAVIS ========================================================================= Date: Thu, 28 Jul 88 12:42:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: How many viruses are there? Loren K Keim writes > There are quite a few Brain variations foloating around > at this particular moment. We have counted 7. ... > I have now worked on two versions of the Brain virus and > am looking for the others. Does that mean that you've counted 7 rumors, but only really seen two different versions, or that you have good, solid evidence of seven versions, but for some reason only have copies of two? I've seen two versions of the Brain virus (both attack only floppies, and in fact the only difference between them is in the no-op data areas), and heard rumors of lots of others. In every case, though, the rumors seem to have been due to mistakes or confusions, and I wouldn't be at all surprised if there are in fact only two versions out in the world. If you have hard (first-hand) evidence of others, I think we'd all be interested. I have good evidence for only 6 (or 7) viruses for PC-DOS in actual circulation: the Lehigh, the Jerusalem, two "April Fools" viruses which have already passed their setoff dates, the Brain (and its minor variant), and a small COM-file virus that occasionally replaces its victim with a program to reboot the machine (rather than simply infecting it). Anyone who knows first-hand (or from a solid non-rumor source) of more viruses would be doing everyone a great service by posting a detailed description of their symptoms, so we can all tell our users about things to watch out for. (Loren, if any of the seven that I mentioned above are new to you, let me know and I can send you more details; I'd love to see that list of 40, especially if it includes some hint of how sure we really are that each one exists!) All this is not to say that viruses aren't something to worry about! Quite the contrary. But I do tend to think that new rumors tend to appear MUCH faster than new viruses do... DC ========================================================================= Date: Thu, 28 Jul 88 13:58:05 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Dave: About rumors versus real versions, I have heard rumors about so many versions of the Brain that it isn't funny. Fred Cohen described the Brain found in Mimi as a varient strain and whent on to explain it. It sould... sounded exactly like the original to me. I have heard of 7 versions from reliable sources. Unfortunately most people won't allow me to have copies of their viruses. The two I have are from California and Boston. People are so afraid of virusses that I am ahaving difficult getting ahold of some strains. I have to get permission sent from the government to these poeple fro them to release copies to me, that is why I only have 2. Its kind of interesting that I travel places to help stop viruses but I can't get ahold of some copies because people don't ... no one trust s anyone else. I have either copies or f or heard from reliable sources of 4 Aporil Fool's fviruses, 7 versions of the Brain, the Lehigh, 4 versions of the Israeli (there are early versions floating around Hebrew U I'm told, bpresumably written by the culprit who wrote the Istraeli), the Playboy, the Brain.. Gerbil I' mean, and some minor ones (I' do not have a list in front of me, this is from memory). For the Mac, I've seen aa version of the CHRISTA virus (yes, simple damn thing copies itself around your little Mac, its not written in Rex of course), the Phantom, the NASA virus, the Aldus virus, and the VULT virus. The Flushot renegade for the PC was something i should also point out. The CHRISTMA for the CMS machines, a Smiley face virus which was the Chrisma redone . 4 unnamed Unix viruses and I have rumors of more floating around. (one of them is onely a few characters long and is very ansty). That is the start of a list.. oh, yeah, another off the top of may head is a Mac virus which prints a picture of a nude female on the screen while it copies itself to any other disks in your system. And obvious virus but still a virus. I have heard rumors of a similar virus for the PC. Loren Keim Lehigh University ========================================================================= Date: Thu, 28 Jul 88 14:14:37 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Questions about Brain Actualy, I've been trying to tarack the Brain Virus for some time. If anyone out there has had any contact with the Brain virus, I would really appreciate some info from you (dates, what it did, what it looks like, how it worked, when it hit, how many people it effected and so on). Also, does anyone know if any research has been done on Worm Theory since the big Xerox worm back in 82? Does anyone have a copy of the Apple version of Core Wars? Does anyone know where Len Adleman is now? (He's the person who first called a computer virus an coputer virus. (if my typing were better) Is it true that University of Penn found a Command Com virus? I'd like to know who all was hit the worst by the Christas Tree Exec. How far did the Aldus virus get? Can anyone tell me about the NASA virus other than what was in the papers? (NASA claims they didn't have a virus!) Is nanyone planning on teachine a virus course in the future? Which colleges teach computer security. Loren ========================================================================= Date: Thu, 28 Jul 88 14:32:10 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: How many viruses are there? The only "Playboy" thing that I've heard of reliably was just a Trojan Horse for the Mac, not a virus for the IBM-PC or compatibles. Similar comment applies to the corrupted flushot thing, I think; it just did nasty things to you when you ran it, but it didn't spread itself to other executables. A list of Trojan Horses would be miles long, but not really relevant to the subject matter of VIRUS-L. I suspect a list of real viruses would be much much shorter. DC ========================================================================= Date: Thu, 28 Jul 88 14:41:49 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon In-Reply-To: Message of Thu, 28 Jul 88 09:30:31 pdt from >Continuing to fictionalize the virus writer as a mad scientist, a >Doctor Frankenstein whose genius gives us a secret thrill, whose >lawlessness challenges us, is just the wrong way to go... I agree. I find virus writers just about as romantic as a sniper on the freeway. "Oh look, I just killed somebody else." Too bad brainwashing is illegal (don't flame - I'm being VERY sarcastic). --- Joe. ========================================================================= Date: Thu, 28 Jul 88 13:59:24 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message from "Kenneth R. van Wyk" of Jul 28, 88 at 11:24 am >It's also easy to alter a file without changing the file size as well. >Particularly in the case of COMMAND.COM, the code need not even be >altered on disk at all - it need only be altered within memory, and >that can be done by any program at all since a PC's memory is totally >unprotected. Once again, a file can contain a virus without any file >size or write date change from the original (uninfected) file. Very interesting about command.com. That file, as released in msdos level 3.3 contains a 4000 byte block of zeros at its end, which makes it VERY easy to add code. I cannot fathom why they put that area into the process. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Thu, 28 Jul 88 14:33:14 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Neil Goldman Virus prevention programs (those which claim to stop infection *before* it occurs) typically intercept calls to the DOS (or BIOS) interrupt handlers. If the interrupt request is to write to the disk, the prevention program will notify the user. The general impression I get is that people think that if a program can intercept all potential avenues a virus can take to write to the disk, it would be foolproof (or close to it). However, a clever virus could simply check to see if the interrupt vector is pointing to something other than the DOS/BIOS commands to write to the disk (i.e., the vector would point to the intercepting prevention program). If the virus determines that the vector does not point to DOS/BIOS, it could simply change the vector to do so, replicate itself (infect other programs), and then change the vector pointer back to the "intercepting program". The user would be none the wiser. Comments/technical corrections? Neil A. Goldman Ernst & Whinney National Computer Audit Group ========================================================================= Date: Thu, 28 Jul 88 14:08:50 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Claudia Lynch Subject: Possible Virus The following message appeared on our campus BBS. If anyone has any pertinent information, please reply. Thanks, Claudia Lynch We shall work no time, before its nine!| #1791 28-JUL-1988 08:57:33.73 Topic : PUBLIC INFO From : ALAN MATTHEWS To : ALL Subject : possible virus I've been using the "Master Key" utility by R.P.Gage. For a while and have been having problems with my disk. It is a really nice utility program; it allows you to hide,unhide,delete,and undelete files, look for matching files , and has a hex/ascii sector editor(that's the best way I can describe it) I had, until recently been blowing my FATS sectors. This caused my endless amounts of annoyance as I would get parity errors on my disk drives, and eventually would not be able to load programs. I finally erplaced my motherboard and these problems haven't surfaced again(yet). I'd like to know if anyone has had similar prioblems with this program, or if it was, in fact, just a hardware problem. AM ========================================================================= Date: Thu, 28 Jul 88 15:49:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University David, When I speak of the Playboy virus, I am referring to one of the many things by that name. I refere to a POC program which was complained about slightly in Main I brelieve tha simply copies itself from disk to disk. It is an executable fiel that does this. I should not have nmentioned the Flushot thing, I know it is a trojan. When I talk of a certain number of viruses, I ONLY mean viruses. A list of trojan horses would come out with at least several hundred. However, I am counting variations of viruses as viruses themselves. In my posession I have about 15 viruses and about 20 trojan horses, I have a list of about 70 viruses from reliable sources. I also do not include viruses that peop-le wrote themselves to annoy their co-workers. Haggling oover the specifc number of viruses in the world, however is rediculous. Incdidently, I received two boot sector viruses in the mail (physical mail) without a return address, and they are viruses I cannot identify as anything in particuloar. Also, is anyone on this list from Alabama or Mississipi? Loren ========================================================================= Date: Thu, 28 Jul 88 15:59:51 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Regarding anti-viral programs, I don't think anyof them is the answer. I'm leaning towards hardware protections, and have a few ideas. We really need the hardware to be resdesigned. There isn't anything we can do to prevent the pspread of virueses. All we can do is make it harder and harder for one to get around. Neil, if you were referring to my comments arbout the program we've written, we considered what to referred to as taking over the interrupts, but its too shabby a job and isn't the way we do it. We also, of course, watch for interrupt changes. But again this is not the answer to all our problems. Fred Cohen demonstrated up in New York a little probgram which basically CRC'd everything (it was a powerful check, but still just a file check). And I think that isn't enough either, our program has more than just disk watches, it has the standard CRC's for people who want to use them (one-way increyption) and so on. If enough people use Vaccine and the Innoculator and SDP, and FluShot, then a virus really doesn't stand a chance of getting too far. The more packages out there, the harder a virus is to propogate. Antoher point, something Fred's program does, Vaccine does and our does is have a random key selected which keeps the virus vfrom being able to mimic any CRC. The only thing we can do is make it harder and harder to write a virus which will go through our derfenses, and limit the number of people who CAN write one. Fred, incidently, talked of making the nth level of difficulty in writing a virus, in which case we are safe. I thinkk the world is on the right track. Now we have to convince the world to use the PC condoms that exist (not necessarily anyone's ion particular). Loren ========================================================================= Date: Thu, 28 Jul 88 16:07:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University (Heavy mail is BACK on Virus-L!) One more thing Neil, We're more and more referring to Anti-Viral programs as "Virus Detection Systems" not "Virus Prevention". The object t is to detect the virus as early as possible. You can't stop that first infection (primary infection) from someone elses system, but you may be able to stop it from infecting a second file, or from actually doing damage to your system. We're relagate d to fighting the symptons rather than the fi viruses themselves. Loren ========================================================================= Date: Thu, 28 Jul 88 16:49:06 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: How many viruses are there? Agreed, I didn't mean to be trying to pin you down to a specific number. I was just surprised to hear a number as high as 70; I guess a lot more has been going on than anyone has mentioned here or in similar places. I'll be eagerly awaiting your posting of your list! I think the point about people using lots of different anti-viral programs is a very good one; this is one field where you don't want your own program to be the One Everyone Uses, because if it is, the virus-writers will target it, take it apart, and design circumventions. Safety in Numbers! DC ========================================================================= Date: Thu, 28 Jul 88 16:48:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Questions about Brain In-Reply-To: Message of Thu, 28 Jul 88 14:14:37 EDT from >I'd like to know who all was hit the worst by the Christas >Tree Exec. IBM's VNET got it the worst. Most of the users there had literally hundreds of ID's with which they had corresponded, with the result that thousands of copies of the exec got out. They had to disconnect from BITNet for nearly 2 weeks (as I recall). >How far did the Aldus virus get? Not very. Remember, it's a self-limiting virus which burns itself out after a one-time shot. It got into the warehouses, but there's little evidence it actually hit the streets. Richard Brandnow's contention that he did it to prove how much piracy was going on is an unmentionable substance found in pastures. His claim on CompuServe was that he did because he wanted to. (Too bad I can't type this in brimstone-spewing letters). >Can anyone tell me about the NASA virus other than what was in >the papers? (NASA claims they didn't have a virus!) Some people here may have had the Scores virus. I'm watching it here at Goddard; we've got Vaccine to everyone we could find, along with KillScores and Interferon. --- Joe M. ========================================================================= Date: Thu, 28 Jul 88 16:38:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon In-Reply-To: Message of Thu, 28 Jul 88 13:58:05 EDT from > ...For the Mac, I've seen aa version >of the CHRISTA virus (yes, simple damn thing copies itself >around your little Mac, its not written in Rex of course), More information about this, please. I'm building a document about Mac viruses. Resources, symptoms, etc. I can't use rumours. >...the Phantom, the NASA virus, the Aldus virus, and the VULT >virus... The NASA virus and the VULT virus should be the same one, known as "Scores". Is the Phantom a new one I haven't heard of? Symptoms please. What resources are involved? I would appreciate your pointing me to anyone who can prove that either the Phantom or CHRISTMA virus exists. The CHRISTA sounds like it is a nuisance bacterium rather than a viral infection. I need technical data -- resource names/numbers, modifications made by the viruses, etc. >... the top of may head is a Mac virus which prints a picture >of a nude female on the screen while it copies itself to any >other disks in your system... As I recall, this program shows the picture and erases your hard disk; it doesn't propagate itself as a virus. Perhaps you mean a bacterium? --- Joe M. ========================================================================= Date: Thu, 28 Jul 88 15:28:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: CEARLEY_K%wizard@VAXF.COLORADO.EDU A relatively effective software strategy for an anti-viral program is to use the timer interrupt. It is done by installing a TSR which implements two functions: 1- When loaded, it intercepts the timer interrupt vector. It then times its own execution and stores this duration with a checksum. This prevents its interrupt from being preempted by using timing dependencies. 2- At 18 times per second, it compares interrupt vectors for modifications, these are flagged and, if restricted, they are disabled. The resolution is somewhat coarse considering the number of machine instructions that can execute between intervals, but it can effectively arrest the destruction of data. Kent Cearley Management Systems University of Colorado ========================================================================= Date: Thu, 28 Jul 88 16:55:12 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Questions about Brain In-Reply-To: Message received on Thu, 28 Jul 88 15:10:07 EDT Here at the University of Maryland the (c) Brain virus was first noticed about year and a half ago. We have several floopy based labs on campus that are run by the business school. Data security at these labs was not the best and eventually all the boot disks were infected. The version of Brain we had was totally benign but a big stink was raised when the Brain virus infected some floopies that had bad physical media. Every one said that the Brain had mutated into a malignant virus! Today, infections by the Brain virus are very rare on campus. We stamped out the virus with a simple three part attack. 1. I down loaded the NOBRAIN.C program from VIRUS-L. With a fair amount of hacking I made it work with the version of Brain we had. I distributed the program to the Lab managers on campus, and for a while they put a command to run the program in AUTOEXEC.BAT. 2. We had an campain to educate users on the importance of write protect tabs. 3. And finally we stoped buying cheap disks. I suspect that in September we will see it again, as students inadvertently bring it back to school. With these simple precautions we should be ready for it. Although I have heard many rumors, I have yet to see any virus on the University of Maryland campus that did any damage. Erik Sherk ========================================================================= Date: Thu, 28 Jul 88 15:53:01 mdt Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was From: Bill Kinnersley Subject: Re: Trapping Direct Disk Write Calls [In "Re: Trapping Direct Disk Write Calls", Len Levine said:] > > Very interesting about command.com. That file, as released in > msdos level 3.3 contains a 4000 byte block of zeros at its end, which > makes it VERY easy to add code. > > I cannot fathom why they put that area into the process. > Perhaps they pad their software with zeroes to avoid possible shipping damage. :-) ========================================================================= Date: Thu, 28 Jul 88 15:12:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SUE@UWAV1.ACS.WASHINGTON.EDU Subject: RE: Re: Trapping Direct Disk Write Calls test posting, please ignore. ========================================================================= Date: Thu, 28 Jul 88 23:25:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: RE: Questions about Brain >[...] > >Does anyone have a copy of the Apple version of Core Wars? > A Macintosh version of Core Wars can be obtained from LISTSERV@RICE.BITNET by sending the command (in the first line of a MAIL message) $MAC GET DEMO-COREWARS.HQX This will get you the BinHex-ed version of the program, along with the documentation. You'll need BinHex and PackIt (or UnPackIt) (or is it StuffIt; I don't remember, sorry) to recreate the application. If you don't have them, ask around. Someone local should have them. > >[...] > >I'd like to know who all was hit the worst by the Christas >Tree Exec. The worst case, based on reports in RISKS TO THE PUBLIC IN THE USE OF COMPUTERS AND OTHER AUTOMATED SYSTEMS (a.k.a. RISKS Digest) would have to be IBM's internal network, called VNET. It slowed it down to such an extent that most of it had to be shut down until the program could be removed from the mail queues. >[...] >Can anyone tell me about the NASA virus other than what was in >the papers? (NASA claims they didn't have a virus!) This is a new one to me, I think. SPAN/HEPNet had one H*ll of a case of crackers, though! They almost made VMS Security an oxymoron. >[...] >Loren _______________________________________________________________________________ | James M. Shaffer, Jr. | Bitnet: shafferj@bknlvms CIS: 72750,2335 | | P.O. Box C-2658 | Internet: shafferj%bknlvms.bitnet@cunyvm.cuny.edu| | Bucknell University | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj | | Lewisburg, PA USA 17837 | CSNet: shafferj%bknlvms.bitnet@relay.cs.net | ------------------------------------------------------------------------------- | "He's old enough to know what's right and young enough not to choose it; | | He's noble enough to win the world but fool enough to lose it." | | -- Rush, "New World Man", on _Signals_ | ------------------------------------------------------------------------------- Disclaimer: I'm not the list owner! (See the last NetMonth.) :-) X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: The NIRVANAnet(tm) Seven & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 Burn This Flag Zardoz 408/363-9766 realitycheck Poindexter Fortran 510/527-1662 Lies Unlimited Mick Freen 801/278-2699 The New Dork Sublime Biffnix 415/864-DORK The Shrine Rif Raf 206/794-6674 Planet Mirth Simon Jester 510/786-6560 "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X