VIRUS-L Digest Thursday, 10 Oct 1991 Volume 4 : Issue 187 Today's Topics: re: DIR II removal (PC) Re: Hardware Re: DIR II (Cluster) Virus (PC) Re: HW not a virus solution Need help with Empire virus (PC) Re: VIRUS-L Digest V4 #185 New virus - advanced symptoms (WAS: New virus warning (PC)) Re: DIR II (Cluster) Virus (PC) Viruses and OS/2 (OS/2) Stoned on 3.5" disks / "1590" virus (PC) disable ctrl/break? (PC) False Alarm (PC) Hardware and Software; Re: Forget Turing... Re: Forget Turing... Psychology of virus writing (was HW not a virus solution) 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: Wed, 09 Oct 91 13:16:36 +0700 >From: Andrzej Kadlof Subject: re: DIR II removal (PC) Joe Wells <0004886415 at mcimail.com> writes: >A disinfector should be written only by a qualifid (preferable asm) >programmer and tested extensively. This particular virus is extremaly easy to remove. It may be done very quickly by any non qualified person in the following way: 1. Rename all executable COM and EXE file to something else (CCO and EXX). 2. Reset computer from clean disk. 3. Run CHKDSK /F 4. Rename all CCO and EXX back to COM and EXE.. step 3 is necessary only if you want back two sectors occupied by virus. DIR II will do the rest for you. But remember, above work only with DIR II. Regards, Andrzej Kadlof Department of Mathematics, University of Warsaw, Poland Editor-in-chief of PCvirus bulletin KADLOF AT PLEARN.BITNET ------------------------------ Date: 09 Oct 91 12:30:59 +0000 >From: groot@idca.tds.philips.nl (Henk de Groot) Subject: Re: Hardware turtle@darkside.com (Fred Waller) writes: [Description of his super virus-resistant computersystem] All Fred (Waller) makes clear is that he allows infected programs on his hard disk (infecting his machine) but that the infection can not spread due to the hardware-write protection. He forgets that some data-files are also program files (not for the cpu but for a program on the program-disk) and a virus written in the interpreted language can infect all the other "data" files of this interpreter. Fred said he uses his spreadsheed whitout worrying, but if I write a virus in his spread-sheed language and put it on his machine, than after usgage all his spread-sheeds are infected. If it is a distructive virus than I may distroy all his spreadsheeds on friday the 13th. Right, the speadsheed program itself is still clean, but still he lost all his files on this "virus-resistant" computer-system! Henk. - -- / / Henk de Groot | Department: PG 9000i - System Services /---/ __ __ / V2/A12-A13 | Internet : groot@idca.tds.philips.nl / / (-_ / / /( Tel: +31 55 432099 | == PHILIPS INFORMATION SYSTEMS == Disclaimer: I only speak for myself, not for my employer! ------------------------------ Date: Wed, 09 Oct 91 12:08:45 +0300 >From: grdo@botik.yaroslavl.su (Dmitry O. Gryaznov) Subject: Re: DIR II (Cluster) Virus (PC) In VIRUS-L vol.4 iss. 180 bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >with the FAT and to run Norton Disk Doctor. One more thing - the virus >body is marked as 0(F)FFEh in the FAT. This is interpretted as EOF by >DOS. In fact, DOS interptrets as EOF any value from 0(F)FF8h to >0(F)FFFh, but uses only the last one. The virus does not check whether >a disk is already infected (i.e., that the virus body is already >present on the disk), so this marker cannot be used to "vaccinate" the >disks. And in VIRUS-L vol.4 iss. 183 : >hex representation of the EOF mark in the FAT is 0(F)FFEh (means >virus), or 0(F)FFFh (means normal EOF). Anyway, the virus does not use >this strange mark for self-recognition, so IMHO the strange value is >a bug un the virus code. No, it is *NOT* a bug. The virus *DOES* check whether a disk is already infected. In this case it neither updates FAT nor writes itself to a disk. It is true, nevertheless, that such a mark ((F)FFEH) cannot be used to "vaccinate" a disk. Such a "vaccinating" will cause additional problems - the virus won't infect a disk BUT IT STILL WILL crosslink all executables to the cluster. And since there will be no the virus body on a disk - there will be much more difficult to detect an infection and to repair files. COMMAND.COM being cross-linked to a "vaccine" cluster without the virus body will be just corrupt as well as other executables. >in use or not. Therefore, it can destroy part of a file (or directory) >which uses this cluster. Since the virus body is written on any >accessed disk, regardless whether the latter contains executable >files, the destruction of information described above occurs most >often on backup diskettes or diskettes that contain only one large >archive file, or that are otherwise full up to the last cluster. Since >the DOS program BACKUP tends to write its control information in a >small files -after- the backup, such destruction will damage the whole >backup on the diskette. One more tip to detect an infection. Suppose you have a disk similar to described above. It mustn't be exactly BACKUP disk - it's enough to have a file occupying the last cluster. Now suppose this disk is write protected. Thanks to [cf. Fred Waller] "a simple hardware device called a write-protect tab" (grin) the virus won't infect a disk. Neither it will overwrite the file. But this file (using the last cluster) becomes unaccessible - DOS will report "File allocation error" while reading such a file. The reason is that the virus decreases the actual disk size and, hence, DOS believes the last cluster to be beyond the disk. It is not just an assumption - I've tested this. Oh, yeah, as was already mentioned by others, DOS won't report "Write protect error" due to the virus. In the previous message on the same subject I wrote the virus tries to open a file in the *ROOT* directory on C: not in the *CURRENT*. I appologize. It really uses *CURRENT* directory. But the virus still tries to *OPEN* not to *EXECUTE* this file. - -- Sincerely, Dmitry O. Gryaznov | PSI AS USSR grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su | Pereslavl-Zalessky Phones: office: (08535)-2-0715 home:(08535)-2-1465| 152140 USSR ------------------------------ Date: 09 Oct 91 13:03:05 +0000 >From: telxon!johnk@uunet.uu.net (John E. Kabat Jr.) Subject: Re: HW not a virus solution The Name of the book is The Shockwave Rider by John Brunner John E. Kabat Jr. <|> ...!uunet!telxon!teleng!johnk Telxon Corporation <|> P.O. BOX 5582 <|> 1-800-800-8001 x 3554 Akron, OH 44334-0582 <|> ------------------------------ Date: Tue, 08 Oct 91 17:07:16 +0000 >From: kees@ee.ualberta.ca (Kees denHartigh) Subject: Need help with Empire virus (PC) I have been attacked by the Empire virus. Both fprot and scan detected the virus in the boot sector of both my hard drives. fprot was unable to remove the virus for the boot sector but clean82 reported successfully removing it. The problems the Empire virus originally caused seems to have dissappeared however fprot200 still reports the virus in the boot sector of both drives. I backed up my D drive insuring that I the virus was not infecting any backed up files and reformatted the drive and restored and still fprot200 reports the Empire in the boot sector of the reformatted drive. Is it really there or fprot200 lying to me. Scan82 detects no viruses after clean82. Does anyone have any ideas? - -- Kees denHartigh kees@ee.ualberta.ca Electrical Engineering Digital Labs alberta!bode!kees University of Alberta 238 Civil Elect Voice (403)492-5421 Edmonton, Alberta Canada Fax (403)492-1811 ------------------------------ Date: Wed, 09 Oct 91 13:14:34 -0400 >From: ctraynor@attccs1.attmail.com Subject: Re: VIRUS-L Digest V4 #185 Jay Skeer: In your posting about the book with the phone network worm, I think you were refering to the S.F. book "The Adolescence of P1". I have also read this work and found it quite interesting. I would recommend it to others with hig regard not only for its storyline, but also its insight for the time period it was written in. If anyone has a problem finding the book, I might consider parting with mine via mail - but please convince me that I will get it back ASAP. Happy hunting.... Chris ------------------------------ Date: Wed, 09 Oct 91 17:49:17 +0300 >From: ish@ire.msk.su (Shulman Ilya A.) Subject: New virus - advanced symptoms (WAS: New virus warning (PC)) Vesselin Bontchev writes: >> >The virus is also a stealth virus. While it is active in memory >> >it is difficult to detect. >> ^^^^^^^^^^^^^^^^^^^^ actual size of the disk :-) but >You probably mean that if you know the exact full size of your disk, >you'll notice when it changes. However, I don't think that many users >will notice even when the size of 360 Kb diskette gets changed from >354 to 353 Kb, let alone the larger media... :-) No, I mean that it is very simple to identificate is virus present when it is active :-) >> 2 check last cluster in the 1 and 2nd copies of FAT if in first you found >> EOF but in second not than it may be thesignal that those virus is hear. >Sometimes DOS updates the second copy of the FAT itself, so this >method is unreliable. I have observed several cases in which the EOF >mark was present in both copies of the FAT. Better check whether the Are you sure that "Sometimes Dos updates" all copies of the FAT up to the end? When it happens? How I can initiate Dos to do it? I observed this virus on the few computers and the difference in FAT was on each of them. Two computers worked with this virus in memory nearly 1-1.5 month and users didn't know about it. To my mind the difference in FAT is a stable symptom but not only _ONE_. >Anyway, the virus does not use >this strange mark for self-recognition, so IMHO the strange value is >a bug un the virus code. Anyway is it error or not, we can count it as one of the virus's appearence. >The virus has been named in SU ( as far as it appeared here in early >summer) as DRIVER-1024 (due to scheme of infection) or DIR but not >DIR-2 >...and if the file attributes for this entry do not indicate System, >Directory, or VolumeLabel. Naturally. Thanks. >> 2 There were the situation when disk was infected and virus occypies not >> the last cluster and not even near. That is why I think that there may >> be situation when 2 or more copies of virus may be present on one disk >Have you really observed such situation?! It shouldn't be possible, >according to the virus code... Yep. Two times I found virus on the hard disk in the cluster 714 and 2371 (I can't remember this numbers exactly but) which are the last clusters on the 5" 1.2Mb and 3.5" 730Kb diskettes respectivly. I can't explain why there were the last clusters but not the pre-last but it was so. Also I know the other abnormal effects when virus infects disk but didn't write itself to the last cluster. May be it is an error too, but anti-virus developers _HAVE TO_ know this. Best Wishes. - -- /-----------------------------------|---------------------------------------\ | Ilya A. Shulman. | E-Mail: ish@ire.msk.su | | Institute of Radio Engineering | :postmaster@ire.msk.su | | & Electronics ACAD.Sci. of USSR. | phone :(7-095)203-17-16 | ------------------------------ Date: Wed, 09 Oct 91 20:26:01 +0000 >From: smyser@athena.mit.edu (Robert Smyser) Subject: Re: DIR II (Cluster) Virus (PC) For those epidemiologists who like to follow the spread of these things, the DIR II virus has definitely reached MIT. Our Lab and the one at the Sloan School both have machines with all the symptoms. I'd say it first appeared in our lab on or about Oct 1, 1991. At risk of seeming obtuse, I ask, just what is the method of transmitting this virus from machine to machine? Is it by physically transferring an infected executable from one machine to another? Thanks for all the fine sleuthing! - -Rob - -------- Robert Smyser, Manager, Computer Resource Laboratories School of Architecture and Planning, MIT smyser@athena.mit.edu ___ -=====- | | | | | | ======= ==M=I=T== ------------------------------ Date: Thu, 10 Oct 91 10:01:57 -0400 >From: Kevin_Haney@NIHCR31.BITNET Subject: Viruses and OS/2 (OS/2) Just to add a little to what Bill Arnold posted concerning the question on whether DOS viruses and antiviral programs will work under OS/2 2.0, most all scanning programs should work with no problem. DOS system monitor programs that require a device driver will most likely work under 2.0 unless they do something very abnormal. From what I have seen and heard about OS/2 2.0, it should allow you to specify device drivers that a DOS program needs, which are then started whenever the DOS program is invoked. Antivirus drivers will only be able to monitor activity for the single DOS program or session though, since it will be running in the virtual machine mode of the 386 or 486. Thus, you will have to specify the device driver in the configuration information for each of your DOS programs. I think you will also be able to specify DOS device drivers in the OS/2 CONFIG.SYS, and they will then be available to all DOS programs without having to set them up individually. I have done tests on the effects of DOS viruses on OS/2 1.x systems, and the situation there is bleak. As soon as I get the next OS/2 2.0 beta, I will be doing some more tests on the effects of DOS viruses, and will keep the digest posted. To mount the soapbox for a second, it is indeed unfortunate that some basic virus protection measures are not built into OS/2, which IBM bills as an "advanced" operating system, e.g., partition table and boot sector integrity tests and backup utilities, system file and .DLL self-checks, and even a full blown "integrity shell". Hopefully, OS/2 developers will recognize the need to include such functions in the operating system itself and include them in future OS/2 versions. Until then, OS/2 systems are generally as vulnerable to virus infections as is any DOS system. (And we're supposed to use OS/2 for our mission-critical applications???) Kevin Haney ------------------------------ Date: 10 Oct 91 09:56:35 -0500 >From: "Don Medal" Subject: Stoned on 3.5" disks / "1590" virus (PC) I am new to this forum, please forgive if these subjects have just been covered. We are currently infected with an apparently new strain of the "Stoned" virus. We ran tests last year and determined that the Stoned virus we had at that time could not infect our 3.5" disks, suddenly we are overwhelmed by Stoned on our 3.5" machines also. Q#1: Is this a new strain??? Q#2: Any info on the "1590" virus? I can't find it in the McAffee list. Thanks! Don Medal dmedal@mail.crk.umn.edu Computing Services U of Minnesota Crookston ------------------------------ Date: 10 Oct 91 10:27:52 -0500 >From: VIRUS-L@mail.crk.umn.edu Subject: disable ctrl/break? (PC) Our lab machines run a virus check at boot and are SUPPOSED to hang if a virus is found. Unfortunately, our instructors have been saving time by teaching the students to press Ctrl/Break at boot in order to skip the test. The result is of course that the lab machines are all infected. Can this (ctrl/break) be disabled? ------------------------------ Date: Thu, 10 Oct 91 11:40:00 -0400 >From: Garb@DOCKMASTER.NCSC.MIL Subject: False Alarm (PC) I recently received a few diskettes which were reported to be infested with the "Happy New Year" virus. I scanned the diskettes with VIRUSCAN (McAfee), VIRUSAFE (Eliashim), Turbo Anti-Virus (Carmel), Norton Anti-Virus, and Central Point Anti-Virus. All reported the diskettes to be free of any viruses. The product that gave the false alarm is called V-BUSTER, published by Looi Hoong Thoong in Penang, Malaysia. It should not be confused with VIRUS-BUSTER, distributed by Leprechaun Software in Georgia. While a false alarm may seem to be a harmless event, it can have serious consequences. It can cause the user to delete files or reformat disks unnecessarily. Workstations may be taken offline from networks or whole networks shut down. At the very least, access to computer resources are denied while the user attempts to find and deal with the phantom virus. Most importantly, from a vendor's perspective, the reputation and reliability of the provider of the suspect media are called into question until the true situation is known. All vendors of virus detection products should take as much care in ensuring that false positives do not occur as they take in ensuring that actual viruses are reported. Gary Garb Corporate Computer Security Officer Unisys Corporation ------------------------------ Date: 10 Oct 91 11:32:00 -0500 >From: "William Walker" Subject: Hardware and Software; Re: Forget Turing... >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) > This is the first time I have seen a reply appear in the same posting > as the original - a dose of Asimov's endochronic somethingoranother I > guess. I have seen postings and their replies in the same issue of VIRUS-L before. How does it happen? (Ken?) > My real disagreement is this argument that "computers are made to run > programs, viruses are programs, therefore computers cannot tell > viruses from programs." This is wrong. Period. > The same logic would state that "saddles fit horses, saddles also fit > tigers, therefore horses cannot be distingushed from tigers." No, the same logic would state that "saddles fit horses, saddles also fit tigers, therefore saddles cannot tell tigers from horses." The statement that the argument is wrong is itself wrong. If computers CAN tell viri from [other] programs, then why are viri so widespread? Now, computers CAN be made to recognize virus-like behavior, but since viri are a subset of programs, it is possible for a non-viral program to exhibit virus-like behavior. Take SideKick, for example. It goes resident, it intercepts interrupts (and tinkers with them in real time), and writes to disk (Notepad, which I think can be coerced into even reading and writing an executable). DIET, Padgett's DiskSecure, and other programs also exhibit some virus-like behavior. The problem is finding some way to allow the known non-viral programs which exhibit virus-like behavior to operate, while preventing other programs which exhibit virus-like behavior (viri) from operating. About the only way is to have a system which includes a series of permissions and has trusted paths for assigning and enforcing these permissions. About the only way to implement such a system is: >From: "Mark Aitchison, U of Canty; Physics" > (1) "Smart" software that lets you write to some files, but not others > (2) "Smart" hardware [...] that stops people by-passing (1). > ... > The obvious answer is that a COMBINATION of hardware and software is > needed; the hardware to stop people getting around the software.... The hardware and software will have to be designed keeping the trusted path in mind. Perhaps unfortunately, they would have to be designed together to work together, so retrofitting existing machines may be difficult. Also, the security features would have to work continuously and independent of the user. Jay's "Virus-Proof" machine and Fred's "Virus-Resistant" machine may work okay, but they are user-vicious in that the user plays a major active part in maintaining the security, and the protection can be disabled via the "big red" or "small colorless" switch. Padgett's machine is better in that a lot of the security is now transparent to the user, but there is still no trusted path, and a virus (or a Trojan horse) can still subvert the system (how well does your machine hold up against 12 Tricks?). It is mandatory that a system's security be independent of and transparent to the user to be successful. From what I've seen, the vast majority of viri have been spread by people who are either computer- illiterate (don't know what they're doing), are as security-conscious as a biscuit (are oblivious to what they're doing), or just lazy (don't want to do anything more than they really have to). These people cannot or will not use any security features if these features require them to have an active role. Of course, this brings up two points which have been brought up before by others on this list: implementation and user education. For any security solution to be effective, it will have to be implemented across a major portion of the installed base of machines. Also, users would have to be trained in basic security measures as well as use of the new features of their machine. But that's a completely different matter. On to the next thing... - - - - - - - - - - >From: spaf@cs.purdue.edu (Gene Spafford) > What Cohen proved in his thesis was that a program to exactly detect > all viruses on a Turing machine was an intractable problem. That is, > you cannot write a program that will run on a Turing machine and will > print "infected/not infected" with 100% accuracy for any arbitrary > program on that same Turing machine. > ... #2. The proof shows that you cannot build a perfect detector on a > Turing machine. However, the proof depends on the fact that the > theoretical Turing machine has unbounded space for programs/data, and > has unbounded time to run. If you bound either, the proof no longer > holds. For example, if memory consists of only 3 words, you can > easily write a detector that knows if there is a virus present or not, > and it runs in finite time. > Now, consider that real machines have bounded time and space for > execution of programs. The intractability result DOES NOT hold on > these machines. The problem may be exponential in nature, or worse, > but it is not intractable. The halting problem does not exist on > machines with finite memory and/or execution time bounds. This sounds similar to a problem I studied in Computability, which asked if it was possible to write a program in some language to detect an infinite loop in ANY program of the same language. The proof showed that it was impossible to do so. While I admit that I'm not up to speed on my formal proofs, it seems to me that it would also be impossible (or nearly so) to write a program (NOT a signature scanner) to detect ANY virus, known, unknown, or yet to be written, without error. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | Arnold Engineering Development Center | AEDC -- Home of the "Chicken Gun" M.S. 120 | Arnold Air Force Base, TN 37389-9998 | ------------------------------ Date: Thu, 10 Oct 91 09:37:14 -0700 >From: a_rubin@dsg4.dse.beckman.com Subject: Re: Forget Turing... spaf@cs.purdue.edu (Gene Spafford) writes: >Without going into all the gory details.... >What Cohen proved in his thesis was that a program to exactly detect >all viruses on a Turing machine was an intractable problem. That is, >you cannot write a program that will run on a Turing machine and will >print "infected/not infected" with 100% accuracy for any arbitrary >program on that same Turing machine. What is a virus (in Cohen's thesis). Further comments depend on a good answer to this, but.... I don't think I'm originating this, but the way _I_ would show that a program to check whether a program infects a system is impossible, (assuming the system is sufficiently complex that infection _is_ possible) is by assuming such a program P exists. Write a program P' which does the following: apply P to P'. Infect if and only if P reports P' clean. I would have to see Cohen's thesis to see if it is only a more sophisticated version of that. Is it available by ftp? >... However... >#3. A perfect detector on a Turing machine is intractable. However, >an imperfect program is possible. That is, you may write a program >that makes either or both Type I and Type II errors in its >classification scheme (Type I in this context would be labeling an >uninfected program as infected, and Type II would be labeling an >infected program as clean). Building a program that makes only Type I >errors might be possible, and could be completely appropriate for our >needs. A very good point. - -- 2165888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal) a_rubin@dsg4.dse.beckman.com (work) My opinions are my own, and do not represent those of my employer. ------------------------------ Date: Thu, 10 Oct 91 17:34:06 +0000 >From: umbuhr03@ccu.umanitoba.ca (Kevin Buhr) Subject: Psychology of virus writing (was HW not a virus solution) PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) writes: >Talk about the "psychology" of virus writing before leads me to think >that all that is required is for virus writers to be faced with a >pretty slim chance of success (and a good chance of being caught), for >virus writing to suddenly go out of fashion. On the contrary, I would suggest that the true virus "artists" would be quite stimulated by the thought of working around a particularly ingenious detection technique. The slim chance of success would drive them to succeed. Consider the two clowns in Bulgaria who are foiling detection methods that haven't even been implemented yet! Of course, the relatively common phenomenon of virus "planting", by which I mean the practice of placing someone else's virus on a target machine to cause trouble, might very well go out of fashion. After all, if new virus detectors can keep pace with new viruses, then there is only a slim "infection window" which would generally be available only to the virus writer. Kevin Buhr ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 187] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253