Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA19978; Mon, 27 Apr 92 20:34:05 +0200 Message-Id: <9204271834.AA19978@abacus> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8629; Mon, 27 Apr 92 14:24:01 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 8691; Mon, 27 Apr 92 14:23:38 EDT Date: Mon, 27 Apr 1992 14:10:06 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #95 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Monday, 27 Apr 1992 Volume 5 : Issue 95 Today's Topics: Increasing CBCS Security (PC) Re: Polymorphic listing, Stealth in memory (PC) Combatting tunnelling viruses (was Re: Increasing CBCS Security (PC) Misinfo detected - 2 (PC) Misinfo detected - 3 (PC) Re: Increasing CBCS Security (PC) Question about forms of the stoned virus (PC) F-PROT Cascade false alarm... (PC) New Myths #1: Infection during format (PC) New Myths #2: Boot viruses survive format (PC) Re: Bloody Virus (PC) Re: Windows viruses? (PC) Re: Write protecting with software (PC) Re: Viruses via MS Windows OLE? (PC) Re: Extensions (was: Viruses via MS Windows OLE?) (PC) QEMM "stealth" and Anti-Viral Products (PC) Authentication of resident Anti-Viral programs (PC) help!!! (Apple ][gs) Re: Biohazard symbol for computer viruses? A short commercial break (was Re: lies and damn lies) Check list Series avail for FTP? 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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) 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: Thu, 23 Apr 92 15:19:12 -0500 From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza A.) Subject: Increasing CBCS Security (PC) > energetic barrier (the "tunnelling effect"). If correctly implemented, >these techniques are able to bypass -any- monitoring program, and >therefore the monitoring programs (like FliShot+) are the weakest >line in the anti-virus defense (even weaker than the scanners). No matter how well implemented is the tunnelling effect, there is always a way to break-it (but as allways: at the expense of having your system overloaded and not being compatible with other programs). Miguel de Icaza Universidad Nacional Autonoma de Mexico miguel@roxanne.nuclecu.unam.mx - InterNet deica@unamvm1 - Bitnet ------------------------------ Date: Thu, 23 Apr 92 20:54:10 +0000 From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Re: Polymorphic listing, Stealth in memory (PC) Thus spake frisk@complex.is (Fridrik Skulason): >Sorry - V2P6 is a typical polymporphic virus...it is not necessary that >the encryption changes, only that the implementation of the encryption >changes - for example with the addition of "garbage" instructions in >between the actual instructions. Correct indeed. Try computing the number of permutations of the decryptor in one of the V2Px series. Certainly, under the curious US laws which allow algorithms to be patented (this is possible in the States, is it not?), all permutations of a V2Px decryptor would be covered by the same patent. But they certainly look very different. One glimpse with the brain and you'll spot V2Px at a mile off (ie: 1600m); for poor ole' DOS software, V2Px definitely are polymorphic! Paul Ducklin Somewhere near the middle of the City of Pretoria South Africa ------------------------------ Date: Thu, 23 Apr 92 15:48:29 -0500 From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza A.) Subject: Combatting tunnelling viruses (was Re: Increasing CBCS Security (PC) Mark Aitchison writes: > Instead of TSR's sitting on interrupts such as int 13, it is possible > to check the program as it is loaded. Okay, nothing new so far. But > what you can do is interpret (instead of execute) the first few > instructions. Because of the way that viruses infect, it is much and > At this stage, you're probably saying that a virus could be specially > built to waste lots of time at the start, until the TSR thinks the > code being executed must surely be out of any viral area, and stops > interpreting. But, to do so the virus would have to slow down the > execution of all programs, which should make them obvious to users. Or Two problems: - - When will you know you're done with the analysis? - - Have you ever run this on an interpreter?: mov al,0 mov cx,0ffffh cld a: stosb loop a I know this is not an optimized code, but you can find code like this everywhere (just browe a PKlited file or EXEpacked or LZEXEd or...), pretty much software today comes packed, with integrity checkers: then interpreting becomes quite slow. > instructions. Because of the way that viruses infect, it is much > easier for them to execute at the start of the program than the end. > During this stage, it is possible to watch for any illegal disk or > memory accesses. This could be done on any PC (8088 chip up), but the And if the program is something like Mirror? would you break it?, so let's face it: interpreting is slow (Have you seen Soft-PC on a 25Mhz Mac?) > fib about anything... the only sensible test they could do is timing, > and that would require access to one of the internal timers, which is > something the TSR would detect and could trigger a more thorough test > of the program. take a look to the Borland C++ Startup: it stores the current time in a variable called _StartTime (using Int 1ah): this will not work... Miguel de Icaza miguel@roxanne.nuclecu.unam.mx ------------------------------ Date: 23 Apr 92 18:29:12 -0400 From: "Tarkan Yetiser" Subject: Misinfo detected - 2 (PC) Hello Eric, >> Me previously > Eric > comb@sol.acs.unt.edu (Eric N. Lipscomb) >> The SPECIAL system is standard MS/PC DOS based PCs most people >>use. They are prepared using FDISK, and are not compressed or protected >>by an exotic security system. You seem to argue by the exception rather >> than the rule :-) > I must disagree with you on this point, Tarkan. More and more users in > the Intel world are using the items Vesselin mentioned and many > others. In fact, what you claim as a "standard" PC system is becoming > an endangered species. Okay. So there are more copressed disks, and PCs using DOS clones such as DR DOS and 4DOS instead of plain MS/PC DOS 3.0+ and non-compressed disks? Our surveys significantly differ from your perceptions of the current market status as far as "standard" PCs are concerned. My point was, however, VDS 2.0 specifically disclaims working on such systems. Taking a software package and attempting to make it work on a system where it is NOT claiming to be able to run was, in my opinion, is a little unwarranted. > (I love this part:) >>Sure, VDS is not for everyone. It sure is the >>strongest software solution available, maybe not as convenient as some >>other packages with flashy user interfaces. Not as expensive either :-) > How can your software package be the strongest software solution > available, yet not be for everyone? It seems to me that you may have a Why not? Define "strong". > very good package for a limited user base, but if it can't be run on > every system configuration that someone might use, it's not a really > viable package in the current market. I can (for example) user F-Prot, What is viable or not is arguable. We are content with the current market situation. :-)) > which works under every setup I've been able to throw at it, and I can > use it for FREE! As far as I can tell, because I haven't taken the > time to test it, your program may be just as effective as F-Prot, yet > you imply it's better because it won't run on my Stacker-ed hard disk, > and F-Prot will. Sorry, I can't buy that. Let's not compare apples and oranges please. F-PROT is a nice virus identification tool, a so-called virus scanner. VDS 2.0 is a comprehensive package which is centered around an integrity checker, but also includes a scanner and a low-level utility to handle MBR/BR infections. In fact, we recommend F-PROT as an alternative to the scanner component of VDS. BTW, VDS 2.1 will be a lot more compatible than 2.0. VDSFSCAN, which is roughly like F-PROT, can handle network drives (tested on Netware & Banyan) and even CD-ROMs (to show compatibility), as well as compressed disks and under DR DOS 6.0. VITALFIX will work under DR DOS 6.0. We added a switch to avoid memory protection violation when EMM386.SYS is loaded. VDS.EXE (integrity checker part), on the other hand, works only if you have a non-compressed disk. Besides, we are trying to find a way to stop it from removing DR DOS protection :-)) Maybe early May, we will release VDS 2.1, for those who need more compatibility. >>And if you repartition the hard drive, re-installation is a safe bet. >>On alike machines, it may work fine, but why not install it as intended. > I'll give you a darn good reason: computer-phobic students. I pass out > F-Prot to any student who wants it that comes into my lab, and they > *very simply* go home and copy it on their hard disk. Boom. I even > wrote a thorough stupid- user batch file for installation for those > kids who don't even know how to do a directory on their computer at > home. What's the point in doing backups of your software if you have > to reinstall packages every time you make a change on your hard disk > or it crashes and you get to start from scratch? Eric, Your darn good example is based on not knowing what VDS is all about, and comparing apples and oranges. How many integrity checkers are you aware of do not require some kind of installation to create a baseline? F-PROT is NOT an integrity checker. Please do not make such assumptions if you are not familiar with a product. BTW, VDSFSCAN and VITALFIX do not require installation. Only the VDS.EXE (integrity checker) does. > I'm sorry, but I just can't see using a program that has limited use > on different hardware/software/OS configurations and recommends > reinstallation (not a trivial task from the description I read) any > time a change is made. I hope you and your organization rethink your > approach. Any time a change is made??? IMHO, repartitioning a hard drive is not just a simple change and requires reinstallation. Other changes such as installing new software etc. are handled easily, and do not require reinstallation. I hope you will take a look at VDS, and then make an assesment based on your experience, not based on an angry hacker's remarks. Please let me know. [Moderator's note: I would think that the rest of the group would be very interested in reading an impartial review of VDS. Have Rob Slade and/or Chris McDonald seen this product?] Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: 23 Apr 92 18:46:20 -0400 From: "Tarkan Yetiser" Subject: Misinfo detected - 3 (PC) Hello Mr. Bond, > 007 >> The SPECIAL system is standard MS/PC DOS based PCs most people >>use. They are prepared using FDISK, and are not compressed or protected >> by an exotic security system. You seem to argue by the exception rather >> than the rule :-) > In my experience, these "exceptions" are the rule with people who use > virus protection. If a user has the experience/presence of mind to > install virus protection, I'd give good odds he/she is a fairly > advanced user, and may well have Stacker, DR-DOS, NDOS, $DOS, or any > of a number of "exceptions" which make a PC easier to use. What if a > user shells to DOS from Windows and tries to use your program? Our experience differs. As far as sophistication of users go, I prefer not to classify it as you put it. Out biggest problem is not the stuff that makes a PC easier to use. It is non-standard stuff like compressed disks. Running VDS from within Windows? Please do not scare me like that. Just run it from the AUTOEXEC once a day. BTW, we are working on a modified version of VDS that will be compatible with unusual cases. >> If you have DR-DOS, Stacker, or some other non-standard stuff on your >>machine, please do not waste your time, VDS is not for such systems. > This is quite apparent. It seems to make poor economic sense to limit > the compatibility of your product so tightly. You had some good > ideas, it is a pity those who are best suited to use them can't. Well, if I were you, I would not be so sure about what is good economically speaking :-)) It is a valid point that compatibility with a wider variety of environments is desirable. > Vesselin seems to have been a bit unfair here. It is a given that a > virus can be written to evade any given detection scheme it knows > about. But we have so many virus detection methods that is seems > impossible to write a common virus that will evade ALL detection Well, that's okay. He does not seem to take sarcasm too well. The "joke is on you" posting angered him a little :-)) Of course, that does not mean people should be unfair just to justify their points. > I really like your idea of launching "decoys". I use this quite a bit > to see if my system is infected. If I think I might have a virus, I Yes, in many cases it works fine. Does not need to know the name of the active virus either. > has a 4 byte .COM file on it that does nothing but terminate. If I > notice any changes in the file (after rebooting from a know clean Not necessary to limit it to 4 bytes. Many viruses do not take small baits but prefer a larger and juicy one! > disk, of course) odds are I have both proof of viral activity, and a > clean copy of the virus for analysis. Yexactly! It really helps. > This method is far from foolproof, it is merely another layer in my No one claimed otherwise (besides Vesselin). It is just another piece in a whole system such as VDS, the strongest software solution available :-) Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: Thu, 23 Apr 92 16:19:00 -0800 From: "a_rubin@dsg4.dse.beckman.com"@BIIVAX.DP.BECKMAN.COM Subject: Re: Increasing CBCS Security (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >Huh, pardon my ignorance... I know what QEMM is (although I'm not >using it) and have heard that it has a stealth mode, but have no idea >what this mode consists in... Does it mean that it permits loading of >a resident program in a "shadowed" and read-only area of memory? If it >is possible to mark the memory occupied by the program as read-only, >this means that the virus will not be able to patch it (unless there's >a way to make it writable again), but this -is- memory protection and >my initial message dicussed the situation with no memory protection. I don't know the details of stealth mode, but I think the basic principle is that it allows you to have your own code in the same logical 20-bit address space as the BIOS; somehow QEMM can determine whether a BIOS call is being attempted or use of your code is being attempted on access. (I don't have QEMM V 6+, so I can't comment in detail.) It's possible that a virus looking for the real INT 13 vector couldn't find it if the areas are multi-used. - -- Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea 216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal) My opinions are my own, and do not represent those of my employer. Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ------------------------------ Date: Fri, 24 Apr 92 04:34:00 +0000 From: neilson@cs.sfu.ca (Carl Neilson) Subject: Question about forms of the stoned virus (PC) The other day I got Stoned - actually I was warned that a disk contained the stoned virus and took the appropriate steps. in the process of checking all of my diskettes, I uncovered 2 versiones of the stoned virus - one called 'no-int' stoned. What is the difference? I was under the impression that Stoned only infects if an infected disk is booted from yet the scanner would report Stoned in memory after a dir of the infected disk. Is this just due to the data loaded during a dir or has the virus actually been activated and is now in memory ready to pounce? On an aside, how would I go about getting a copy of the boot sector of the infected disk into a file so that it can be disassembled? any answers would be appreciatted. ------------------------------ Date: Fri, 24 Apr 92 10:09:19 +0100 From: "Vaughan.Bell" Subject: F-PROT Cascade false alarm... (PC) While scanning my hard drive with F-PROT 2.03a it picked up a possible Cascade variant in an ascii *text* file, FIND1701.DOC. This is the doc file that is supplied with FIND1701.COM a program that scans for and removes the Cascade virus. The doc file has the string '141$FLu' which also appears in the virus, and is also about 2100 bytes long. As an experiment I set up an ascii file with the 141$FLu string in it as well as 2000 zero characters and lo and behold F-PROT detects a possible Cascade variant in it. Although I find F-PROT an excellent package surely this should be fixed, a variant should NOT be assumed on a 7 byte text string and 2000 or so byte length. Frisk ?? )===---> Vaughan Bell - vaughan@uk.ac.psw.cd <---===( )===---> Polytechnic South West - Drakes Circus <---===( )===---> Babbage Building - Room 112 - Plymouth <---===( )===---> Devon - UNITED KINGDOM <---===( ------------------------------ Date: Fri, 24 Apr 92 11:12:00 +0100 From: Anthony Naggs Subject: New Myths #1: Infection during format (PC) Was "Virus surv[iv]ing format". michael.blackwell@f820.n680.z3.fido.zeta.org.au (Michael Blackwell) writes: > In a recent arcticle [New Scientist no.1813 p48] the author stated > "...some viruses may transfer from floppy to hard disk DURING > FORMATTING" {caps mine}. > > As far as my little knowledge tells me, this cannot be. I have yet to > find a virus description that aludes to this. I suppose theoretically > it is possible, but so is walking through walls. Has anybody heard of > such a virus? To deal with this properly I need to quote more of the original item, [New Scientist no.1813 p54 (Feedback column)], reproduced without permission: "... one idea .. to safeguard .. against .. a computer virus. If you send someone data on a floppy disc, and it is returned, reformat it to wipe everything clean before reuse. But be warned, some viruses may transfer from floppy to hard disc during formatting, before the process kills them. The trick here is to format the floppy on a cheap and cheerful computer which has has no hard disc, preferably a portable which has its operating system stored in ROM. That way the virus has nowhere to hide." The clear implication is that a virus can load/execute from the floppy disk during formatting, on an otherwise clean system. It is probably best to deal with this on a system by system basis: Acorn Archimedes: "Archimedes World" magazine April 1992 briefly describes the 10 (yes ten) viruses known to Acorn: all seem to either infect applications or attack !BOOT (equivalent to login.com, .login, autoexec.bat, ...). So little chance of a virus auto-executing. Apple Mac: (Caveat: I'm not an expert on these, however I think ...) WDEF virus hides in the desktop file, and will auto-execute when the desktop is updated for a new diskette. System 7.0 has some modifications to prevent this happening, so upgrade now! If you select Format/Initialise and wait for a prompt for the disk to be formatted, you should be okay - I can't imagine the Mac updating the desktop at this point. (Corrections from a Mac user would be welcome) WDEF is an old virus (winter 89) and is recognised by all AV software on the Mac. Atari ST: This is so similar to a PC with MS-DOS that I don't believe it would be possible, GEM only looks on a diskette to find icons and doesn't auto-execute anything. Commodore Amiga: Saddam virus can autoexecute, it purposefully corrupts part of the disk - Kickstart (the ROM part of the OS) will then execute l/disk-validator, however it looks on the currently active drive first. The solution is to either upgrade to Workbench 2.0 (includes Kickstart 2.0 ROM) or run FORMAT but wait for the prompt before inserting the diskette (at this point FORMAT has locked the diskette drive for it's exclusive use). Most AV s/w since last autumn should detect Saddam. (In the UK the Workbench 2 Upgrade Kit is hard to find, I NEED) (the HD backup s/w included so that I can send the HD unit for) (repair - I wish Commodore had a tech support desk!!! ) MS-DOS, PC-DOS, DR-DOS: Absolutely no chance of such a virus. OS/2: I've no information on this. Windows 3.x: Nobody understands what this does, apart from drag its feet and crash frequently. When Microsoft have blithely introduced new bugs in MS-DOS 5 XCOPY I can't trust Microsoft version control or QA! Take your chances if you're foolish enough to use this beast. I should have noticed the magazine item before, I'll write a letter to NS today. Hope this helps. Regards, Anthony PS Sorry to take so long to respond, only just got around to making a new modem cable. ------------------------------ Date: Fri, 24 Apr 92 11:15:00 +0100 From: Anthony Naggs Subject: New Myths #2: Boot viruses survive format (PC) Was "Virus surv[iv]ing format". "Mark Aitchison, U of Canty; Physics" writes: > ... it IS POSSIBLE > for viruses to survive the format process. If they were already on a > 360Kb diskette's boot sector that is formatted on a 1.2Mb drive to > 360Kb again there is a slight chance of the original tracks being > readable on other 360Kb drives, and if the MBR of a hard disk is > infected the normal DOS formatting of partitions probably won't affect > it. We're talking about quite a few more cases than walking through > walls occurrances, here. For this to happen the heads on both drives must be out of alinement in opposite directions. Because of the narrowness of of tracks & large amplitude signals on a HD disk (1.2Mb) a HD drive with significant misalignment would show up rapidly as being unable to read old disks or exchange disks with other PCs. The computer being clearly faulty even a naive user would call an engineer at this point. So we must assume that the HD drive is close to correct alinement, placing tracks ie right through the centre of the track on a 360k disk. On a correctly aligned 360k this leaves 25% of the track width on either side with old data: ===******=== = is data written by a 360k drive, * by a HD drive. +--------+ Normal position of head on 360k drive +--------+ Typical alignment problem +--------+ Head position required to read old data(!) ...******========= Disk previously used by the faulty 360k drive As 80% of the signal picked up by the 360k drive comes from the portion written by the HD drive so data exchange is usually reliable. If the drive head is of unusual design or out of alinement then the disk would be wholly or partly unreadable on the 360k drive. The drive head must be grossly out of alinement for the data from the HD drive to be ignored. This would not only show the same symptoms as for a HD drive with very bad alignment, but would preclude exchanging any data with a HD drive. Hope even the physicists out there can cope with this explanation, if not then try graphing the field strength of an electromagnet (ie when a disk is being written to - for the same electromagnet used as a search coil a similar graph portrays relative sensitivity). Regards, Anthony PS Just noticed that I keep changing my spelling of aline/align, as I have no particular spelling preference on this I merely apologise for being inconsistant. PPS Alternate email address is xa329@city.ac.uk ------------------------------ Date: Fri, 24 Apr 92 11:42:14 +0100 From: "Vaughan.Bell" Subject: Re: Bloody Virus (PC) In VIRUS-L Digest V5 #93 las@cunyvms1.gc.cuny.edu writes :- > Maybe two months ago I had the greusome esperience of > down loading some e-mail from the main computer via > modem to my pc at home. Immeddiatly one of my floppy > drives stoped working, but I had no idea what was > happenning. I took my computer to be serviced, the > person ran some viral scanner and found a virus had > infected the hard disk. He unfortunatly failed to have > an antivirus for the virus that was infecting my > machine. I eventually, many dauys later found out > mcafee. It ran it and cleaned the machine of the > infection. The virus was "Bloody Virus". Now I'm afraid > of down loading files into my pc from the main computer. > What can I do to prevent an infection of the sort My > computer suffered? any software (public domain) > available for this sort of stuff. Unfortunatly I didn't > know then of this group. You may be happy to know that a virus cannot be spread by simply downloading files onto your computer (isn't this in the FAQ list ??). In the situation that you described it is immpossible for the Bloody! virus to infect your computer by downloading e-mail (which I assume were text files). The Bloody! virus is a bootsector virus which means it can only spread by booting your computer off of an infected diskette. The only situation that I can think of that would have caused the infection would be that you downloaded a UUencoded (or similar encoding method) file, you then unencoded it to produce an executable program file which was a trojan and placed the virus onto your computer when you executed it. As for your disk drive stopping working, this is not a virus as software can't damage hardware. PD and shareware anti-virus software... LOTS OF IT, some of the most popular being Fridirik Skulason's F-PROT (now version 2.03a), McAfee Associates SCAN (now version 89), VIRx (now version 2.2) and lots of others thatI haven't mentioned, check out BBS's and anonymous FTP sites. In general it should be perfectly safe to download text and data files from another computer but all executable files should be checked with an up-to-date virus scanner. Bye for now... )===---> Vaughan Bell - vaughan@uk.ac.psw.cd <---===( )===---> Polytechnic South West - Drakes Circus <---===( )===---> Babbage Building - Room 112 - Plymouth <---===( )===---> Devon - UNITED KINGDOM <---===( ------------------------------ Date: 24 Apr 92 14:11:00 +0100 From: sgr4211@uk0x08.ggr.co.uk Subject: Re: Windows viruses? (PC) "Mark Aitchison, U of Canty; Physics" writes: > sgr4211@uk0x08.ggr.co.uk writes: > > Microsoft Windows v3.1 provides a facility for embedding executable > > code within datafiles (part of the "Object Linking and Embedding" > > philosophy). It occurs to me that this could allow viruses to sneak > > in through the anti-virus procedures adopted by many organisations - > > scanning "standard executables" and boot-sectors only. > Seriously, though, it looks like something anti-virus people > need to look at pretty darned quickly, although I doubt that a virus > that requires MS Windows to be present would get very far at the > moment. (but then again...?) I disagree. MS Windows is *very* widely used indeed! Anyway, the infected file needn't be a Windows executable; a DOS program containing any file-infecting virus can be embedded and can then be executed just by double-clicking on it. So the virus could potentially sneak past anti-virus software that isn't looking at, say, .WRI files. I don't know if "MS-DOS viruses" can spread when infected DOS programs are executed from within a Windows session - can anyone confirm/deny this? > > Also, I have heard that some virus scanners search for virus patterns > > only in places where the virus code would occur - if this means, for > > example, the beginning or the end of a file, would this make a virus > > invisible to such "smart" scanners? > > Most can be told to search more, but the default is .COM and .EXE. > Personally, I think the default should be .COM and .EXE and .SYS and > any file that starts with MZ. The .BAT, .PIF and .BAS viruses are > rare enough to not include them by default. Any other extensions don't > need to be scanned for general viruses but for specific viruses, to > save time. Misunderstanding. The whole point of "embedded viruses" is that they would effectively be infecting datafiles, rather than executables. My query was not which *type* of files are searched - that, as you say, is usually configurable. What I was asking is "do the scanners search only the FIRST (or last?) n-bytes of a file for a virus pattern, and if not found the file pronounced clean?" If so, when an executable file that has been infected with a virus (now occupying the first n-bytes of its code), and the infected executable is embedded within a datafile (perhaps documentation in the form of Microsoft Write file), the virus code will no longer be at the beginning of the "outer" file (co-host?). This means the virus may not be found even if the scanner *is* looking at all files. Steve Richards. ------------------------------ Date: Fri, 24 Apr 92 15:00:13 +0000 From: kibirev@csa.bu.edu (oleg kibirev) Subject: Re: Write protecting with software (PC) Original poster is lost, sorry. >> If you ask DOS nicely about BIOS direct access then my defence can >>answer to your asking nicely too, but you can not receive address of >>BIOS itself. This call returns with address of Int 13, and becomes >>equil to call of Get Interrupt Vector. I doesn't find any software >>that worked incorrectly while receiving this address (except viruses, >>of course :-) Well, one of my TSRs will be very unhappy about this. It's INT 13 extender (1066K on 720K diskette etc.) and if DOS 5 is loaded to HMA, it will load together with it. I get original INT 13 address from DOS, so when I am called, DOS has already had fun with INT 13 vector and enabled A20 for me. Hope people will not confuse INT13X with virus. (although if computer has a hard disk, the TSR will chain to INT 40, not to address returned by the function). Kibirev Oleg kibirev@CSA.BU.EDU ------------------------------ Date: Thu, 23 Apr 92 22:10:43 +0000 From: rslade@sfu.ca (Robert Slade) Subject: Re: Viruses via MS Windows OLE? (PC) sgr4211@uk0x08.ggr.co.uk writes: >Microsoft Windows v3.1 provides a facility for embedding executable >code within datafiles (part of the "Object Linking and Embedding" >philosophy). It occurs to me that this could allow viruses to sneak >in through the anti-virus procedures adopted by many organisations - >scanning "standard executables" and boot-sectors only. We've heard from the authors of antiviral software that Windows is a difficult environment to work in in any case. Having just attended a technical seminar on Windows 3.1, I do not feel that OLE presents further security problems. The "embedding" portion of OLE seems to refer only to printable material, such as a chart, which was originally created by another application. "Embedding" such objects in the body of a document merely means that a record is maintained of the original application for ease of amendment. Therefore, the executable, in this case the original application, exists outside of the document. "Linking" appears to refer to non-printable material, such as a "sound-bite" or program. In this case again, it is merely a record or pointer to an outside application. ============== Vancouver | "A ship in a harbour Institute for Robert_Slade@sfu.ca | is safe, but that is Research into rslade@cue.bc.ca | not what ships are User CyberStore Dpac 85301030 | built for." Security Canada V7K 2G6 | John Parks ------------------------------ Date: 24 Apr 92 11:47:19 -0400 From: "David.M.Chess" Subject: Re: Extensions (was: Viruses via MS Windows OLE?) (PC) > From: "Mark Aitchison, U of Canty; Physics" > Most {scanners} can be told to search more, but the default is .COM > and .EXE Many scanners scan somewhat more than that by default, I think. The IBM Virus Scanning Programs by default scans (rustle, rustle) all of EXE, COM, OV?, INI, SYS, BIN, and PRG (2.2.2 and above also scan files of extension .DOS and .OS2, and report any boot viruses they find there, because of the OS/2 Dual Boot feature). It's a good idea, I think, to scan the most common executable extensions by default. And of course there should be the equivalent of the -a switch to scan all files, for cleanup and for the paranoid. Scanning any file starting "MZ" is an interesting idea! There's a considerable speed hit, of course (you have to Open() every file so as to read the first two bytes), but it might be another good option. Speaking of "MZ", does anyone know of a linker or whatever that produces EXE files starting with "ZM"? DOS (and a few viruses) apparently support it, but is it ever used? Does it mean anything different from what "MZ" means? DC ------------------------------ Date: Fri, 24 Apr 92 12:52:30 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: QEMM "stealth" and Anti-Viral Products (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >Subject: Re: Increasing CBCS Security (PC) Vess: >> >energetic barrier (the "tunnelling effect"). If correctly implemented, >> >these techniques are able to bypass -any- monitoring program, and >> >therefore the monitoring programs (like FliShot+) are the weakest >> >line in the anti-virus defense (even weaker than the scanners). >"a_rubin@dsg4.dse.beckman.com"@BIIVAX.DP.BECKMAN.COM writes: >> Does that mean that they will fail under QEMM 6 STEALTH mode? Vess: >Huh, pardon my ignorance... I know what QEMM is (although I'm not >using it) and have heard that it has a stealth mode, but have no idea >what this mode consists in... The function of the "stealth" mode is to permit remapping of the ROM in memory to expanded memory and using the page frame to move ROM functions in and out of the lower 1 Mb. This permits use of the ROM area as "high RAM". To do so, it changes all ROM vectored interrupts to point at the "stealth" handler in the QEMM driver. To make sure it is done properly, QEMM (6.0 & above) walks the interrupt list to *correct* applications already in RAM. I first discovered this with my DiskSecure product when the maintenance mode flagged it as a virus-like vector error. Since most applications that use expanded memory now know how to use extended memory, I elect to use the NOEMS switch which frees up the same 64k that "stealth" would. Since "stealth" requires use of the page frame, this was a wash in terms of available high memory. It does provide a good check of integrity managers for disks - if QEMM "stealth" is in use, there should be some warning displayed particularly if the manager loads from the DOS level as a TSR. If not and if the system doesn't hang on disk accesses, unless the product specifically advises you that it has detected QEMM "stealth", I would have to wonder about the effectiveness of the anti-viral product. Warmly, Padgett ------------------------------ Date: Fri, 24 Apr 92 13:23:00 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: Authentication of resident Anti-Viral programs (PC) >From: "Norm J. Harman Jr." >Subject: F-Prot & DATAMON (PC) > In general how can a user verify that the >anti-virus software he/she has installed is actually operating as expected? This is something that I have had a number of discussions with various vendors over the last year or so. At present I know that McAfee Vshield and Roger Thompson's VirusBuster have this capability (as my products do of course 8*). There may be others with this capability that I am not aware of. Usually such authentication is via a separate .COM or .EXE file that knows how to find the anti-viral product in memory and will verify its presence. Just how far this verification goes depends on the product. Obviously it could range from trivial to very complex. One product that I know of (Enigma-Logic's SafeWord-VirusSafe) installs as a device.driver and will intercept the command TYPE SWVSVERS and respond with the product license screen (for a description of how this works see the *many* postings reguarding device driver "aliases" of a few months ago). The other possibility involves the fact that most good resident programs intercept the EXEC function of DOS. It would be possible to use a code name that would be a signal to display recidency information when requested. These are just three of the ways such authentication could be invoked. IMHO, such a capability is vital to the authentication of a machine from a network server level on login (ref an equal number of comments reguarding the virtues of client-server networks over peer-peer systems) Warmly, Padgett ------------------------------ Date: Thu, 23 Apr 92 23:07:08 -0400 From: John S. Lee Subject: help!!! (Apple ][gs) Hi, I have a friend who may have a virus on a IIgs. Can anyone help me. thanks in advance.... john Lee jsl102@psuvm.psu.edu ------------------------------ Date: 23 Apr 92 21:16:56 +0000 From: linc@tongue1.Berkeley.EDU (Linc Madison) Subject: Re: Biohazard symbol for computer viruses? A.APPLEYARD@fs1.metallurgy.umist.ac.uk writes: >Someone said that there is no ambiguity between biological and >computer viruses in using biohazard tape to warn of both, since >"computer floppies etc aren't likely to get biocontaminated". Aren't >they!? ... That was me, I'm afraid; mea culpa. I didn't think out the possibility of diluting the original meaning of the biohazard symbol. Unfortunately, though, I wasn't alone in my thinking: I saw a commercial antiviral package (sorry -- I forget which one, but it was for Mac) with the biohazard symbol on the box cover. I agree with the people who have pointed out that it is a bad idea to use the same symbol for both purposes; we need a unique symbol for computer viruses. - -- Linc Madison == Linc@Tongue1.Berkeley.EDU ------------------------------ Date: Fri, 24 Apr 92 13:16:00 +1200 From: "Mark Aitchison, U of Canty; Physics" Subject: A short commercial break (was Re: lies and damn lies) FBCohen@DOCKMASTER.NCSC.MIL (fc) writes: .... As for advertising on V-L... > [Moderator's note:... I welcome discussion on the > product announcements which I allow here on the group; based on > feedback from readers, I have accepted the announcements because they > provide a public service. However, if the majority of the group feels > that they should be eliminated because they are commercial, I will > reject all announcements of commercial products.] I personally like finding out when the latest version of X is available on Y, etc. Whatever compromise is arrived at, I hope it isn't based entirely on avoiding advertising (although I don't like blatent advertising)... partly because the mere mention of particular products (which, I feel, is not only valuable but inescapable) is also a form of advertising, and there is a risk of unfairness and stagnation if only the old, existing products keep being mentioned. It is the *way* that products are mentioned, and the *balance* in mentioning the full range, that is important, not the *if*, I feel. But that is hard to do. And the solution has to improve the Signal/Noise ratio, which means coverring all product announcements, including freeware (for example, I could easily rave about my BOOTID program and waste lots of net bandwidth, which would be bad - even though I don't get a bean out of the program). So a suggestion: How about establishing a table, perhaps an Appendix to the FAQ... a brief summary of anti-viral products, by category. It would have the latest version number, and where you can get it, and the size (& checksum?) of the archive, and some other information tabulated - don't know what (I'd hate to say "number of viruses spotted", and scores for documentation, etc would involve a lot of work for somebody, although I know there are good reviews being done now). Then, if someone asks what software can do a particular job it is a simple matter to use the standard, impartial list as the answer. I do think, though, that there is still a need to answer very general questions like "what is best" with a lot more than a particular product - considerations like using a mixture of approaches, maintaining good operating procedures, what software can work together without incompatibilities ("protecting each other's backs"), etc are at least as important. It would be sad to not answer such questions, or to have a couple of zillion individuals all mentioning their own preferences (with, I bet, a zillion different spellings of Mick Affey :-) As new versions become available, a differences file (or simply the additions) for the list could be posted. What do others think? Mark Aitchison, Physics, University of Canterbury. ------------------------------ Date: Fri, 24 Apr 92 11:14:00 -0400 From: Alex Nemeth Subject: Check list Series avail for FTP? I've found the Checklist series informative and helpful. Is this series available on an FTP site somewhere, either in whole or in parts? [Moderator's note: Most of the checklist series is available by FTP on cert.org (192.88.209.5) in the pub/virus-l/docs/slade.cvp.articles directory. Admittedly, the directory does need to be updated.] Alex Nemeth AN5@cornellc ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 95] *****************************************