VIRUS-L Digest Monday, 2 Dec 1991 Volume 4 : Issue 228 Today's Topics: vaccine for STONED on boot disks? (PC) MD5 better than CRC! RE: Virus Proof Machine Response Re: DIR-2 found in USA (PC) infection (PC) In-Re: Radai re: Murray re: Radai re: Frisk, re: Washburn Re: Washburn Re: Radai re: Frisk, re: Washburn Re: Telefonica (PC) Removing Den Zuk (PC) More Virus Reports From The Katt's PC Week Column (PC) System checking F-PROT Now On _Network_World_'s BBS (PC) Need Jerusalem info again (PC) 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: 26 Nov 91 11:32:18 -0500 >From: "Don Medal" Subject: vaccine for STONED on boot disks? (PC) I am happily in possession of INNOC which says it will innoculate against STONED, but with one tiny unhappy exception: it won't protect DOS bootable disks. We are constantly being infected with Stoned from a pool of student disks and would very much like to find a way to vaccinate against STONED for bootable disks, ideally to include hard drives, but at LEAST floppies. Can this be done? Is it theoretically impossible? Don Medal medal@mail.crk.umn.edu U of Minnesota Crookston dmedal@UMNACVX.BITNET Computing Services Crookston, MN 56716 ------------------------------ Date: Tue, 26 Nov 91 11:51:19 -0600 >From: Jeff Pipkins Subject: MD5 better than CRC! bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >Version 82 of McAfee's program SCAN has been trojanized in Bulgaria. >The executable file has been modified to include a new virus and the >archive, modified in such a way has been uploaded to a Bulgarian BBS. > >I have received reports from several places that breaking PKZIP's >authentification code is relatively easy. It also seems that the >Bulgarian hackers have found an authomated way to do it. Anyway, all >SCAN trojanizations about which I know, have the string displayed >about changed in some ways. So, it seems to be a good idea to always >check for it, not only for the presence of the -AV info... > >The current version of the package uses three levels of protection. > - The ZIP authentification code > - The VALIDATE info in the docs > - The self-checking that each of the executables perform >All of these have proven to be unnecessary sophisticated and >completely useless against a dedicated attack. It -IS- possible (and >even relatively easy) to devise an authentification scheme, based on >public-key digital signatures, which -will- work. The only problems >might be legal ones (the RSA public-key cryptosystem which I have in >mind is patented, but I guess that a large company like McAfee >Associates can afford the license, in order to provide security for >their users). Have a look at Dr. Dobb's Journal, Sept 1991, Vol 16, issue 9; there's an article called, "One-Way Hash Functions" by Bruce Schneier. It lists code for the MD5 ("message digest") algorithm from the RSA folks. Think of this algorithm as being similar to a 128-bit CRC, except that it is pragmatically impossible to modify the message and get the same key. Licensing for the algorithm is particularly paletable, and basically just requires giving credit where credit is certainly due. You can get the listing from SIMTEL, it is in PD:DDJ9109.ZIP. - ------------------------------------------------------------------- [sig #20] Jeff D. Pipkins | "A consensus means that everyone NOTE: I am | agrees to say collectively what no NOT authorized to represent my employer. | one believes individually" --Abba Use my opinions ONLY at your OWN risk. | Eban ------------------------------ Date: Wed, 27 Nov 91 12:23:47 +0000 >From: Chris Stops Subject: RE: Virus Proof Machine Response In answer to some of Vesselin's comments on my last posting... On the subject of creating and writing files... >> I think you must also forbid executables being turned into 'data' >> files. If not, for example, a virus could turn an executable into a >> 'data' file, read the data file, and then CREATE a new copy of the >> executable which includes the virus. >It can CREATE it, OK, but it won't be able to WRITE it on the disk... >This will cause problems on compilation... >[Lots of stuff deleted....] >Note that Creating a file is not enough to put code in it. You have >also to Write to the created file... Maybe I wasn't clear enough on what I meant by CREATE & WRITE... 1) When I say 'CREATE', I mean (in DOS terms) to create the file (e.g. function 3Ch) followed by writing the data (e.g. function 40H). 2) When I only say 'WRITE', I mean (in DOS terms) to open an exisiting file for write access (e.g. function 3Dh) followed by writing the data (e.g. function 40H). Because the OS knows how the file was opened, it can distinguish between writing while creating a new executable (as in a compiler) and writing to an existing executable (as in a virus). So there is no problem. On the subject of source code infectors... >> Yes, I was aware of this. In reply, anything in source code or ASCII >> form should be easy to spot in an editor, or the file dates will be >"Easy to spot" is easy to say... Will you be able to spot [paragraph >deleted]... OK, I agree it may be difficult to spot a source virus if it is really clever about how it patches itself in. But it will be much easier to spot than a good (or do I mean bad?) DOS executable virus. Also, remember that there can be no stealth viruses to conceal changes. So "Easy to spot" could include "Easy to spot by a simple source code checksummer". On what I meant by 'Virus Proof'... Another point that has come from our discussion is that the name 'Virus Proof Machine' may have mislead some people. What I meant was a... 'practical PC type machine implementable with existing '386 technology, proofed against all the usual and most effective DOS attack paths like boot sector infectors, resident viruses and code attaching to exisiting executables, but admittedly leaving a few minor holes such as source code infectors and interpreted code infectors'. ...but that's too long for a 'Subject:' header, so I shortened it. But as I expliained in my last posting, I can be up to half a month behind you lot 'cos of where I get the digests from in the UK; It seems that as I started this thread, some other people started theoretically discussing TOTALLY VIRUS PROOFED machines, so in that context, my title was a little too shortened. On agent 007, (licence to kill)... >>Oooops, now I'm starting to sound like a baddie from a James Bond film! >No, you are sounding like... [several lines deleted] Curses! I always wanted to meet 007! Chris. ------------------------------ Date: Wed, 27 Nov 91 07:56:41 -0500 >From: "Bonnie Scollon" Subject: Re: DIR-2 found in USA (PC) In early October we received an update for Vi-Spy from RG Software that included a program to remove DIR-2. I haven't tested it since we have not been struck with the virus. Bonnie Scollon Oakland Community College ------------------------------ Date: Tue, 26 Nov 91 15:25:54 -0400 >From: Jim Subject: infection (PC) We have a PC lab of 30 units which has become infected with a virus (STONED). We are thinking of having a clinic to rid our systems and students disks of the infection. Does anyone have any experience in solving this problem and post treatment procedures to ensure that reinfection does not occur ? Any suggestions would be appreciated. James B. O'Brien (Jim) St. Lawrence College, Cornwall Canada ------------------------------ Date: 27 Nov 91 11:08:00 -0400 >From: "zmudzinski, thomas" Subject: In-Re: Radai re: Murray re: Radai re: Frisk, re: Washburn In VIRUS-L #226, Bill Murray replied to Y. Radai's earlier posting: >>> To assert otherwise is hubris. We would do well to remember how the >>> god's punished Pandora. Y. Radai responded in V-L #227: >> Funny, I would have sworn that to assert otherwise was arrogance. And >> here it turns out to be hubris! Just goes to show that you learn >> something new every day .... * AHEM * From the Random House College Dictionary, Revised Edition: > HU-BRIS (hyoo'bris, hoo'-). n. excessive pride or self- > confidence; arrogance. Also, hybris. [< Gk: insolence] > -- hu-bris'tic, adj. As they used to say, "use a new word three times today and it will be yours forever". Let's can this part of the argument and get on with the main issue: Should we do business with someone who has inflicted a virus on the community? I say no (and will limit myself to two examples:) (1) "Shunning" as practiced by various Pennsylvania Dutch sects. (2) The Israeli Government's policy of not dealing with kidnapers. In each case, it may be hard on the innocents involved, but the results are deemed positive, i.e., the persons making and keeping to the policy are perceived as "winning" by their community. (Otherwise there would soon be new policies in both communities.) ----- By the way, Bill, at least in my Bullfinch's, the god's punished Pandora for her curiosity, not her hubris. Tom Zmudzinski ZmudzinskiT @ IMO-UVAX.DCA.MIL Defense Information Systems Agency, "DISSS-ah" (703) 285-5459 "The pen is the tongue of the mind" -- Cervantes ... And the keyboard is a bullhorn -- me ------------------------------ Date: Wed, 27 Nov 91 09:48:54 -0700 >From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Re: Washburn One historical note seems to be missing, so far, in the Frisk - Radai - Murray - Radai dialogue (flame-throwing contest?) on the Washburn virus (whatever that is) and appropriate punishment for a virus writer. I don't know Washburn, or anything about when he released a virus. My comments here are more general. We should not forget how rapidly values, mores, and laws have evolved, relative to malicious computer code. The first self-replicating programs were only written a decade ago. In the mid-eighties the notion that computer viruses might be harmful was rather new, and was not commonly held. Today we all agree that all viruses are harmful, and our countries are beginning to institute laws to that effect. But an individual's values will necessarily have evolved as well. An individual may have made a mistake in the past, based on earlier, less developed value sets, yet today have fully embraced the currently acceptible code of behavior. That individual is in a different category than one who is writing viruses today, in the face of the norms, values and laws in place today. This principle is fundamental to the development of societies. Only a little over a hundred years ago, slavery was accepted in the USA. Today Americans will occasionally refuse to elect a politician who is blatently racist, even in a State like Louisiana. The difference is that the people of the United States have had generations to work on that value issue, whereas the problem of malicious code has come upon us very quickly. I think we should keep in mind the time frame of the evolution of our collective values, from "viruses as research entities" to the current understanding of "all viruses as harmful", when we judge one another's activities. Today it would be unpardonalble to release a virus. Two years ago it would have been unpardonable. Six years ago, might it have been a grave error in judgement, based on undeveloped values, or was it unpardonable then, too? Of course the analogy with slavery breaks down: I think slavery was always unpardonable. But then I think it is unpardonable that a racist would be allowed to run for government today. (Even if he does pretend to have converted!) - -Tim ------------------------------------------------------------- Tim Martin * Soil Science * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: 29 Nov 91 18:21:26 +0000 >From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: Radai re: Frisk, re: Washburn I must agree with Bill Murray. Releasing *any* compuer virus is an unethical act that should be deplored by any responsible professional. Releasing a virus known to be (or suspected to be) harmful is a worse offense, but it does not excuse the release of so-called "harmless" viruses. Viruses use resources and spread to machines without the consent of the owner. This can be viewed as a form of trespass. Although the analogy is not perfect, it can be compared to trespass on my property - -- the fact that no damage is done does not make the trespass acceptable. Viruses last a very long time in the population, and cannot possibly take into account all the available software and hardware configurations that may exist now or in the future. We have already seen cases of viruses that appear "harmless" until a new disk architecture appears, or a new software package is released. We can *never* assume that a virus is harmless. Also, with the mutation of viruses, and viruses being altered by others into new strains, the introduction of a new virus can still lead to direct damage. By making the base virus available, a new potential for damage has been created. The indirect damage described by Bill is also a major concern -- each new virus destroys trust and makes the environment of computing that much more questionable. As the count of viruses continues to spiral upwards, it makes people more afraid of computing, and more likely to distrust computers. It also tends to push our lawmakers towards new (and usually ill-designed) laws and regulations that have a harmful effect on our profession and society. Intent to cause damage adds additional dishonor to the author, certainly. But lack of intent to cause damage does not absolve an individual of his act. Consider that the law distinguishes intent between manslaughter and murder (in many countries) -- the intent determines the punishment, but the basic act is still condemned as illegal and wrong. Too many evil things have been done by people who claim after the fact that "I didn't intend for that to happen." By now, we should be able to see through the fallacy of that defense when offered by virus authors. I argue that morality should be judged by act, not by result. This is a position taken by most modern philosophers, and is the basis for much of Western law and ethics. The ends do not justify the means. The presence or lack of damage does not determine the evil of the act - -- the release of the virus itself is the wrong involved. If you are interested, I expound further on this theme in "Are Computer Hacker Break-Ins Ever Ethical?" to appear in the January 1992 "Journal of Systems Software"; this is also available for anonymous ftp from cs.purdue.edu in ~ftp/pub/reports (see the README file there). If someone genetically-engineered a new biological bacterium that was highly contagious to humans, and he then dumped it into the municipal water supply, would you excuse the act if it appeared that the bacterium caused no immediate damage? The logic and ethics are the same -- it is merely a change of degree and venue. It is an invasive act without controls and without the permission of the affected individuals. It is unethical, and we should not tolerate nor condone it. - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 Internet: spaf@cs.purdue.edu phone: (317) 494-7825 ------------------------------ Date: Wed, 27 Nov 91 17:56:24 +0000 >From: cs_b152@ux.kingston.ac.uk Subject: Re: Telefonica (PC) Robert.Turner@brunel.ac.uk (Robert Turner) writes: |> We have recently been inundated with a new (to us) virus, called |> Telefonica (AKA Spanish Telecom, Anti-Tel). Before new software was |> acquired, this virus managed to run its' course on a few machines, and |> we have been left with some dead PCs. |> |> Does anyone have experience of this virus, and if so, can they tell me |> how to recover a totally corrupted hard disc. |> |> Also, is there any way of removing this virus safely from a floppy disc? |> Norton is erratic, and seems to wipe the contents of the disc two or |> three times more than saving the data. Scan (McAfee) recognises the |> virus but cannot remove it. We have been removing all files, |> re-formatting the disc, then replacing files, but there must be a more |> elegant method than this. A-Tel only affects the bootblock of floppies and the partition table of hard disks. I think the latest version of Clean-up should do it, or try FPROT2.01 To get rid of the virus from the HD boot from a clean floppy and assumming you've get DOS 5, type FDISK /MBR which will rebuild the partition table. I got the above hint from the nice chappies at McAfess Assoc. Cheers! Regards... Vlod Kalicun. Kingston Poly, Surrey, England. 3rd year Computer Science. ------------------------------ Date: Wed, 27 Nov 91 15:40:00 -0600 >From: tneuhaus@uwspmail.uwsp.edu Subject: Removing Den Zuk (PC) Trying to solve a boot sector virus problem. Some one brought in a disk which appears to be infected with a boot sector virus. The following message appears when trying to disinfect with F-Prot 2.01: Boot Sector: possibly a new variant of Den Zuk and Analyze reports: This boot sector contains code which seems to indicate a virus infection. Unfortunately, F-Prot 2.01 will not disinfect, at least when "disinfect/query" is set. I have not tried "delete" yet. McCaffee 84, reports similar but will not clean. I'm sending the disk to Fridrik Skulason to look at. In the mean time, does anyone have any ideas? I'm able to infect another disk by booting with the bad disk (shows 0 bytes on disk, no files listed with directory) which displays "non-system disk" and prompts for new disk. If you put in a new system disk and hit return, the PC boots fine, but after a scan with F-Prot 2.01, the disk is reported to be infected. Again, could not disinfect with either McCafee 84 or F-Prot 2.01. Thanks in advance! Tom ------------------------------------------------------------------- | Tom Neuhauser | tneuhaus@uwspmail.uwsp.edu | | Information Technology, LRC 26 | | | University of Wisconsin | | | Stevens Point, WI 54481 | "He who hesitates, waits..." | | 715-346-3058 | | ------------------------------------------------------------------- ------------------------------ Date: Wed, 27 Nov 91 16:22:00 -0700 >From: "Rich Travsky 3668 (307) 766-3663/3668" Subject: More Virus Reports From The Katt's PC Week Column (PC) Huh. The Katt's Column in the November 25th issue of PC Week has _two_ virus reports. I quote: ...Zinc Software's C++ class library was recently sent out on disks containing the Forms virus, which randomly destroys files. The company admits it knows about the virus but has no clue about how it got on the disks. and ...Virtual Reality Laboratories, which publishes a planetarium program called Distant Suns, recently mailed a recall letter stating that some of its 5 1/4 inch disks have a new virus (called Michelangelo) with a trigger date of March 6, 1992. It will be activated only if booted up from the floppy disk; Virtual Reality is providing free virus-elimination programs for their users... Is this news to anyone else? I'm not accustomed to getting virus reports in PC Week :) Gee, if all it takes to get the free thingie they offer for submitting tips is to send in a virus report, then I think the readers on this list could easily supply several items per week. Musta been a(nother) slow week at PC Week... Richard Travsky Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU University of Wyoming (307) 766 - 3663 / 3668 ------------------------------ Date: Wed, 27 Nov 91 16:11:36 -0800 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: System checking FUNGEN9.CVP 911127 System checking The measures described in the previous two columns will detect file infecting viral programs (within limits.) However, a very large class, or perhaps a number of sub-classes, of viral programs do not make any changes to program files on the disk. Boot sector infectors replace or move the "boot program" resident on almost every disk. Although these viri are extremely common, surprisingly few "change detectors" bother to make any check of this area at all. One reason may be that a number of computers make regular changes to the boot sector for various purposes. "Companion" viri, while they are associated with certain programs, do not make any changes to existing program files at all. Similar claims can be made for "system" viri, such as the DIR-II virus, which leaves the file intact, but changes the directory entry in order that the virus, which "officially" does not exist on the disk, gets called first. It is, therefore, necessary to check much more than the size and image of the individual program files on the disk in order to detect viral infections. The boot sector (and master/partition boot record) should be checked, although it is possible that a certain area should be excluded from checking in the case of certain computers. A check on the total number of programs, and names, should also be kept separate from the system directory. A copy of the directory and file allocation table should also be kept, especially in regard to program files. System memory, and the allocation of system interrupts, should also be checked. This is problematic during normal operations, as programs tend to use, and sometimes not fully release, areas of memory and interrupts as they work. Therefore, the best time to do such checking is at boot time, even before drivers and programs have loaded from the startup files. (DISKSECURE does this to great effect. So did F-PROT's F-DRIVER.SYS -- which led to unfortunate conflicts with MS-DOS 5.0. The security programmer's lot is not an easy one, with virus writers, legitimate programs and even operating systems continually finding new and "interesting" ways to do things.) It is also possible, however, and quite desirable, to take a "snapshot" of memory immediately after the startup sequence. This should be able to detect any changes made to programs involved in the boot sequence, as well as other changes. (It may also "catch" program traps which "redirect" a "warm" boot in order to avoid disk security devices.) copyright Robert M. Slade, 1991 FUNGEN9.CVP 911127 ============= Vancouver p1@arkham.wimsey.bc.ca | "If a train station Institute for Robert_Slade@mtsg.sfu.ca | is where a train Research into CyberStore | stops, what happens User (Datapac 3020 8530 1030)| at a workstation?" Security Canada V7K 2G6 | Frederick Wheeler ------------------------------ Date: Tue, 26 Nov 91 11:25:00 -0700 >From: "Rich Travsky 3668 (307) 766-3663/3668" Subject: F-PROT Now On _Network_World_'s BBS (PC) The November 18th issue of Network World reports they now have F-PROT available on their BBS. The number is 202-364-1304. Rich Travsky rtravsky@corral.uwyo.edu ------------------------------ Date: 26 Nov 91 17:09:29 -0400 >From: LARRY MATEO Subject: Need Jerusalem info again (PC) I few days ago I sent a request for information on the Jerusalem virus. Someone sent me a fantastic file with everything I needed. Unfortunately, due to my ignorance of mainframe printing, I deleted the file. I would appreciate it if that individual would please resend the info. Thank you. (I know what I'm doing now, so I won't make the same mistake twice. Perhaps another, but not the same). ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 228] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253