VIRUS-L Digest Monday, 29 Jul 1991 Volume 4 : Issue 132 Today's Topics: Re: F-PROT configuration question (PC) Re: F-PROT & DOS 5.0 (PC) CARO and EICAR Re: viruses in the press Re: F-PROT & DOS 5.0 (PC) Re: Index of Known Malware: 998 viruses/trojans Re: F-PROT & DOS 5.0 (PC) ScanV57 & Stoned alarm (PC) Re: Self-scanning executables (PC) Dark Avenger (PC) Re: Virus Scan V57 and V77. (PC) Index of Known Malware: 998 viruses/trojans Re: HighMemory(even longer & more technical) (PC) Re: Philosophy, comments & Re: longer and technicaller Re: High Memory (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 Jul 91 08:01:08 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: F-PROT configuration question (PC) The configuration of F-PROT will change a bit with the soon-to-be released version 2.0. Instead of loading F-DRIVER.SYS from CONFIG.SYS and running F-NET.EXE after the network software is loaded, the programs have now been combined into one: VIRSTOP.EXE This program is loaded from AUTOEXEC.BAT, so... (for) On a network, a single copy can now be kept on the server, instead of having to update each individual machine, when a new version is released (against) F-DRIVER.SYS was more-or-less immune to infection, being a device driver, and it could prevent an infected COMMAND.COM from running. VIRSTOP.EXE may become infected, if it is run after an infected program. It performs a very good self-test, however, so it will even detect an infection by a sophisticated "stealth" virus, such as Frodo. I have just received a report of one strange conflict regarding F-DRIVER/F-NET. If run on a Novell network, with a certain version of Netware, and the user is running Windows, and either Excel or Word for Windows, and attempting to print to a laser printer, the output will become garbled. Switching to a copy of Netware, with a slightly different size and date, but the same version number solved the problem. I don't have an explanation, but I would very much like to hear from anyone else who encounters this problem. - -frisk ------------------------------ Date: 26 Jul 91 08:03:46 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: F-PROT & DOS 5.0 (PC) TEMNGT23@YSUB.YSU.EDU (Lou Anschuetz) writes: >Installed DOS5.0 on my machine last night (which works well imho), >but ran into a problem with F-PROT. If I attempted to leave the >F-PROT driver.sys in my config.sys file the machine would freeze >and complain that INT13 was modified (undoubtedly true). Has >anyone found a work-around for this? There are three possible solutions, one of which should work on your machine. 1) load F-DRIVER with DEVICEHIGH= 2) load F-DRIVER last in CONFIG.SYS 3) load F-DRIVER with DEVICE=F-DRIVER /NOINT (this undocumented switch disables the interrupt check). - -frisk ------------------------------ Date: Fri, 26 Jul 91 14:25:28 +0200 >From: frog@DGIHRZ01.BITNET Subject: CARO and EICAR In "Der Aarbote" 1991-04-19, a local newpaper, the founding of two anti-virus organizations was anounced. Here's a short excerpt from this article (the original text isn't as clumsy as my translation B-]): "To avoid unneccessary double work, leading virus experts in europe founded two international organizations: with CARO (Computer Antivirus Research Organization), the scientists want to coordinate their anti-virus-work; EICAR (European Institute for Computer Anti- Virus Research) is the organization of the commercial software developpers. CARO and EICAR will be located in Brussels. The most important goal is to develop a common language to describe computer viruses and to inform each other about new viruses". I never read something about CARO and EICAR on this list. Does anyone have some information about this two organizations or other international efforts to fight computer viruses? Christian Treber `___' /- -\ "Big brother is writing you!" \ | / Frog@DGIHRZ01.bitnet \-/ Christian Treber, FRG, FH Fulda, FB Telecommunications ------------------------------ Date: Fri, 26 Jul 91 02:27:40 -0500 >From: Paul Coen Subject: Re: viruses in the press Well, all I can say is that in a document that I wrote for the Drew University Academic Computer Center (and I think that the department that hands out freshman computers included it in their fresman handbook) started out by saying that you should forget what you've heard about viruses from the press, since too much of it is inaccurate. Okay, we can't expect the press to be perfect. We can expect them to at least make an effort. And in fields that I'm pretty well-versed (computers, cultural & physical anthropology, sociology, etc.), they're horribly inaccurate. People I've talked to in other fields have complained about reporting in their areas -- incorrect in ways that shouldn't have happened if the person either writing or editing the story had even taken an intro course in that field or a related field. I'd say that asking "people in the know" -- establishing contacts in various fields would help, except that often times newspapers don't even quote correctly, or attribute the quotes to the correct people. An example: during the Morris worm incident, a reporter from the Newark Star-Ledger in NJ called the Academic Computer Center, and talked to my boss, his boss, and a student programmer about it. We all knew about it, because we'd read everything that had come in over the net about it, so we told her what we knew. My boss told her that it wasn't a virus. In her story, she called it a virus. She then went on to not use quotes from my boss (Neil) but from his boss (Bill) but proceeded to attribute the quote to Neil. Moral of the story: the press makes mistakes. Okay, again, they're human. But if "journalists" can't report properly or put a reasonable perpective on an event or topic, shouldn't papers and news organizations be hiring more people who understand the technology AND can communicate? There are a few of us out here. There are quite a few on this list :). If you're a journalism student, and want to pick a bone with me, go ahead. Just don't EVER write a factually incorrect story about computers or anthropology in a paper I read :). - ---------- Paul Coen -- pcoen@drew.edu, pcoen@drew.bitnet, paulcn@idsvax.ids.com Disclaimer: These ARE my opinions -- I've been taking the summer off. ------------------------------ Date: 26 Jul 91 11:41:31 +0000 >From: M I Clarkson Subject: Re: F-PROT & DOS 5.0 (PC) I found problems with F-PROT's F-DRIVER.SYS and DOS 5.0 too. The cause of the problem on my machine seems to have been HIMEM.SYS. It modifies INT 13, doesn't it? Anyway, try moving F-DRIVER.SYS to just after HIMEM.SYS in your CONFIG.SYS file. My machine now boots OK, and traps F-TEST OK. Mike. ------------------------------ Date: 26 Jul 91 21:09:49 +0000 >From: sytang@lamar.ColoState.EDU (Shoou-yu tang) Subject: Re: Index of Known Malware: 998 viruses/trojans brunnstein@rz.informatik.uni-hamburg.dbp.de (Klaus Brunnstein) writes: >VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus >Catalog: Index.791; all entries classified up to now) are now available from >FTP: > Our FTP server: ftp.rz.informatik.uni-hamburg.de Does anyone has the Internet IP # for this site? Our system does not have a table link to this address and local name server can't find it too. Thanks Tang sytang@lamar.colostate.edu [Ed. See follow-up below.] ------------------------------ Date: Fri, 26 Jul 91 14:01:37 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Re: F-PROT & DOS 5.0 (PC) TEMNGT23@YSUB.YSU.EDU (Lou Anschuetz) writes: > Installed DOS5.0 on my machine last night (which works well imho), > but ran into a problem with F-PROT. If I attempted to leave the > F-PROT driver.sys in my config.sys file the machine would freeze > and complain that INT13 was modified (undoubtedly true). Has > anyone found a work-around for this? I was able to find workarounds on two different machines. On one, booting off the A: drive, with a normal CONFIG.SYS, fixed the problem. On a PS/2, this did not work. I was able to get it too work by invoking F-DRIVER.SYS after the HIMEM.SYS. Other ideas about "loading high" did not seem to work in this case. Here is the relavent section of the CONFIG.SYS file: rem devicehigh=c:\vir\fpr\f-driver.sys **hangs rem device=c:\vir\fpr\f-driver.sys **hangs rem device=c:\vir\fpr\f-driver.sys /noint **works break=on FILES=50 BUFFERS=32 LASTDRIVE=w FCBS=16,8 shell=c:\command.com c:\ /p /e:1024 rem device=c:\vir\fpr\f-driver.sys **hangs device=C:\dos\himem.sys device=c:\vir\fpr\f-driver.sys rem device=c:\dos\emm386.exe noems x=d000-d3ff devicehigh=c:\dos\setver.exe devicehigh=c:\dos\smartdrv.sys 2048 1024 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ Date: Sat, 27 Jul 91 09:40:14 -0400 >From: Tom Young Subject: ScanV57 & Stoned alarm (PC) Andrew Brennan of Drexel writes: > I've an interesting problem at the center I am working for. > Apparently, SCAN stops checking memory for Stoned after V57. We > have V57 (in normal use) and can locate Stoned in memory, but it > is not found on the disks - hard disks or otherwise. After we > reset the machine (booting from the hard disk), we have Stoned > in memory again - not located on the hard disk. > ... Are you perchance running AppleShare PC? I seem to remember deciding that the combination of ScanV57 and AppleShare 2.0 (but not 2.1?) yielded a false positive for Stoned in memory. This would also explain why you don't get an alarm when booting from a clean diskette (AShare stuff not loaded). I never posted this tidbit since one or both of the above versions of these products were outdated at the time of my discovery :-). Tom Young, Cornell Information Technologies, Workstation Systems Services Bitnet: XMU@CORNELLA Internet: xmu@cornella.cit.cornell.edu ------------------------------ Date: 27 Jul 91 14:39:55 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Self-scanning executables (PC) 76336.3114@CompuServe.COM (Kevin Dean) writes: >Cracking the algorithm is not a trivial task: a virus has one chance >in four billion (2^32) of successfully infecting a program or, if it >decides to fool the algorithm by changing the stored CRC, would lock >up a 386 for hours bordering on days to find and change it. Well, this is of just as much use as a simple checksumming algorithm - it is very unlikely that a virus will attempt to atteck the encryption algorithm itself - trying to "fake" the CRC. A much more effective method is to use "stealth" techniques. If the implementation of this algorithm detects infection by Frodo (4096), it is worth considering... - -frisk ------------------------------ Date: 28 Jul 91 02:05:34 +0000 >From: sine@brahms.udel.edu (sine@sun.acs.udel.edu) Subject: Dark Avenger (PC) Hello, I just discovered that my hard drive has been affected by the Dark Avenger Virus. I dutifully downloaded a few of the scanners and disinfectants from wuarchives. With the McAfee software (7.6v80), I was told the the DA was there and then I used clean to remove it. When I then run scan, it tells me all is well. So, I power down and reboot from my hard drive (having used a clean floppy before). Now scan tells me the the DA is present in memory again. Am I doing something wrong? missing a step? Thanks for any help you can give. Pat - -- Pat Sine sine@brahms.udel.edu Instructional Technology Willard Hall Ed. Bldg., University of Delaware, Newark, DE 19716 ------------------------------ Date: Sun, 28 Jul 91 04:40:20 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: Virus Scan V57 and V77. (PC) BRENNAAA@DUVM.OCS.DREXEL.EDU (Andrew Brennan) writes: > I've an interesting problem at the center I am working for. > Apparently, SCAN stops checking memory for Stoned after V57. We > have V57 (in normal use) and can locate Stoned in memory, but it > is not found on the disks - hard disks or otherwise. After we > reset the machine (booting from the hard disk), we have Stoned > in memory again - not located on the hard disk. > My immediate assumption was that it was a strain of Stoned > that was not locatable by the old version - but the basic shape > of Stoned was locatable in the memory of the machine. Upon a > boot from a clean disk, no Stoned anywhere. I dug out a copy of > V77 (assuming/hoping that it would locate the virus on the disk) > only to find that V77 no longer memory-scans for Stoned. I also > found that V77 was unable to find Stoned on the same harddisk. > We don't have V80 and I was unable to retrieve a copy via the > Internet as there was/is some problem out there that was not > allowing access outside this site - some server was down ... > We tried (a suggestion from an outside source) optimizing the > hard disk - to remove any phantom viral activities(?) V57 still > finds Stoned in memory - not on the disk. V77 doesn't look for > Stoned in the memory _and_ doesn't find it on the disk. I will > be retrieving a copy of V80 ASAP, but I don't know exactly what > to think in this situation ... To tell VIRUSCAN (also known as SCAN) to check memory for the Stoned virus, add the "/M" parameter to the command line, i.e., SCAN C: /M (and press Enter) It could also be that you are having a false alarm with some other program in memory, or that the disk optimizing program didn't erase the "ghost" left over after disinfection. You may wish to look at the partition table of the disk with a sector editor to determine if the virus is there. This would help rule out a false alarm. Regards, Aryeh Goretsky McAfee Associates Technical Support - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | Santa Clara, California | BBS (408) 988-4004 | aryehg@darkside.com(personal) 95054-0253 USA | v.32 (408) 988-5190 | ViruScan/CleanUp/VShield | HST (408) 988-5138 | CompuServe: 76702,1714 ------------------------------ Date: Sat, 27 Jul 91 22:14:02 +0700 >From: swimmer@stage.hanse.de (Morton Swimmer) Subject: Index of Known Malware: 998 viruses/trojans brunnstein@rz.informatik.uni-hamburg.dbp.de (Klaus Brunnstein) writes: > Catalog: Index.791; all entries classified up to now) are now available from > FTP: > Our FTP server: ftp.rz.informatik.uni-hamburg.de > Login anonymous > ID as you wish (preferably your name) > dir: directory of available information > cd pub/virus: VTCs documents Sorry, the address should have read: ftp.informatik.uni-hamburg.de As the directory's moderator, I would ask everyone to first look for the information at a site nearest you. We are very far off the internet and suffer from a low load line (9600 BAUD) that is also used for other things. Cheers, Morton [Ed. The DNS-registered IP numbers for this site are: 134.100.4.42 and 188.1.20.32.] .............................................................................. .morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: +49 40 4910247. .internet: swimmer@stage.hanse.de or swimmer@rzsun1.informatik.uni-hamburg.de. ..............to leave only footprints, and take only memories................ ------------------------------ Date: Mon, 29 Jul 91 16:25:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: HighMemory(even longer & more technical) (PC) rohrer@fnacp1.fnal.gov (Keith Rohrer) writes: > One thing that I will agree that is if nothing is loaded high, it isn't > a virus, especially if you stopped things from loading high by axeing > the memory manager from your CONFIG.SYS. It is possible for a virus (admittedly, a pretty large virus) to be loaded above A0000 even without one of the memory managers you mentioned, but it does require certain hardware to be present. The obvious way is to provide its own control of the 386 or Neat 286 chipset or even just the A20 line. But, since most people who buy such hardware are hardly likely to have it without using such software to get the best value out of it, such a virus is likely to conflict, and the system would crash. Also, a virus could try to live in the extra RAM on a vidoe card (the Hercules card has plenty), or the RAM on some network cards, etc... again, they would, in all probability, be overwritten as soon as you use some programs, but it is theoretically possible. There are ways of checking that the code is ROM rather than RAM which are easy to implement. I suggest that anyone tracing through memory for a code segment greater than C000 should also check that it points to ROM by trying to write something to it (with interrupts turned off). The machine I'm using now, for instance, has at least two chunks of code up there grabbing the int 13 vector in addition to the BIOS. Mark Aitchison. ------------------------------ Date: Mon, 29 Jul 91 16:54:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Philosophy, comments & Re: longer and technicaller johnf@apollo.hp.com (John Francis) writes: > BUT - on 386 or better systems, I can write a "Virtual Machine" emulator I was hoping nobody would mention that possibility. It is a risk saying too much, in case virus writers get ideas, but also a risk in not alerting people to the possibility (e.g. I wonder if I should *really* have mentioned that it is possible to get a virus from just listing files in a directory?). Hopefully, that and the present idea won't be too successful for virus writers, because they need a good number of receptive systems to spread effectively. For anyone worring about viruses taking advantage of 386 features, here are a few thoughts to balance it with... (1) Think of the size of the virus, what difference it would make to files or disks it tries to infect - surely obvious even to uneducated users. (2) Most people with a 386 will now be using MS- or DR-DOS 5 (or whatever) to take adavantage of the hardware - such software at present might not be smart enough to say "hey! there's a virus here already" but will probably crash. (3) there are few ways of detecting it - especially when you know information about the computer from the time it was virus-free. For one thing, exact timings of some operations would be a big clue. (4) if Microsoft, Digital Reasearch and others have any sense, THEY will use the hardware to beat the viruses, instead of the other way around. Whoever - virus writers or O/S writers, take control first and best, will win - or at least make it extremely difficult for the opposition. (5) I've run a checking program on a Sparc emulation of an AT, and noticed the difference (I didn't even write the program with that system in mind) - any virtual machine running under a 386 would be even easier to detect, given the speed considerations - i.e. a 386 cannot emulate a 386 of the same clock speed without making the extra time in hardware traps, etc obvious). I said a long time ago that boot sector viruses are essentially doomed; the ability to detect and stop* them will always be greater than file viruses (given PC's of today and the near future). I may have sounded very pessimistic about whether file viruses or anti-virus measures will win in the long run (mainly because there are so many programs that do just about the same things as a virus) - but really good software in control of a 386 or better gives me, at least, a lot of hope. Now come on, MS & DR guys! write it before the virus writers use the loopholes, please! Mark Aitchison. * if you have more questions about a-v software beating *any* boot sector virus, feel free to e-mail me. ------------------------------ Date: Fri, 26 Jul 91 12:39:21 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Re: High Memory (PC) >From: rohrer@fnacp1.fnal.gov (Keith Rohrer) >From: "William Walker C60223 x4570" Both writers make valid points concerning the "high memory areas" available for DOS on modern (80286-up) platforms and the potential for viral activity to use these areas. However, integrity management is possible, even in this specialized environment. The key is that at BIOS load time (before DOS), all Intel iapx80X86 processors are running in real mode (i.e. brain-dead as a 8086). There should be no "high" or "extended" or "expanded" RAM available as yet and all interrupts "should" be located in the segment range C000h-F000h. This is easily authenticated with a fast pass through the interrupt table since the segment prefix is in each vector. (the video buffer A000h-BFFFh) is a data storage area and should not have interrupts pointing there). While QEMM and others use the B000h-BFFFh area in some cases for high menory, this does not occur until after DOS & the memory manager loads. The only exception to this that I know of is certain expanded memory boards designed for XT class machines that incorporate the LIM page frame and use onboard ROM extenders for access. Since everything in this region is, in theory, ROM and unwritable (easily checked if necessary), verification is simple. - --------------------------------------------------------------- ANFSCD: >From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) > ... a response was posted to another comment that you must boot > cold from an infected floppy before trust is possible even if a ^^^^^^^^ > clean Int 13 (disk access) path is known. EEP! er, ah, that is...oops. Mr. Walker is of course entirely correct, that should be "boot cold from an uninfected, write protected" floppy. Padgett ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 132] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253