From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V3 #149 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Thursday, 30 Aug 1990 Volume 3 : Issue 149 Today's Topics: Re: Stealth viruses (PC) Re: virus names Re: vaccine viruses - a poor analogy antiviruses can be good Desktop Manager for WDEF/CDEF (Mac) Re: virus analogy Re: WARNING 'avi' does not find cascade 1701/1704 Viruses! Re: virus analogy Re: Infected? (PC) Re: infected? (PC) Re: Antivirus viruses Re: virus analogy RHC to New York Times, re: Markoff Article VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: 25 Aug 90 12:27:44 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Stealth viruses (PC) mweiner@bene.at (Michael Weiner) writes: >There is an additional problem: Many of these 386/486 memory managers >allow you to define "high DOS memory" over the 640k barrier. 386max >for example allows you to load device drivers and TSRs into this >memory region (In my case, it is 96kB at C800 - E000). I just wanted to mention that we already have one virus which is able to load itself above the 640K barrier. The E.D.V. boot sector virus starts to look for free ram at E800:0000 and moves downward in 64K jumps - skipping the area 9800-B000 As an extra twist, the virus will attempt to crash any program scanning high memory - in intercepts the "timer-tick" interrupt, and if it finds that ES or DS point to the region where it is hiding, it will halt the computer. This of course makes scanning for this virus a bit complicated. - -frisk - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: 25 Aug 90 12:40:37 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: virus names CSTEHLIK@SCU.BITNET writes: >When there were only a few viruses, it was fine to give each a creative >name, but now there are over 200 and most have several aliases. > > ..... > My personal preference would be naming them by size and then an >optional extension to denote variants or special characteristics. An >example is 1704-a, or 4096-stealth. My opinion is the exact opposite - Using the file length was OK while we only had a few viruses, but now that we have over 200, it just does not work any more, as many totally unrelated viruses may have the same length. Just take 1701 and 1704 as an example. We have 1701 - original version of Cascade, which activated in the fall of '88, - the "every year" version. - "Jo-Jo", a related, but quite different virus. - a 1701 byte variant of the "Phoenix" virus from Bulgaria. 1704 - The IBM infecting variant of Cascade. - The non-IBM infecting variant of Cascade. - The Yugoslavian "Y" variant of Cascade. - The "multiple infection" variant of Cascade. - The disk-formatting variant of Cascade. - The Bulgarian Phoenix virus. - The Phoenix-D virus. and possibly a few more which I do not remember right now. Besides, how is the virus length to be determined - just take a common virus like Jerusalem. Should it be called "1808" (EXE) or "1813" (COM) ? - -frisk - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: Sat, 25 Aug 90 12:55:00 -0500 From: ELMO@db1.cc.rochester.edu Subject: Re: vaccine viruses - a poor analogy We've been generating a lot of steam about vaccine viruses lately. Some of those who support the idea want to back it up by the analogy between computer viruses and human viruses. Critics of the idea have pointed out that the vaccine against a virus is adminstered with consent, which is true. However an even more fundamental point is that biological viruses evolve under natural constraints. Computer viruses, however, evolve under the divine intervention of human beings. So unless we are willing to accept that there are deities affecting the evolution biological viruses, the analogy breaks down. Yes I know the viral-based vaccines are engineered by humans. But in the case of the "live" ones, they go on and evolve by themselves, as opposed to computer vaccine viruses which would probably evolve by tampering alone. Eric Cabot elmo@uordbv.bitnet Department of Biology elmo@db1.cc.rochester.edu University of Rochester elmo@uhura.cc.rochester.edu Director, Harry Faversham Memorial Institute for Computer Dollar Incineration ------------------------------ Date: Sat, 25 Aug 90 11:10:08 -0700 From: attain!RATVAX.DNET!ROBERTS@apple.com (I'm working on it...) Subject: antiviruses can be good I like the idea of anti-viruses, I think they can be a good thing, but I also think they should be illegal and the writing of them should have the same punishment as a destructive virus for 2 reasons: 1) If they have bugs they can be destructive. 2) They are legally indistinguishable from other viruses. I like the idea of anti-viruses because they can help people who are unaware of a virus problem on their system without bothering them. They could potentially kill the spread of destructive viruses before they ever get to some unwary users who would have gotten hurt if it weren't for the anti-virus. And people who are aware of viruses will easily squelch the anti-viruses with software that they are already paying for and using. - ------- rubinoff@linc.cis.upenn.edu (Robert Rubinoff) writes: >"Anti"-vaccines don't fit this pattern, because they are spread >without any concern for their suitability on particular systems. >Also, by their nature they inevitably spread to other systems which >may not be able to tolerate them. Like the polio vaccine, if >administered indiscriminately they would end up causing serious >"infections". An anti-virus could be written to infect only certain types of operating systems. - ------- The opinions expressed here are mine and not necessarily those of my employer. - - George Roberts ...decwrl.dec.com!teda!ratvax.dnet!roberts ------------------------------ Date: Sat, 25 Aug 90 17:56:00 -0500 From: Big fish man on hippocampus Subject: Desktop Manager for WDEF/CDEF (Mac) What an idea... maybe. In order to avoid the CDEF and WDEF viruses, won't the Desktop Manager work? By removing the Desktop file, they won't be able to infect that file. Also, this is, I believe, shipped with new Mac systems. I understand that the Desktop Manager and its cohorts, Desktop DB and Desktop DF, are more efficient than the old Desktop. The "Desktop" is not recreated if you "rebuild the Desktop" after the Desktop Manager is installed. (I don't know if the Desktop is removed when it is "rebuilt;" I just removed mine by hand.) I guess it updates the DB and DF files. When I installed the DT Manager, documents weren't finding their creator until I rebuilt the desktop, but I haven't had any problems since. Let me/us know if there would be any problems with this. ++++++++++++++++++++++++++++++++++++++++++++++++++ |\ \\\\__ Anthony Maimer | \_/ o \ __ > _ (( <_ / | | / \__+___/ / | |/ |/ /o /_/| < )) _ < maimer@kuhub.cc.ukans.edu \ \ \| \ | +++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ Date: 26 Aug 90 00:48:38 +0000 From: decomyn@penguin.uss.tek.com Subject: Re: virus analogy SYSBXR@SUVM.ACS.SYR.EDU (Bridget Rutty) writes: >> I can think of at least one precedent from the medical profession >>- - the Saulk (sp?) vaccine (the primary polio vaccine in the US). Thiss >>vaccine is a live, contagious, virus. Any Physician who administers it >>is releasing a virus into the population. This is considered an >>advantage. ... > >This is NOT a precedent, or even a good analogy. Physicians do not >administer any medication, vaccine or otherwise, without understanding >the risks and benefits. Patients do not get vaccines without consenting. >Granted, some patients may not understand all the risks of a vaccine >but that probably is because they do not ask. This is not exactly true. Although the person getting the vaccine (or their parents) hopefully understand the risks and benifits, the Salk vaccine actually spreads to non-vaccinated people, transmitting the benifits of the vaccine to them without their knowledge or consent. That is why the Salk vaccine is used, rather than a killed virus vaccine. Brendt Hess decomyn@penguin.uss.tek.com ------------------------------ Date: Sun, 26 Aug 90 04:33:22 +0000 From: ts@uwasa.fi (Timo Salmi LASK) Subject: Re: WARNING 'avi' does not find cascade 1701/1704 Viruses! rzi@philpav.UUCP (Roman Zielinski) writes: >'avi' has been posted some weeks ago in c.b.i.p. I don't think it is to be >trusted too much... > >I had got two diskettes from a 'cheep' hardware dealer in Stockholm containing >VGA-drivers and setup (original and their copy - I don't know how and why they >gave me this extra copy-diskette?). have a habit to test all diskettes >from other sources, so I found that the non-original diskette has virus >1701 or 1704 ('cascade' and/or 'format') - I am happy because I checked : >Summa summarum: > 1. Do not trust ANY diskettes that they are not yours > even if they come from a dealer (who knows how serious are the kids > working there...?) > 2. Do not trust single ani-virus programs (get a second opinion from > another virus scanner) > >And at last an Ethical question, What should I do with the dealer? : First of all let's follow-up to comp.virus, but I'll post also to c.b.i.p.d because it has some relevance to this group as well. At the University of Vaasa we had a similar experience when we bought six new 386 PCs from a very small local dealer (at a favorble price). The VGA driver programs that came with the delivery contained a Sunday virus, and very nearly caused nasty havoc but for the astuteness of one user. The dealer is not really the one to blame here (his knowledge of PCs being very limited :-) but the original importer. The annoying thing is that when told them about the virus, the importer just shrugged it off, and may still be at it. We seriously considered suing, but finally decided against it. The lesson here is the same as yours. Don't trust any sources. This goes for ftp sites as well. We do our best to guard against these eventualities, and nothing has happened yet, but no absolute guarantees can be given. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun ------------------------------ Date: Sun, 26 Aug 90 03:42:40 +0000 From: peter@ficc.ferranti.com (Peter da Silva) Subject: Re: virus analogy SYSBXR@SUVM.ACS.SYR.EDU (Bridget Rutty) writes: > This is NOT a precedent, or even a good analogy. Physicians do not > administer any medication, vaccine or otherwise, without understanding > the risks and benefits. Patients do not get vaccines without consenting. > Granted, some patients may not understand all the risks of a vaccine > but that probably is because they do not ask. Actually, that's not entirely true. One of the reasons for using the attentuated virus vaccine instead of the killed virus vaccine, other than the improved protection, is that people who have not been vaccinated but come in contact with recently vaccinated individuals (generally other kids at schools or day-cares) will be infected by the attenuated virus and get the same immunity. - -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com ------------------------------ Date: 26 Aug 90 05:08:18 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: Infected? (PC) Watkins@np1a.bristol.ac.uk (Steff) writes: > With response to James Li (Uk.AC.OXFORD) .... > > It looks like you have had a case of INT 26 (I Believe) calls. This causes an > absolute disk-write of some area of preogram memory onto the disk. > A> Some of your source code contains an INT 26H call that it shouldn't. MSDOS 4.x has monkeyed around rather severly with the int 25 and int 226 call If the CX register is ffff (an illegal value under dos 3.x) it presumes that the registers are used diffrently in order to support the new 32 bit fat table. This may cause severe system crashes and file corruptions. Cheers Woody ------------------------------ Date: 26 Aug 90 04:56:31 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: infected? (PC) James Li posts a message about trashed disks. o.k., I would say that you have no infected disks, but what has happened is fairly nasty. I am assuming that you formatted the disks on the other machine. Now, there are various flavors of DOS around, and various flavors of format utilities. If you take a disk formatted and written on by dos 3.x and try reading it on a system running dos 2.1x you will have symptoms exactly as described. MS-DOS is only upwardly compatable between major releases, i.e. primary number changes. There is an additional problem. We released a new software package where I work. Some of our users reported that file directories were garbaged out and the programs would not work, others had no problem. I got a set of bad disks sent back. On my machine they were trashed, on a compaq they were trashed, on another machine, running another flavor of DOS, they were fine. A perusal with Norton, revealed the following: In the FAT table (the File Allocation Table) the first byte used to be used as a format identifier. If it was a F0 it marked a single sided 180k floppy. If it is F8 it is a double sided 360K floppy. The format program out on the factory floor was formatting double sided, but writing the id byte for a single sided disk. Some versions of dos make decisions based on the FAT table, others use other criteria to determine what kind of disk it is. Those that used other critera, such as placement of FAT tables worked, the ones that used the id byte didnot. MS documentation says that the id byte can no longer be relied on. The basic problem is that the first copy of the FAT always resides at the same spot both for 360k and 180k floppies, but in the case of a 360k floppy, the fat table is 2 'x as big. The second sector of the second fat table, occupies (on a 360K disk) occupies the exact same physical/logical sector as the directory sector on a 180K floppy. This results in total hash in the directory if the system thinks it's a 180K floppy. Hope this helps Cheers Woody ------------------------------ Date: Mon, 27 Aug 90 12:14:39 +0000 From: cbp@foster.avid.oz.au (Cameron Paine) Subject: Re: Antivirus viruses Thus far, the debate has concentrated on the ethics of viruses designed to `destroy' other viruses. One or two contributors have touched on the *real* issue but their comments seem to have been lost in the hubbub. While I'm unfamiliar with other parts of the world, I'm sure you can all think of non-indigenous (biological) organisms which when released, ran rampant in their new environment. In Australia, we have many examples: cane toads, rabbits, blackberries and the prickly-pear cactus spring immediately to mind. Since none of you can *guarantee* that you can write software that will perform without fail on all potential hosts, there is no question. Such an approach is doomed before it starts. A case in point is SCANV66 (no offence to John intended - I selected it because most readers will have read about it recently). Since it wasn't an auto-propagating program we simply had to note John's bug report and replace it with 66B. Think about it... and then stop thinking about it. It's a disaster waiting to happen. cbp - -- cbp@foster.avid.oz - ACSnet cbp%foster.avid.oz.au@uunet.uu.net - Internet ...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.avid.oz.au!cbp - UUCP ------------------------------ Date: 27 Aug 90 14:45:11 +0000 From: CAH0@gte.com (Chuck Hoffman) Subject: Re: virus analogy SYSBXR@SUVM.ACS.SYR.EDU (Bridget Rutty) writes: > > In the situation described, there is no informed consent and to my > mind such a program is no different than the virus with which it > competes. I agree with Bridget. In this thread, many responses wandered off onto the technical issues, but this was not the point. In our culture, it is not accepted to "help" someone without their informed consent. And this means more than just putting some text and an "OK" button up on a screen prior to execution. I think that understanding this principle is a real task for younger programmers, especially those just entering their full adulthood. They have spent their lives receiving "help" from people without giving consent, like parents, teachers, and the like. They have no way of knowing how special a case they were because they were not yet fully enabled to give judgement and consent. It's a new business, all of this, about how important it is to get another adult's informed permission first, before helping. Although this understanding will come with time, much of the code these days is being written by those who have not yet developed this understanding, and who do not have technical supervision from those who have. As a group, our technology may be ahead of our personal maturing processes. Chuck Hoffman, GTE Laboratories, Inc. ! I'm not sure why we're here, cah0@bunny.gte.com ! but I am sure that while Telephone (U.S.A.) 617-466-2131 ! we're here, we're supposed GTE VoiceNet: 679-2131 ! to help each other. GTE Telemail: C.HOFFMAN ! ------------------------------ Date: Mon, 27 Aug 90 11:25:00 -0400 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: RHC to New York Times, re: Markoff Article Forwarded with permission. #246 (79 lines): Date: Thursday, 23 August 1990 08:24 edt From: rhcx%beta at LANL.GOV (Robert H Courtney) Subject: NYT Article To: WHMURRAY at DOCKMASTER August 19, 1990 Mr. Max Frankel, Executive Editor The New York Times 229 West 43rd Street New York, NY 10036 Dear Mr. Frankel: Your article, "Washington is Relaxing Its Stand on Guarding Computer Security", by John Markoff, August 19, reflects a serious misinterpretation of both the intent and the probable effect of the new Presidential directive on computer security. The new directive replaces NSDD #145, which was issued by the Reagan administration in 1984. With the authority of that older directive, and because they were not willing to accept the utterly mundane, unexciting nature of the data security problems in most agencies, the National Security Agency (NSA) distorted the data security implementations of many federal civil agencies and reduced the effectiveness of their computer security programs. NSA's computer security efforts were oriented exclusively about the protection of classified data from disclosure to those who did not have appropriate security clearances. Their development program did not address the need for data to be complete, accurate, timely and available. They were concerned only with the confidentiality of data and wholly unconcerned about their usefulness to their proper owners. It has been an unfortunate NSA assumption that those with appropriate security clearances can be trusted to the level of their clearances. This ignores the damage which has been done in recent years by Messrs Walker, Pelton, Pollard, Boyce, Smith, Miller, et al, all of whom were cleared for access to the data which they delivered to those who appeared, until recently, to be the enemy. There seems to be no basis for a belief that comparable damage has been done through technically-oriented, foreign-directed penetrations of our systems containing classified data. Fortunately, the new directive relieves the civil agencies from a requirement that they continue to accept misleading guidance in computer security from NSA. Unfortunately, it was not issued not until significant damage had already been done. The Computer Security Act of 1987 gives the National Institute for Standards and Technology (NIST) responsibility for providing technical guidance in computer security to the civil agencies and DoD for the protection of their unclassified data. It is regrettable that NIST is very poorly funded for work in the computer security area and, at the current funding levels, cannot provide any significant amount of the technical leadership in computer security so badly needed by the civil agencies. Only a small portion of funds previously available to NSA for computer security would permit NIST to provide the needed guidance. Whether those funds are provided or not, the new and wisely conceived directive will not result in relaxation of the security afforded data by either DoD or the civil agencies. The new directive rectifies a serious error of the previous administration and makes it probable that data security in the civil agencies will improve - not as much as it would if NIST had adequate funding and not as much as it should, but it will be improved. The contrary impression conveyed by your reporter is unfortunate. Sincerely, Robert H. Courtney, Jr. ------------------------------ End of VIRUS-L Digest [Volume 3 Issue 149] ******************************************