From virus-l@lehigh.edu Fri Oct 16 13:17:19 1992 Return-Path: Received: from csmes.ncsl.nist.gov ([129.6.54.2]) by first.org (4.1/NIST) id AA06146; Fri, 16 Oct 92 13:15:53 EDT Posted-Date: Fri, 16 Oct 1992 12:36:59 -0400 Received-Date: Fri, 16 Oct 92 13:15:53 EDT Errors-To: krvw@cert.org Received: from Fidoii.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA05080; Fri, 16 Oct 92 13:10:35 EDT Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA41418 (5.65c/IDA-1.4.4); Fri, 16 Oct 1992 12:36:59 -0400 Date: Fri, 16 Oct 1992 12:36:59 -0400 Message-Id: <9210161529.AA05310@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V5 #163 Status: RO VIRUS-L Digest Friday, 16 Oct 1992 Volume 5 : Issue 163 Today's Topics: Is this a virus problem?? (PC) Virus alert: "Larry on a Screen" (PC) VCL operation (PC) Re: Is there a new virus (720Kdisks) ? (PC) BIOS functionality at bootup (was the C: the A: saga..) (PC) is nav good ? (PC) Re: How trojans work. (PC) Re: Recent IBM Virus List? (PC) Virus Scanner Reviews (PC) Information about Brasil virus (PC) Could FORM infect OS/2's BOOT.DOS file (OS/2) re: Review of VDS (PC) Re: more network security Re: Product Test 45, Virus Prevention Plus, version 5.10 (PC) Re: network security Re: The Harmless Virus Re: A less virus prone architecture replies to some questions Contact information for Fred Cohen and ASP MacMag, the commercial virus (CVP) 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@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: 08 Oct 92 00:08:03 +0000 >From: gt7187c@prism.gatech.edu (Thomas Oates) Subject: Is this a virus problem?? (PC) Is there a virus out that can cause a computer not to boot when I/O ports are installed? Mine will not boot when I try it with an I/O card installed. (tried 3 cards, so chances are it is not the card). THe reason I think it could possible be a virus is that when it does actually boot (with no I/O) it does virus-like things such as: completely hanging for no apparent reason, incorrect dir listings of a,b drives, repeating commands for no reason. Can a virus actually do this? I tried Norton antivirus with no success and also an older version of SCAN which found nothing. So, could this be a virus or should I take the computer in for a tune-up???? THanks, Thomas Oates - -- Thomas Oates MS Windows...From the same people who gt7187c@prism.gatech.edu brought you edlin...... Prodigy NGDR20A How you gonna do it?? Georgia Institute of Technology OS/2 IT!!!!! ------------------------------ Date: Fri, 09 Oct 92 00:14:49 +0000 >From: brian@probitas.cs.utas.edu.au (Brian Marriott) Subject: Virus alert: "Larry on a Screen" (PC) A virus has shown up in Tasmania, Australia, which we haven't seen reported before, and which isn't known by name to F-Prot 205 or TBScan 43 (although they both pick it up by heuristics). We have only analysed it far enough to get its name and an ID string; we don't know potential damage. Name: Larry on a Screen Infects: .EXE & .COM files (at least) .COM files seem to grow by 491 bytes, .EXE files by a varying amount ( we saw 403 & 507 bytes ). Signature strings: "Larry on a Screen" Hex: "50cbbf00018b750181c6d90257b90500fcf3a481" Further information may be obtainable from: Russell Twining (R.Twining@eee.utas.edu.au) Brian Marriott (B.W.Marriott@cs.utas.edu.au) - ----------------------------------------------------------------------- Brian Marriott, Department of Computer Science, University of Tasmania Mail: GPO Box 252C, Hobart, Tasmania 7001, AUSTRALIA. Ph: +61-02-202929 Internet: B.W.Marriott@cs.utas.edu.au Fax:+61-02-202913 ------------------------------ Date: Thu, 08 Oct 92 19:37:12 -0400 >From: fc@turing.duq.edu (Fred Cohen) Subject: VCL operation (PC) I have been trying to get VCL to operate on my system, and I think the authors don't know how to write compatible code. Does anyone know how to get it to work on a 286 with a black and white screen (HGA)? Or do the virus creation lab people only design their VCL for those with lots of money? I suppose it's only for elite virus writers, and not for the rest of us. FC ------------------------------ Date: 04 Oct 92 17:07:10 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: Is there a new virus (720Kdisks) ? (PC) Thus spake U8945535@csdvax.csd.unsw.EDU.AU: >I have heard a rumour that there is a virus that will prevent 720K >disks from being read or formatted. This virus apparently does not >affect 1.44K disks. The EXEbug virus (seemingly written in South Africa and now very, very widespread here) has, as one of its most noticeable giveaways, the side effect that floppies can't be formatted on a infected machine. EXEbug's stealth replaces the INT 13 Format call with a Do-Nothing-But-Say-You-Did call to "protect" the boot sector of discs. So, when FORMAT verifies Track 0 (as it does, because of its importance, thanks to the DOS floppy layout) it gets somewhat upset to see that the boot sector didn't actually get succesfully formatted! Result: "Track 0 is bad - diskette unusable". This side-effect will, however, be observed on discs of all capacities. Floppy disc drive salesmen are having a great time right now, especially if they get to keep the "failed" drive they're replacing :-) A virus which doesn't affect (infect?) 1.44M discs and which prevents 720K discs from being read (ie: used..) would seem to be a seriously brain-damaged virus indeed.. - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 05 Oct 92 09:03:41 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: BIOS functionality at bootup (was the C: the A: saga..) (PC) The trend amongst BIOS manufacturers to provide a CMOS-configurable option to allow you to inhibit bootup from floppy disc has been rather staunchly raved about of late in comp.virus. Yet Boot Sector viruses continue unabated. Unfortunately, the interface which allows you to select the BIOS bootup mode usually lets you choose, during CMOS setup, between "Boot sequence C: A:" and "Boot Sequence A: C:". Once you've chosen, you get no feedback during subsequent bootups to remind you of the configuration. If you go back to the "A: C:" sequence in order to let yourself boot from floppy, you need to remember to reselect "C: A:" next time. Much better would be, when in "A: C:" mode, for the BIOS to ask for confirmation before booting from A:. This would serve three purposes: firstly, to remind you to switch back to "C: A:" mode; secondly, to avoid accidental floppy bootup and, lastly, to assure you that any bootup from floppy disc really was originated by the BIOS. A virus like EXEbug boots from floppy by a devious route -- it alters the CMOS setup to force bootup from your hard disc and then, after loading itself from the hard drive into memory, switches over to boot from floppy if you have one inserted. This means that what seems to be a clean boot is actually no such thing! If the BIOS were to ask for confirmation before initiating a floppy bootup, the subterfuge of viruses like EXEbug would be obvious. BIOS manufacturers, what say ye? - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 09 Oct 92 15:00:54 +0000 >From: cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi) Subject: is nav good ? (PC) We recently got Norton Desktop 4 Windows and it installed nav ( anti virus ) in config && autoexec. is it the best [de][anti]virus or I can find a better one ? - -- - -------------------------------------------------------------------------- ! /|/| /| \ / ! Massimo Cotrozzi Computer Science Dept. Milan Italy ! ! / | /-| \ ! cotrozzi@ghost.dsi.unimi.it ! !/ |/ | / \ ! massimo@cdc835.cdc.polimi.it ! ------------------------------ Date: 09 Oct 92 12:50:02 -0500 >From: 739chan1@gw.wmich.edu Subject: Re: How trojans work. (PC) AHARDISON@intel9.intel.com (FIRED UP...ALL FIRED UP...PRG 2026) writes: > Hello, My name is Andy Hardison and I am a BBS sysop with a problem. > I was notified by a user of a program that scanned clean, but when > run, caused a Michaelangelo infection. > > Here is what I was told, Xyphr.zip was unzipped to form the game > files, Xyphr.exe, .dat, etc. When trying to run Xyphr, the computer > would hang. My user rebooted the computer with a CTRL-ALT-DEL. Since > he thought it was a memory problem, he ran Quarterdecks Manifest, mft. > He thought he was running MFT.exe, but there was a 300 or so byte > MFT.com file present. > > He typed in MFT and his computer locked up again. Upon a second > reboot, with an actual powerdown, the computer lost some files. He > scanned with Fprot and McAfee. Both reported Michaelangelo in the > boot track. > > Could someone out there explain to me how Michaelangelo could have > gotten onto the system via this method of infection. My user is more > paranoid about virii than I am (I scan all incoming files, but do not > run the executables). He did not have an infected computer before > running Xyphr, but did after the above mentioned sequence of events. > Any help would be appreciated. I would think that the program wrote the Michelangelo virus strings to the partition table. Try running F-PROT on the file. It will detect Boot sector/Partition table viruses even if they are not in their respective places. (e.g. in an image file) Don't erase the file; send it to MCAFEE assosiates (makers of SCAN) or Fridrik Skulason (F-PROT). __________________________________________________________________________ Chan Lee Meng \ "Let us endeavour to live so that when we die, 739chan1@gw.wmich.edu \ even the undertaker will be sorry." X92chan3@gw.wmich.edu \ - Mark Twain. Western Michigan University. \ ------------------------------ Date: 09 Oct 92 18:11:41 +0000 >From: frisk@complex.is (Fridrik Skulason) Subject: Re: Recent IBM Virus List? (PC) mechalas@mentor.cc.purdue.edu (John Mechalas) writes: >was too late to edit the article after I sent it. :) I meant, can it >be removed by disinfectant software, or must it be replaced? This is, >however, essentially irrelevant, since the best "cure" for an >infection is to *always* replace the offending files with clean >backups. So just ignore this one. :) Well, it is an interesting question. Assuming the virus has been accurately identified, there are several possible answers. 1) The virus can never be disinfected - this is true for overwriting viruses. 2) The virus can be removed, but the resulting program will not be 100% identical to the original. For example, it may have grown by 1-15 bytes or a non-critical field in the EXE header may be changed (the checksum field, for example) 3) The virus can usually be removed, but it may damage some programs, and that damage may not be detectable. Jerusalem, for example. 4) The virus can be removed, and the resulting program will be identical to the original one. - -frisk ------------------------------ Date: 09 Oct 92 18:31:10 +0000 >From: frisk@complex.is (Fridrik Skulason) Subject: Virus Scanner Reviews (PC) There were two reviews published in British computer magazines this month. One (in PCW) was badly done - in fact, my opinion is that they should officially apologize next month. They used an incredibly small set of virus samples, modified the infectedd programs in order to disable the viruses, and checked which programs were still able to detect the viruses. When they discovered that some of the anti-virus programs did not detect some of the viruses, they considered this highly significant and an indication that the programs were not protecting the users. My program was not included in that review, so I don't have any reasons to be upset, but..... The other review (in PC Direct) is surprisingly well done - I am personally quite satisfied with my outcome there, but according to that review some of the anti-virus programs on the market are, well...not quite as good as they should be, to say the least. In one case the review starts like this: It is rare to find a program as bad as ....... The poor impressions started on opening the box, to reveal the software on two write-enabled disks. We write-protected them before installation, but the install procedure wanted us to remove the write protection to enable any viruses found to be cured. ... The program is incredibly tedious to use, requiring several keypresses between each disk or virus and there is no option to produce a printed report ... The monitor claimed to have detected a virus every time we loaded Windows 3.1 ... The distributors offer unlimited free upgrades via BBS...We called the bulletin board: this turned out to be the "The Dog and Disk BBS" and we were greeted with the information that "Richard was in the bar" Now, I usually don't like to say bad thing about my competition :-) but in this case I just could not resist... ------------------------------ Date: Fri, 09 Oct 92 19:09:42 -0400 >From: weber@inf.ufrgs.br (Raul Fernando Weber) Subject: Information about Brasil virus (PC) I have obtained a copy of the "Brasil virus" and partially disassembled it. Here follows the results: This analysis is based upon the virus sectors found in a 360k diskette, forwarded by Joseph Max Cohenca , from University of Sao Paulo, Brazil. 1. The virus is not detected by any anti-virus software available now (5th October 1992). F-Prot 2.05 doesn't detect it, neither in "secure mode" nor in "quick mode" nor in "heuristic mode". Scan v95b detects a "Generic Boot Infector", but this is just a warning saying that SCAN did not discover the normal DOS boot code in the disk. 2. The virus is a bootstrap virus, and seems to be a new one; either it is an original Brazilian virus, or it is a very modified copy from some existing virus (like Stoned or Michelangelo). 3. The virus occupies three sectors of a disk. The first sector, that substitutes the boot in diskettes, or the master boot in hard disks, contains the initial activation code of the virus, which is executed when the machine is powered up or rebooted. The second sector contains the virus code that becomes memory resident, and that is responsible for propagating the virus. In the third sector the virus stores the original boot sector. 4. In hard disks the virus uses for his three sectors the sectors 1, 2 and 3 of cylinder zero, head zero. To eliminate this virus, sector 3 (the original master boot) should to be copied back into sector 1. 5. In 360k diskettes the virus uses DOS sectors 0, 10 and 11 (this means sector 1, cyl. 0, track 0 (boot), sec 2 cyl 0 tr. 1 (sector 10 and sect 3 cyl 0 tr. 1 (sector 11)). Sectors 10 and 11 are the end sectors of the root directory, and the virus may overwrite directory information during the infection process. To eliminate the virus sector 11 into should be copied back into sector 0. 6. The virus handles correctly other diskette types (720k, 1.2M and 1.44M), hiding his three sector always in the boot sector and in the last two directory sectors. 7. The virus test his own presence through the addresses hex 01A8 and 01A9 of the boot sector. If these two bytes are CF CF, the virus assumes it already infected the disk. If not, it then proceeds to infect the disk. 8. The virus intercepts only interrupt 13H (Bios Disk services). 9. The virus uses stealth techniques to avoid his detection. Any read access to the boot sector is redirected to the sector where the virus stored the original boot sector. 10. During his attack, the virus writes "Brasil virus!" at the current cursor position at screen. This text ("Brasil virus!") is stored scrambled in the second virus sector. 11. The virus infects only diskettes in drive A:., during read operations. A single "Dir" command is enough to infect a diskette. 12. In order to trigger his attack, the virus sets a counter when it infects a hard disk. This counter is decremented after each hour that the computer is in operation. After 120 hours of effective use, the virus writes his message ("Brasil virus!"), writes random data in the first 50 cylinders of the hard disk and the "freezes" the computer. Obs: This "trigger routine" needs further investigation. I haven't disassembled it completely. A specific program to detect and eliminate the "Brasil virus" was written in the Informatics Institute of the Federal University of Rio Grande do Sul (UFRGS), Porto Alegre, Brazil. It is available through anonymous ftp from the site caracol.inf.ufrgs.br (143.54.2.99), directory pub/virus/pc, file antibras.zip. Raul Fernando Weber, Prof. Instituto de Informatica - UFRGS Av. Bento Goncalves, 9500 - bloco IV Caixa Postal 15064 91501-970 Porto Alegre RS tel: (051) 336 8399 r.6805 fax: (051) 336 5576 e-mail: weber@vortex.ufrgs.br or weber@inf.ufrgs.br ------------------------------ Date: Fri, 09 Oct 92 04:40:31 -0400 >From: Bill Peel Subject: Could FORM infect OS/2's BOOT.DOS file (OS/2) A colleague has a PC which can dual boot to either DOS or OS/2. Both Jim Bates's VISCAN and F-PROT v2.05 report that the file BOOT.DOS in C:\OS2\SYSTEM contains a FORM image. After booting from a clean floppy the size of BOOT.DOS reported by a dir is 512 bytes and the date/time stamp is similar to that of other files in the directory (I know viruses can fiddle this). The usual FORM message is not in the file. My colleague says (I haven't had time to check this) that she cannot find BOOT.DOS on any of the original OS/2 disks. On the hard disk it is hidden/readonly. Could any of the experts say whether this is a real infection and if so how to recover from it. We have had infestations of FORM on both floppy disks and DOS-only hard disks. Thanks Bill Peel PS For information, over the last 18 months we have cleaned up: Stoned, Tequila (not pleasant), Yankee Doodle, Ping Pong, Green Caterpillar and Dark Avenger/Eddie. Dr W E Peel za9ra01@sa.cs.manp.ac.uk Computing Services Manchester Metropolitan University Manchester M1 5GD England ------------------------------ Date: Thu, 08 Oct 92 02:45:28 -0400 >From: "Tarkan Yetiser" Subject: re: Review of VDS (PC) Hello everyone, rslade@sfu.ca writes: > Subject: Review of VDS (PC) > As usual, I have given the developers a chance to respond to the draft > i have made some minor changes on the basis of this response, but I > suspect that Tarken will be responding to this review at great length. Looking at the "review", you barely read our response :-) BTW, the name is Tarkan, sir, not Tarken. As far as a lengthy response goes, I will not waste bandwidth since the stuff you posted does not seem to be about VDS. Worse yet, it omits major features of the package and it does not even mention how it handled a common virus infection. Considering that no criteria is given in any of your evaluations, we have to say that there is no context in which some of your comments make sense. We think that the main principle of reporting performance evaluations should be reproducibility. Please share with us and the rest of your readers how you go about testing products. We have the impression that your "methods" are ad hoc and cannot be taken seriously. Hope we are mistaken. The sad part is that you are giving your readers an incomplete picture. Reviewing an integrity package is not the easiest thing to do, compared to the simplicity of scanner zoo-testing; and to some extent, gross inaccuracies in your posting are understandable. Individuals who wish to look at VDS can do so by downloading a copy of the trial version (fully functional with a few features missing) from many FTP sites, including Simtel-20 and its mirrors. And if anyone finds that the F1 key does not do anything perceptible as you say, we would like to hear :-) VDS is a very comprehensive package with carefully selected components. The documentation may not do justice to each one; however, calling it flippant or containing little substantive material is ludicrous. And if it maintains a sense of humor at certain points, that is for those who can appreciate such an approach. It is readable, unlike many others you would see. In the light of what you call a "review", I cannot help but quote a sentence from our "flippant" documentation: "... Similarly, some product reviewers get their stopwatches and virus samples ready and babble the same old rhetoric about the numerous (but irrelevant) features of these anti-viral programs. This situation hurts the end-users in a non-obvious way: it adds to the existing confusion about what the problem is and what a good solution should entail." VDS 2.10 documentation, page 3 Have a nice day of virus-free computing! P.S.: VDS Pro 1.0 is in beta-test phase, and it should be available in a few weeks. Interested individuals can send me e-mail and I will try to answer any questions as my time permits. Regards Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228, U.S.A. e-mail: tyetiser@ssw01.ab.umd.edu ------------------------------ Date: 04 Oct 92 17:39:55 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: more network security Thus spake seborg@csrc.ncsl.nist.gov (Brian Seborg): >Vesselin Bontchev writes: >>As a conclusion, it is a bad idea to rely on virus disinfectors. >>Just delete the infected programs and replace them with clean >>backup copies. >I am glad that you have finally reached this conclusion. :-) We >have been saying this for years! Hey, Vesselin (and anyone else with enough suss to count, myself [ahem] included..) has been saying this to anyone who'll listen (and many who won't) for ages. I've never seen him suggest anything *but* the deletion of infected files, in fact.. BTW: "reinstalling" infected binaries can indeed be painful these days. It's no longer a question of copying .EXEs from original floppies onto your HDD. We're seeing increasingly cryptic distribution discs, with custom compression and no easy way to pull off a single binary. Once you've got a clean installation of a whopper-app (try BC++ 3.1 with Application Framework if you're keen on ___big___) with things set up how you like, try making an "as installed" copy to tape. Could save you a lot of frustration if someone deletes one or two of those seemingly redundant configuration/setup/hey-what's-this files.. - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 04 Oct 92 17:21:40 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: Product Test 45, Virus Prevention Plus, version 5.10 (PC) Thus spake padgett@tccslr.dnet.mmc.com (A. Padgett Peterson): >2) Tandon - uses a custom BIOS that actually checks the BIOS for a valid > partition table (bravo !), Not quite sure what this means -- especially since the partition table is not part of the BIOS [or is there a version of FDISK out there which can remask ROMs while they're in use :-)]. Assuming that the second "BIOS" should read "HDD", then so what? Most MBR viruses leave the partition table intact, altering only the *code* zone of the MBR, so an integrity check of the partition table at BIOS level will show nothing wrong. Lastly, if "partition table" should read "MBR" (ie: code+table), then what constitutes "valid"? There are lots of "valid" partition record boot loaders out there -- the FDISK one, Coherent's multiboot one, XYZ Corp's multiconfig one, etc. Seems like defining "valid" partition record boot loader might be a bit tricky, and even trickier to implement an algorithm to perform the "validation"... - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 04 Oct 92 17:28:45 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: network security Thus spake seborg@csrc.ncsl.nist.gov (Brian Seborg): >Vesselin Bontchev writes: >>and StarShip, I think) will not >>infect, if you don't have a hard disk - because they don't go >Wrong about Tequila, it infects just fine. Remember, it is a >multi-partite virus and it does go TSR. Vesselin is right, in fact. Tequila requires a hard drive. It doesn't go resident when you run an infected file -- it merely "primes" the MBR to load the virus next time you boot up from hard disc. No HDD, no Tequila in memory.. Still, T.Tequila's gamble that you've got a hard drive on your PC is a relatively safe one :-) - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 09 Oct 92 10:22:20 -0400 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: The Harmless Virus >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >WHMurray@DOCKMASTER.NCSC.MIL writes: >> This is a simple oversight, but writing the perfectly harmless virus >> requires this knowledge plus perfect knowledge of all other relevant >> factors about every system in the population. Such perfect knowledge >> is impossible. >The above is, of course, true, but it also holds for any program, not >just for viruses. As we leave the "first generation" of PC programmers, this is becomming more and more evident. Lately the amount of *bad* code from major manufacturers is increasing, not deacreasing. One example is the rising number of "do-it-all" packages that do not seem to know how to handle removable drives. First it was NAV and NDW that would get upset if I did not have a disk in my Bernoulli drive, now we can add Addstor's "SuperStor Pro" Windows element to that list. In another example of "someone who should know better", I saw the use of 286 instructions in a program for "all PCs". Wonder what compiler they were using ? The most recent is the discovery that a particular MBR error will render a system unbootable from floppy with MS-DOS 5.0 (and 6.0 beta). You can still use 4.01 & earlier but then will not be able to use FDSIK /MBR. (Booting from a lower DOS and expert use of DEBUG can restore everything though). Saw this in a security product that touted prevention of floppy boots - - guess the author was not aware of earlier DOS versions 8*( In short, lately there seems to be a regrettable decline in the quality of the gigantic software packages reaching the market today. More disturbingly, often when I call to report such bugs, the only person reachable obviously has no idea what I am talking about and has no inclination (possibly by direction) to pass me on to anyone who does. Must admit that often I'll call the publicised numbers just to find out what will happen to Joe Public. Recently was on hold for 45 minutes (luckily I had a good book) only to finally reach a security operative - tech support went home 15 minutes earlier. One I enjoyed the most was a recording announcing that I had reached TS "after hours" and being advised to call back "between 9 am and 4 pm PST, Mon-Thurs". It was. On the plus side, the quality of hardware seems to be improving. BIOSes are now allowing not only boot selection but providing password protection (would like to think that this is a result of our prodding). In the last week I have seen notice of disk controllers with hardware implimentation of disk compression built in and a single chip AT-Ethernet interface. Have just upgraded to a Maxtor 7213A disk in my "big" PC. Called to ask about documentation. Two days later a thirty page tech document arrived telling me not only everything about the drive but also quite a bit about IDE drives in general (also available in SCSI). With a street price of under US2.00/MB and dropping, this may be the new standard (will have to see if the logetivity will match my MK-1 ST-412 10 MB drive that was my telephone stand for a few years before its current compressed use in an 286 based answering/fax machine). IMHO networks are going to be what will slow/stop the spread of common viruses since they do not have to be subject to the "Turing halting problem". However, this applies only to a true client/server network exhibiting dual state operation (client-server) and state isolation, *no* peer-peer network that I have seen need apply since they are all collections of single state machines. Unfortunately, this condition "just happened" and I have seen little interest by the manufacturers (with the possible exception of Novell) in making this a central strategy. We can hope. Warmly, Padgett ps At DEBUG offset 4368h into DOS 5.0 Command.Com I found the byte pair "B7 07" changing the 07h to 17h "fixes" a CLS to return a "sticky" White on Blue screen on a colour display instead of White on Black. The first nibble is the background colour, the second is the foreground. Note: after changing a reboot is necessary otherwise an "invalid COMMAND.COM" message may occur. No guarentees 8*). ------------------------------ Date: Fri, 09 Oct 92 13:54:12 -0400 >From: Douglas Allen Luce Subject: Re: A less virus prone architecture Excerpts from netnews.comp.virus: 5-Oct-92 A less virus prone architec.. robert j kolker@world.st (1066) > A Babbage machine differs from a Von Neuman machine, in that its > program is external stored on a medium separate from the data store of > the machine. In the Von Neumann architecture, the program is a state machine, and the data is the ticker-tape (or dual stack). They are distinct entities, and no definition is made on where they lay in storage. In today's the Von Neumann computers, the actual "program" state-machine is embodied in the hardware of the computer, while the "data" consists of microcode, the OS, and application programs, as well as the data they require. Modern computers also emulate Babbage machines; there is generally some ROM code in them that is unalterable by viruses. It's very hard these days to make a distinction between program and data on an arbitrary level of abstraction. Doug ------------------------------ Date: Fri, 09 Oct 92 16:49:11 -0400 >From: Brian Seborg Subject: replies to some questions Robert Kolker asks: > Is a computer, in which the program is stored in a totally separate > memory space from data, less prone to virus attack or n space from > data less prone to virus attack or not. Good question! I guess the answer depends on whether that seperate memory space is protected or not. If the separate memory space is write-protected, for example, imagine a program which resides on a protected network drive, it is both external to the system, and protected and is protected from virus infection from all users (with the exception of administrators). Now, if this program is not on a protected memory device, or if it is copied to a non-protected memory device, then it can be infected. In the case where it is copied, the original remains un-infected, but the new copy on the non-write protected memory device would be infected. I hope this answers the question. :-) Andy Hardison asks: (I will paraphrase for the same of brevity) A bbs user he has claims to have run a program from his bbs which caused Michelangelo to infect his disk. How could this happen? Again, good question. The only way this could have happened is that the program in question would have to be a "dropper" program. Dropper programs are programs used to place other virus programs onto the boot sector of a disk or into a host program (for executables). While this is possible, I would think that getting hold of such a program for Michelangelo would be unlikely. If you have the file, dis-assemble it and see for sure. It is more likely that your user did himself in by infecting himself with the Michelangelo virus, and he is looking for a scapegoat. A good disassembly of the code would remove all doubt. Since the Michelangelo is an MBR and boot-sector infector only, it can neither be spread by a program being copied down from a bbs (unless it IS a dropper), nor can it spread via a network. Sincerely, Brian Seborg VDS Advanced Research Group ------------------------------ Date: Wed, 07 Oct 92 22:27:55 -0400 >From: fc@turing.duq.edu (Fred Cohen) Subject: Contact information for Fred Cohen and ASP Many readers of this forum have recently requested various documents and information on recent advances in information protection from me at my Brisbane computer mail address. As I am now back in the US, I have a new computer mail address. Please address further computer generated requests to: fc@turing.duq.edu or physical mail to: ASP, PO Box 81270, Pittsburgh, PA 15217 Thanks - FC ------------------------------ Date: Thu, 08 Oct 92 10:05:58 -0700 >From: rslade@sfu.ca Subject: MacMag, the commercial virus (CVP) HISVIRE.CVP 920905 MacMag virus - Commercialism Surely the most renowned aspect of the MacMag/Brandow/DREW/ Compuserve/Macinvirus virus was that it holds the dubious distinction of having been the first virus to infect commercial software. The president of a company producing educational material for computer training visited Canada. He was given a copy of the "Mr. Potatohead" program. (At a party, by one report.) It was infected. At home, he ran the program. Once. In his office. Thus infecting his computer. The training company, MacroMind, some time later delivered some training software to Aldus Corporation. Aldus was, at that time, preparing the release of its then new "Freehand" drawing product. Computers at Aldus were infected with the virus, and it eventually spread to the production copy of the Freehand program. Three days production of the program were infected (by one report 7,000 copies, by another 10,000). An unknown, but fairly large number had already been distributed by the time the infection was discovered. At the time, MacroMind's customers included Microsoft, Lotus Apple and Ashton-Tate. Ashton-Tate consistently refused comment, the others all, at various times, denied any infection, and none was ever found coming out of those companies. (Some other historical notes. John Markoff, with far less accuracy than he has shown of late, reported that the virus was a product of the "Cult of the Sub- Genius". He also reported some amazingly inaccurate information about the Sub-Genii themselves. We also have, in some of the reports of the virus, the first of what has come to be standard in media reports of viral programs, the warning to avoid shareware and only use commercial software. Very interesting that this particular canard should have started with this particular virus.) With the furor from the Compuserve reports, and the media attention to the Aldus infection, it is unlikely that the virus was every triggered other than by those who wanted to see the display. copyright Robert M. Slade, 1992 HISVIRE.CVP 920905 ============== Vancouver p1@arkham.wimsey.bc.ca | You realize, of Institute for Robert_Slade@sfu.ca | course, that these Research into rslade@cue.bc.ca | new facts do not User p1@CyberStore.ca | coincide with my Security Canada V7K 2G6 | preconceived ideas ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 163] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253