From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V5 #57 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Friday, 6 Mar 1992 Volume 5 : Issue 57 Today's Topics: Michelangelo (again!) (PC) Re: Will Write Protection Prevent Virus Infection? (PC) Re: WP.EXE appended to, up front, solved (PC) Clean 86b and DIR-2 (PC) Network virus ? (PC) Sorry, more questions about Michelangelo (PC) Integrity Checking in BIOS (PC) re:Keyboard problem (PC) Re: Question on Michelangelo Date-Trigger (PC) Michelangelo, the name (PC) Re: Norton AntiVirus Michelangelo Edition (PC) Michaelangelo-Only NAV Available (PC) Re: Michelangelo- blem wit with MEM/C (PC) Re: Which Package is Best? (PC) Michelangelo news brief from The Washington Post (PC) Michelangelo attacks Unix? (PC) (UNIX) Michaelangelo virus info for PC-bases UNIX system users (PC) (UNIX) Re: Antiviral features in operating systems? Virus history question. Re: Antiviral features in operating systems? 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: Wed, 04 Mar 92 16:28:56 -0500 From: Helena M Vonville Subject: Michelangelo (again!) (PC) I have installed F-PROT 2.02 on my pc's so I feel fairly safe at this point but... how effective is it to leave computers on from Mar 5 through Mar 6,i.e. don't shut them off so the system doesn't boot up Mar 6? Is this a possible solution for those who need their computers on the 6th but haven't been able to check for the dreaded disease? Helena VonVille OH State University hvonvill@magnus.acs.ohio-state.edu ------------------------------ Date: Wed, 04 Mar 92 20:32:41 +0000 From: ampex!russest@decwrl.dec.com (Steve Russell) Subject: Re: Will Write Protection Prevent Virus Infection? (PC) mtppepim@lg.ehu.es (Martin_blas Perez Pinilla) writes: >gt1280b@prism.gatech.edu (ELGHARIB,HESHAM MOHIEDDIN ABOBAKR) writes: > >> If I set the attributes of all the executables, overlays, and COMM >> files in my hard drive to be read-only, will this reduce the chances >> of getting virus infection? > >Change the attributes is _absolutely_ useless. Only some very old and >very stupid viruses can be stopped with such trick, but all >well-written (:-)) viruses (Jerusalem, Yankee Doodle...) can change >the attributes, infect the programs and reset the attributes to its >original state. Still a good thing to do to prevent "user-inflicted" damage. - -steve ------------------------------ Date: Wed, 04 Mar 92 21:00:21 +0000 From: ampex!russest@decwrl.dec.com (Steve Russell) Subject: Re: WP.EXE appended to, up front, solved (PC) FRYSTD@ACAD.LVC.EDU (Michael Fry) writes: >The mystery of the .BAT file contents tightly prepended to the front >of WP.EXE, and the other corrupted non-executable files, seems to be >solved (thanks again, cgordon in Chicago!). The phenomenon could >easily have been caused by a defragmentation program that squeezes the >contents of files and later writes them back to newly freed clusters, >being interrupted prematurely. (Hence the filename, etc., being >packed with their contents). > >No, Steve, CHKDSK found no problem (which is a surprise if a defragger >left corruption when it got interrupted). Something I've found is that various drivers, disk caches, or other overhead tsr stuff may affect the performance or behavior of defrag routines. This was particularly noticable when using MACE's un-frag routine. I recommend that all tsr's and cache schemes be removed from memory before doing any sort of disk maintenance. - -steve ------------------------------ Date: Wed, 04 Mar 92 23:09:34 +0000 From: rebill01@vlsi.ct.louisville.edu (Russell E. Billings) Subject: Clean 86b and DIR-2 (PC) I tried mailing this to McAfee Associates e-mail address, but I never received a response on this: A few weeks ago, someone brought some disks that he had been having problems with into the computer center where I work. As we had just found our first (and so far only) Michelangelo infection, we ran his disks through Scan 86. It detected DIR-2 spread throughout roughly half of his disks. He brought his computer system (and the rest of his disks) in a short time later, and I used a DOS 5.0 boot disk and Clean 86b to clean the system. After reporting the first infection, Clean hung. I tried again on a different system and had the same results. In each case, the system was booted with DOS 5. I eventually went back to Clean 85 which removed D2 with a minimal amount of files reported as "unable to disinfect, delete? y/n". Is this a known bug with Clean 86b, or did I get bitten by something else? Thanks! Russell E. Billings Student Supervisor Health Sciences Computer Center University of Louisville Louisville, Kentucky ------------------------------ Date: 27 Feb 92 00:51:00 +0000 From: dave.edwards@f858.n681.z3.fido.zeta.org.au (Dave Edwards) Subject: Network virus ? (PC) Hi I'm looking for info on virus that attack networks specifically, or that pose particular problems for networks. I've heard of one that is tailored to the Novell net but cannot find any info about it.. Any networks had virus probs ?? Ta in advance .. Dave .. - --- Maximus 2.00 * Origin: < The Keyboard BBS > - V32, Call 08-344-5354 (3:681/858) ------------------------------ Date: Thu, 05 Mar 92 00:49:41 +0000 From: brymastr@eng.umd.edu (Bryan I-chuen Lee) Subject: Sorry, more questions about Michelangelo (PC) First, I saw one response about a quick way to check for Michelangelo using CHKDSK and looking at the memory size. Is there any other way? I have only DOS, i.e., no special utilities for looking at disks in detail. Second, from what I've read, if I haven't booted up from A: then my hard drive cannot be infected. Is this true? (Yes I have booted from my A drive before, but rarely). Third, if I do not use my computer Friday March 6, 1992, I will NEVER have to worry about this particular virus ever again. Is that true or am I about to do a lot of disk backing-up? Thanks a lot and I think I'll be getting some Virus scanning software soon (I know, I know, why on earth haven't I gotten one already?) - -Bryan Lee ------------------------------ Date: Wed, 04 Mar 92 20:10:55 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Integrity Checking in BIOS (PC) >From: David_Conrad@MTS.cc.Wayne.edu >Two things the ROM BIOS does NOT do, which it should... >Second, after it has completed the above process, it performs no >integrity checking of any kind on the Master Boot Record or Boot >Sector it loads before handing control to it. People who write >anti-viral code hate the BIOS writers for *that*. Well, some do, TANDON at least checks for a valid boot partition table 8*) but in real life there are certain constraints to what a "100% compatable" (and this really means the BIOS) can do. For one thing, it is difficult to recognize a virus before it tries to execute - what are you going to scan for ? To me, the one thing the BIOS should do (and a few do: Zenith, Compaq, NEC, Tandon) is to specify booting from the fixed disk unless something *special* is done. The other possibility would be a MBR & BR checksum stored in CMOS (should be room) but again you need a mechanism that would allow updating when things change. As far as Int 13 - it is limited what the BIOS can do since many controllers use ROM extensions to take that away from the BIOS control. Of course this has also made things difficult for the virus writers so it is a mixed blessing. Now, since you asked 8*), IMHO the BIOS should be limited to what I have indicated above. It is the OS that should be doing the integrity management (preferably from IO.SYS but MSDOS.SYS could take that function. It does take BIOS programming which is different (still use MASM, I just lie to it). But not from the BIOS, Thanks to the Oct. 27, 1982 revision, it is just too easy to take control away and we all know what happens to any computer that isn't "100% compatable". Warmly, Padgett ------------------------------ Date: Wed, 04 Mar 92 19:44:00 -0600 From: SULLIVAN@iscsvax.uni.edu Subject: re:Keyboard problem (PC) VM@CSPGIG11.BITNET (Vera Marvanova) writes: > Please could someone tell me, if such a behavior of computers could be > caused by a virus? In two computers (386-SX AND 386 - 33) after some > time of operation suddently all look like CAPS LOCK would be touched. > All letters changes to upper case. After "SHIFT" all is O.K., but > after some time this appears again. Scan86b shows nothing. We had a similar experience using DBase III. When we tracked down the problem, it turned out to have a simple cause, totally unrelated to DBase, or viruses. We had had Student Computer Centers filled with Zenith XT compatibles. Students had been using them for assignments for which their instructions read to press SHIFT-PrintScreen to get a printout of their form. When we replaced those machines with PS/2's (specifically 55sx), the shifted version of the PrintScreen key was replaced with a system call which reprograms the keyboard. We're relying on education at the moment to correct the problem, but it seems that, once again, Big Blue has made it unreasonably easy to shoot yourself in the foot. IMHO, something this confusing should be much more difficult to do so that you have to REALLY intend it to happen. The problem has been recreated in some clones so that they act the same way. Whew, got that off my chest! I'll probably be struck by lightning tomorrow. Well, at least I'll miss the Michelangelo cleanup. Sullivan ------------------------------ Date: 05 Mar 92 01:48:13 +0000 From: georgep@vice.ico.tek.com (George Pell) Subject: Re: Question on Michelangelo Date-Trigger (PC) mgk@sql.sybase.com (Michael Keirnan) writes: +bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: + +>> It would seem that if true, as an interim measure until all systems +>> could be scanned, that the systems just be set so that Friday, the 6th +>> of March never comes.... + +The idea of setting the clock has probably been suggested largely +because it is easy to do, and doesn't take much time. This is +understandable, but the virus situation is such that to protect +yourself requires a time investment. But it is well worth it. For those thinking they will just set their clock ahead......... HOLD ON THERE.... I have personally tested the Michelangelo Virus. Setting your DOS clock to the 7th using the DATE command may not protect you. As an experiment with an AST 286, we set the CMOS clock to March 5th and the time to 11:50 PM. The DOS clock was then set to March 7th. The Hard disk was overwritten on the next boot. This is because Michelangelo uses interrupt 1A to read your CMOS real time clock, not your DOS clock. Unless you re-set your CMOS clock, you are going to be surprised when you boot up on the 6th. Secondly, you are going to continue to spread the virus after the 6th, making March 6th, 1993 even more interesting than it was this year. geo ------------------------------ Date: Wed, 04 Mar 92 21:38:00 -0600 From: RCTE4@Jetson.UH.EDU Subject: Michelangelo, the name (PC) With all this discussion about the naming of the Michelangelo virus, let us not forget that March 6 is known for more than the birth of an artist - March 6, 1836 was the fall of the Alamo. While I doubt that the authors had that in mind, if the virus had hit here in Texas first (and it has not spared my lab recently), it would probably be known as the SantaAnna virus..... Scot Carpenter University of Houston RCTE4@jetson.uh.edu ------------------------------ Date: Thu, 05 Mar 92 04:35:27 +0000 From: grady@world.std.com (Dick Grady) Subject: Re: Norton AntiVirus Michelangelo Edition (PC) James_Williams@ESS.NIAID.pc.niaid.nih.gov (James Williams) writes: >While I think that the Norton AntiVirus Michelangelo Edition is smart >business by Symantec. I thought the program was shoddy at best. Why >does this program scan all exe and com files when Michelangelo is a >boot sector infector? Perhaps to impress the unsophisticated user. Checking only the boot sector would take such a short time that the user would think that nothing was checked. Central Point's Michelangelo Edition scans *all* files, even data files which could not contain any virus. More show-business? The CP version does check for the Friday-13th virus also, so (assuming that Friday-13th can hide in executables; i don't know.) it has more reason to check executables. But data files??? - -- Dick Grady grady@world.std.com uunet!world!grady ------------------------------ Date: Thu, 05 Mar 92 00:15:28 +0000 From: brian@norton.com (Brian Yoder) Subject: Michaelangelo-Only NAV Available (PC) Just in case any of you have not already heard, Symantec/Peter Norton is making a Michaelangelo-only version of Norton Anit-Virus available free of cost as a public service. It is avaialble on several FTP servers including: wuarchive.wustl.edu in msdos/utilities/virus. Just to repeat, this version ONLY deals with Michaelangelo and cannot be upgraded to understand more virus definitions. This also does not mean that the commercial version of NAV has become public-domain or shareware. We are this special version available to promote NAV and to help users avoid the clutches of Michaelangelo. Happy Computing, Brian K. Yoder - -- - -- Brian K. Yoder (brian@norton.com) - Q: What do you get when you cross -- - -- Peter Norton Computing Group - Apple & IBM? -- - -- Symantec Corporation - A: IBM. -- - -- ------------------------------ Date: Thu, 05 Mar 92 08:26:27 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: Michelangelo- blem wit with MEM/C (PC) SLINE@ITHACA.BITNET (Dan Sline) writes: > > I noticed something really weird when I came in contact with >Michelangelo today. When I did a MEM /C it came up with: > > blem wit > >in the output and it was taking up about 4K. Weird, isn't that? I've seen that before with Novell NetWare drivers, among other things. Its actually part of a message from inside the program that says "proBLEM WITh" (emphasis mine) as part of the text within the program. It's not related to the Michelangelo virus at all. Regards, Aryeh Goretsky McAfee Associates Technical Support - -- - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 1900 Wyatt Drive, Suite 8| FAX (408) 970-9727 | "Log... from Blammo" Santa Clara, California | BBS (408) 988-4004 | 95054-1229 USA | v32bis(408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ Date: Thu, 05 Mar 92 14:56:00 +0200 From: Y. Radai Subject: Re: Which Package is Best? (PC) Vesselin Bontchev, Donny Gilor, and Wolfgang Stiller write concerning Untouchable (and Integrity Master): >> Note 1: As opposed to most "quick checks" and "Turbo modes", UT's >> quick check is performed in such a way that for all practical purposes >> there is no loss of security, *regardless of how the virus infects*.) VB> Regardless?! Hmm, it's a little bit hard for me to believe that... The idea is this: When a quick check is requested, UT obeys only with respect to 90% of the files; it randomly selects 10% of the files for a full check anyway. Since the virus-writer can never know which files will be full-checked on any given execution, he cannot take advantage of the fact that the other 90% are not full-checked on that execution. DG>If there is no loss of security, why is there a "full check" option? What I said was that *for all practical purposes* there is no loss of security. Some people might feel uneasy about waiting an average of 10 executions of UT in order for a given file to be full-checked, so the full check exists for them. But in practice this is not something that the average user need be worried about. >> Note 2: UTScan's speed is not decreased by addition of more viruses. VB> VB>You probably mean that the spead is not decreased proportionally to VB>the number of viruses added. I hope you won't claim that if you add VB>100,000 new virus signatures, the program will run at -exactly- the VB>same speed... :-) In principle, the speed remains constant absolutely, not proportio- nately. UTScan uses a hashing technique. Each time new virus pat- terns are added, the size of the hash table is increased linearly, hence the search can go just as fast in absolute, not proportional terms. This is limited only by the amount of memory available. Each of UTScan's patterns requires 6 bytes, so 100,000 entries no, but 40,000 yes. That ought to be enough for at least another month :-) . VB> you have to ensure that you are installing the integrity VB>checker on a clean (non-infected) system. Do you know a better way to VB>ensure this than to scan for known viruses? (I -know- that this is not VB>a good solution, but do you know a better one?) Well, it would certainly help to have a file- and sender-authentica- tion scheme (by means of a two-key system, preferably preceded by a hash function) to authenticate the sender and to ensure that the file has not been altered en route to the user. Of course, given that such a scheme is not widely used at present, you are right with respect to *files*. But MBRs and boot sectors can be guaranteed clean as I men- tioned in my previous posting. VB> In fact, IM (and any integrity checker) does not need to restore VB>the infected files at all. I don't know why it does it; it is not VB>necessary. There are plenty of good backup/restore programs on the VB>market. One (a rather bad one) even comes with DOS. That's true in theory, but in practice most users do not keep backups, at least not in a way in which they can be easily accessed for reco- very purposes, and that's the reason there is a demand for specific disinfectors (like CLEAN) and generic ones (like UT). Moreover, many of those who do keep backups do it incorrectly, e.g. they keep making new backups of the same executable files until they find out that from some stage on, they have been backing up infected files. We could go into a long discussion of how (not) to create backups. >> In fact, IM is >> even *more* dependent on a KVS, for (like all programs based on modi- >> fication detection) IM must ensure that the files and boot records are >> uninfected when checksums are initially computed. VB> VB>I fail to see why UT does not need this. I didn't say that UT doesn't need this. On the contrary, since UT is based on modification detection, it *does* need it. But it needs it *only* for this reason and not for the other reason that IM needs it. VB>Unfortunately, the generic restoration is a bad idea, which does not VB>always work. IMHO, it is even worse than virus-specific disinfection. VB>OK, I agree that at least UT will not try to disinfect a file VB>incorrectly, but still the best solution is to use a backup/restore VB>program. See above remark on backups. VB>Not necessarily. Consider a Lehigh-type virus. Agreed. (But just as one can refresh the MBR and boot sector, one can easily refresh COMMAND.COM from the DOS installation diskette.) VB> we won't wait long until we see viruses, which attack VB>checksum-based defences. *All* checksum-based defenses? or only a small number of *particular* ones? In either case, you'll have to explain that remark. VB>And don't forget that the generic disinfection will simply not work, VB>if the file has been previously infected. Of course. VB>But this is not so important. To put it in another way: BACKUP/RESTORE VB>can restore an infected file in 100 % of the cases, when it has been VB>applied before infection. UT can't. See above remark on backups. VB> The important is to compare the checksum VB>checking speed. I understand that UT is fater than IM in this case. Am VB>I right? That's what my test showed if one uses UT's quick check: >> IM 1:59 >> UT quick check 1:09 I didn't notice that IM had a quick check (as Wolfgang writes). WS>Since you quote the Virus Bulletin's report, let me do so also. ..... WS> In tests UT was found to be unaware of stealth viruses and reported WS> no changes to files when Tequila, Haifa, 4K and a host of other WS> stealth viruses were memory-resident." ..... WS> Integrity Master will detect these viruses if WS>resident in memory or on disk. (I know, I know -- they should cold WS>boot from a known good copy of DOS on diskette, but the fact remains WS>that many users won't do this) First, I can't help mentioning that I saw the *draft* version of the review (by Mark Hamilton) of Untouchable which appeared in the VB, and I must say I have never seen so many errors and confusion in a product review. In particular, he had a preconceived impression that UT could not detect stealth viruses because he completely ignored UT's "safe test". To his credit, Mark was open to corrections (much more than I can say for the VB's most frequent evaluator, Keith Jackson), and in the final review he corrected about 90% of the errors. In particular, he added: "The developer is fully aware of this fact [need to boot from a clean diskette,] which is clearly stated in the documentation. The installation program provides the option to create a 'Safe Disk' (i.e. a working copy of UT and its checksum database on a clean boot- able disk) so that ... the user can perform a secure integrity check in a known clean DOS environment." Thus the former quotation is mis- leading. Btw, Hamilton did not explicitly say that Untouchable does not de- tect stealth viruses in *memory*, although this is perhaps implied by his statement that UT spread infections when it added new files to the database. I can only presume that he was not running Untouchable's resident module, UTRes, at the time, because it *does* detect all the common viruses in memory. WS>You raise a big personal gripe of mine. I have seen the ads for UT. WS> .... Can anyone present any WS>evidence that their claim is true that they can generically disinfect WS>any virus???? I haven't seen the claim that it can disinfect *any* virus. If that's what the ads say, then I am against them just as strongly as you are. What I have found *so far* is that it fails on viruses which overwrite code (understandably) and on those which overwrite stack space (not so understandably, but this will be corrected in the next version). When I get the time, I'll test UT on more viruses. Meanwhile, why don't you try to get an evaluation copy (if you don't already have one) and test UT on them? WS> 3) Missing common memory resident viruses as reported by VB is in my WS> opinion a fatal flaw in that version of UT. As stated above, I think this is an error on the evaluator's part. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET Phone: +972-2-584536 ------------------------------ Date: Thu, 05 Mar 92 06:59:00 -0500 From: "David Bridge, MSC VAX System Manager" Subject: Michelangelo news brief from The Washington Post (PC) NEWS brief from The Washington Post, March 4, 1992. Page B2. "The Michelangelo computer virus has invaded Capital Hill, sending congressional staffers scurrying for a cure before Friday's trigger date. It's like Grand Central Station here," said Hamish Murray, director of the House Information Systems, whose office is busy distributing virus-killer diskettes to Congressional offices. Agriculture Department officials also reported finding the virus in their computer system." yours, David Bridge Smithsonian Institution ------------------------------ Date: Thu, 05 Mar 92 03:22:38 +0000 From: angie@netcom.com (Angie Tso) Subject: Michelangelo attacks Unix? (PC) (UNIX) Is there a anti-virus check for UNIX on Michelangelo? I did a test today ( I boot the system with the infected boot dos floppy.) with a Interactive UNIX base 486 system, and the system would not boot after it was affected with the date on March 6th. It's a UNIX only system, which means there is no DOS partition. This is a big news to me, and my second question is, Does Michelangelo affect the first boot disk only? If the system has two harddrives, will the second one be affected? Also, is it true after I did a low level format on the first drive, then I shot the virus? Thanks for any input! angie@netcom.com [Moderator's note: See Tim Ruckle's note in this digest.] ------------------------------ Date: 05 Mar 92 17:16:00 +0000 From: timr@sco.COM (Tim Ruckle) Subject: Michaelangelo virus info for PC-bases UNIX system users (PC) (UNIX) [Moderator's Note: Forwarded by permission.] The Michaelangelo virus has generated a lot of media interest recently, as well as concern from many PC computer users everywhere. Most virus are targeted at DOS systems, which are particularly vulnerable due to their lack of protected mode operation and the absence of any security subsystem. Michaelangelo is a type of boot sector virus, and infects a system by moving the master boot record (sector 0 of the hard disk, which includes the partition table) and inserting the virus code in its place. A system contracts the virus if the machine attempts to boot an infected DOS floppy (note: it does not matter of the floppy itself it bootable). Thus it is possible for a PC-based UNIX system to contract this virus if the machine has tried to boot an infected DOS floppy. The virus does not spread via a network. The virus is set to trigger if a machine is booted on March 6th, and is reportedly not sensitive to a particular year. While it is unlikely that most machines that are used primarily for UNIX have been infected, and since many UNIX machines operate 24 hours a day, it is probably the case that very few PC-based UNIX systems will be effected by this virus. But the consequences of this virus are serious, and we would like to share the information that we have. However, virus prevention and detection should be viewed as only one facet of the complete data security picture. It is important to keep the discussion in this context, and treat the notoriety of this particular virus as an educational opportunity rather than an incitement to hysteria. The following information is intended to help users of all PC-based UNIX systems avoid damage due to the virus. It is our belief that the virus is dangerous to all versions of UNIX (in fact, all operating systems) for the PC. As previously stated, the virus is contracted when a system attempts to boot an infected DOS floppy. The system's master boot record is moved (to sector 6) and the virus code is inserted in its place. Note that the virus appears to be generally benign until triggered, so an infected UNIX system will likely boot and perform regularly, and will not give any indications of infection if the form of aberrant behavior of the system. You can look for a "signature" of the virus using UNIX system tools. At offset E8 hexidecimal (232 decimal) in the boot sector, a system infected with the Michaelangelo virus will likely have the hex values: 00e0 ** ** ** ** ** ** ** ** be 00 7c 33 ff fc f3 a4 00f0 2e ff 2e 03 7c 33 c0 8e ** ** ** ** ** ** ** ** You can examine the data on the hard disk with the hd(C) command, or with the od(C) command using the -x option (to get a hex dump). You are going to want to look at the device node that represents the entire boot drive. On SCO systems this is /dev/hd00 (this will vary on different UNIX systems, but is often named /dev/dsk/0s0). You will need to be root to issue the command. On a SCO system enter: dd bs=512 count=1 if=/dev/hd00 | od -x ...and look for lines that match those below (note that "****" is a wildcard that may stand for any value): 0000340 **** **** **** **** 00be 337c fcff a4f3 0000360 ff2e 032e 337c 8ec0 **** **** **** **** If these lines match the ones on your system, you have probably contracted the Michaelangelo virus. Another clue will be seen by using `hd` instead of `od -x`. The text comments which normally appear ("IO err. Bad tabl. No OS" on a SCO system) will be missing in those lines. The virus checks the system date at boot time. On March 6th, it destroys data on the boot device. It tells time by checking the PC's clock (via BIOS int 1Ah). It is important to note that (at least in the UNIX environment) the virus is triggered *only* at boot time. When triggered, the virus erases up to 17 sectors (8.5K) on each of the first 255 tracks of the boot device. This might or might not hit a UNIX partition, but it will definitely wipe out the partition table which allows you to access it. To keep from triggering the virus, one crude but effective tactic would be to insure that the PC clock does not display March 6th as the date. You can also make sure that you do not intentionally boot your machine on March 6th. To make absolutely sure that your machine does not reboot unintentionally (after a power outage or somesuch) you can leave a blank, *unformatted* floppy in the (boot) drive. There are dozens of anti-viral packages available, both commercially and as freely distributable code, to help protect systems and cure infected ones. Most of them know how to deal with the Michaelangelo virus. In today's paper there was an article that listed free inoculations available from various companies. Central Point has one on CompuServe (GO CENTRAL). Symantec has one on its BBS 408 973-9598 (2400 baud) or 408 973-9834 (9600 baud) and also on their CompuServe forum. Microcom VIRx 2.0 at 919 419-1602, with availability via the Internet and on CompuServe as well. WARNING: some DOS-based anti-viral packages do *not* know what a UNIX boot sector is and may destroy a perfectly functioning UNIX system. You need to make sure that any package you use is compatible with your particular system. SCO does not specifically endorse or recommend any of these products and is merely forwarding the information that has been reported. There is one anti-viral product which is being ported to the SCO platform. The product reportedly will check for both DOS and UNIX virus, and is scheduled to ship this month. The company is Cybersoft can be reached at 215 825-4748. In SCO XENIX and UNIX, you can restore the masterboot block by using the dparam(ADM) command with the -w option. This is typically only done if the masterboot block has been accidentally removed or corrupted, and should eradicate the virus by replacing it with a clean copy of the masterboot program. You can also rewrite the code part of the masterboot block manually on a SCO system by entering: dd if=/etc/masterboot of=/dev/hd00 bs=376 count=1 An equivalent command probably exists for other PC-based UNIX products, and you would need to check the manual for the proper syntax. You will need to be root to perform these functions, and should take care that you know what you are doing before attempting them. Once you have eradicated the virus you obviously don't want to boot any DOS floppies until they have all been checked for infection and dealt with accordingly. Again, computer virus protection should be just one concern in the overall context of data security. It should be given its due, but not at the expense of other--perhaps even more important--precautions. Always have adequate backups so that you can recover from data loss whatever the reason: be it human error, hardware failure, or deliberate malicious acts. But it is important to remember that PC-based UNIX systems are indeed susceptible to most DOS boot sector virus infections and one should always be careful about booting unchecked DOS floppy disks. I realize that because of the vagaries and delays of news propagation that some of you are reading this on or after March 6th, but I hope it proves useful in any case. Tim Ruckle - -- Usenet: !{uunet,ucbvax!ucscc,decvax!microsof}!sco!timr, ...!mcsun!ukc!scol!timr Internet: [MX handlers] timr@sco.COM [others] timr%sco.COM@ucscc.UCSC.EDU USPS: The Santa Cruz Operation, 400 Encinal Street, Santa Cruz, CA 95061-1900 PSDN: [voice] (408) 425-7222 [fax] (408) 458-4227 [twx] 910-598-4510 SCO SACZ ------------------------------ Date: Wed, 04 Mar 92 21:21:35 +0000 From: ampex!russest@decwrl.dec.com (Steve Russell) Subject: Re: Antiviral features in operating systems? Kevin_Haney@NIHCR31.BITNET writes: >Mark W. Schumann asks the question "Is it practical to include virus >protection in an operating system?" The answer is yes, not only is it >practical but I think it is a gross deriliction of duty of operating stuff deleted... >will the spread of virues begin to be curtailed. Organizations and PC >users who entrust mission-critical applications to supposedly >"advanced" operating systems have a right to expect built-in security >and antiviral features. I hope PC users will begin to stick up for >their rights. The problem is, virus protection will only be good for the first three or four hours of the o/s release. After that, the hackers will have started passing out new virii just for that o/s. What you're asking is just not practical for the o/s developer. Not enough time or money on a losing proposition. The same argument could be made on why don't o/s writers use some form of compression scheme on there executibles? - -steve ------------------------------ Date: 05 Mar 92 02:40:42 +0000 From: tabco@mtecv2.mty.itesm.mx Subject: Virus history question. Hello, I need information sources (magazine features, articles, ...) about the computer virus history. Also, description, kinds and all you can know about them. Thanks. "De antemano, gracias." Send references to InterNet address: tabco@mtecv2.mty.itesm.mx ------------------------------ Date: Thu, 05 Mar 92 03:37:06 +0000 From: prall968@Armstrong.EDU Subject: Re: Antiviral features in operating systems? Kevin_Haney@NIHCR31.BITNET writes: >Mark W. Schumann asks the question "Is it practical to include virus >protection in an operating system?" The answer is yes, not only is it >practical but I think it is a gross deriliction of duty of operating >system manufacturers not to have included even the basic antiviral >features yet. DOS 5.0 doesn't contain any integrity checking or (More stuff deleted...) I still do not see what many of these clone systems which claim to have multitasking abilities do not run a virus checker as a background task. On my Amiga I run Steve Tibbets Virus x5.2 and BootX both as background tasks. My system does not even feel the effect of both programs running. The ONLY slowdown I experience is the extra 3 seconds it takes to scan a floppy. Since I have scanned my HD with ZeroVirus I know the only source of infection will be by floppy. Can these 386 and 486 systems do this? Gene Prall prall968@pirates.armstrong.EDU ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 57] *****************************************