VIRUS-L Digest Wednesday, 6 Nov 1991 Volume 4 : Issue 211 Today's Topics: computer virus ^2 Taxonomy Hardware... Virus removals vs. Virus classification Efforts Re: where can I get a copy of "When Harlie Was One"? Re: Disk Compression (PC) Re: Questions about VIRLIST.TXT (PC) Re: from fidonet virus conf: new virus found? (PC) Re: Zipped files (PC) Am I infected ? (PC) Availability of "Harley" book DOS viri on the MAC... (PC) (Mac) Re: Regulation of (Medical) Software RE: Virus Proof Machine Response Re: McAfee84 failed to remove Joshi Problem with Stoned virus (PC) ViruShell - New Shell for SCAN - Great (PC) fprot201.zip on risc (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Mon, 04 Nov 91 20:34:39 -0500 >From: spaf@cs.purdue.edu Subject: computer virus ^2 We've heard all about the usual stealth computer viruses and "armored" viruses that are being written these days. It seems that in some places the writing of nasty viruses has become a national pasttime. Some of these authors delight in finding new methods of damage and camouflage. The problem has mainly been for IBM PCs, and the most sophisticated virus-writing has been in Bulgaria and the USSR. Now, however, we have a new and far worse problem from South America, according to the November 12th issue of the "Weekly World News." [This is the "newspaper" you may find at supermarket checkout lines with the kind of headlines you don't see in the more mainstream media. Obviously, a conspiracy by the mainstream media. The November 12th issue is headlined with "Ohio Woman has a 3rd Eye -- in the back of her head!"] On page 7, there is an article by one Sally O'Day, "special to the WWN," and entitled: "Demon Computer Kills 2 Workers!" It is subtitled "Exorcist called in after experts discover virus-bred evil spirit!" The article goes on to explain how a computer system installed in a bank in Valparaiso, Chile is possessed by a demon. A consultant from the computer company that installed the system claims that it must be the result of a virus installing an evil demon that has caused: * observers to see a hideous horned demon appear on the screen * anyone who tries to turn off the machine to black out and fall to the floor * Carmen de la Fuente to have a fatal heart attack within 2 minutes of sitting down at the terminal * Maria Catalan to be found sitting at the terminal with her head in her lap [decapitated, I presume, rather than a contortionist] * a computer expert to began babbling like a madman when he got within 10 feet of the terminal This brings up many interesting questions: -- How long before commercial anti-virus vendors start advertising that their products work against this type of virus? -- Does the exorcism ritual end with extinguishing the candle, closing the book, and sounding the BEL? -- Could this actually be the result of using Ada rather than a virus? -- Do you know any computer experts who don't begin to babble when within 10 feet of a computer? -- Does normal business insurance cover an exorcism? -- Maybe it's a Unix system and this is the first time they've seen the sendmail daemon? -- Will Fred Cohen allow this to be entered in his virus-writing contest? Or, it could be that Ms. O'Day has recently seen the movie "Evilspeak"? [If you have yet to see the movie, rush right out and rent it. Lay in a supply of beer and pizza, and invite the neighbors over. It is a classic wherein a nerdy Ken Howard (Ron's little brother -- the one who used to hang out with Gentle Ben) summons up the devil on an Apple II computer. He should have guessed something was amiss when he started getting Stardent-level graphics on his little Apple, and when it started demanding blood sacrifices. The credits include mention of the "stunt demons" and "Satan's Sows." Not to be missed.] Hey, it must be true if they printed it, right? :-) ------------------------------ Date: Mon, 04 Nov 91 20:22:57 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Taxonomy Writes frisk@complex.is (Fridirik Skulason): > Maybe the following may start some useful discussion.....here > is a list of the PC virus families I currently recognize - in > alphabetical order. > ........................ (long list of virus names deleted) > ........................ Those are not virus families, those are single virus names. Since no information whatsoever is given as to which viruses he would like included in each of these "families", the list is not very useful. The list consists of over 270 names. How does it relate to the NIST proposal? Is it being suggested that known viruses should be simply divided into 270 "families", without any rationale being presented for such division, without even listing what individuals fall in each "family", or why? That seems rather sloppy. At this rate, it might pay to just leave them alone, unclassified. Who needs classification, if the first level of subdivision consists of 270 taxa! :-(( Fred Waller turtle@darkside.com ------------------------------ Date: Mon, 04 Nov 91 20:20:28 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Hardware... Writes frisk@complex.is (Fridrik Skulason): > Correct - and this hardware already exists - it is known as > the "off switch" - simply leave the computer off at all times, > and it is 100% secure against viruses. This is an original solution and should be implemented at once. Thanks to Fridirik Skulason of Iceland. We need more suggestions like this one! > Protected mode is dependent on hardware capabilities EVERYTHING that happens on a computer is dependent on hardware capabilities. Including viruses. And antiviruses. > (Protected mode) ...can be circumvented, Correct. It can be circumvented, and offers no inherent protection against malicious software, any more than any other software. Which illustrates that no software protection is ultimately useful; it can always be defeated by other, newer software. > ...just as any hardware "solution". False. Hardware offers inherent protection which is totally undefeatable by software in the realm where applied. This is not true of software. Runtime software is a function of hardware, but not the other way around. Hardware protection is permanent. Doesn't need to be updated for each new software attack. > If the computer is not an embedded system, That's one "if"... > if it ever runs programs "from the outside" ...and that's another "if"... > and is designed to allow "useful stuff", like program > development, ...and a third "if". Fortunately, most computers in the world are not used for writing programs, and some restriction of the other parameters is readily allowable. > it is possible to write a virus for that system, > REGARDLESS OF ANY ANTI-VIRUS HARDWARE ON THAT SYSTEM! Well, if I were a software publisher, I'd probably say the same thing. A virus can be _written_, of course (anything can be written), but it cannot defeat sensible but simple hardware protection. Ever. Fred Waller turtle@darkside.com ------------------------------ Date: Mon, 04 Nov 91 20:22:03 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Virus removals vs. Virus classification Writes frisk@complex.is (Fridrik Skulason): > This is not what was being said - What Vesselin Bontchev wrote was that because some virus-removal program managed to remove a certain virus from an infected file, then that virus must belong to the family of viruses for which the removal program was designed. First, the inference is not strict. Second, the "family" he was talking about remains un undefined entity. Third, from a technical standpoint, the use of a curing program to make a taxonomical classification is abominable. > The program in question is able to determine... A program isn't "able" to do anything. It does whatever it was programmed to do. Period. > ...that the Fu Manchu virus is related to Jerusalem, that it > is structurally very similar, It doesn't determine any such thing. It only determines its infective effect on the file, not the virus' structure. A great many viruses append themselves to the end of infected files and will change the beginning of the program to point at the virus so that it gets executed first. If the size of infection and other changes can be determined accurately, the virus can be removed and the original program restored. All this has little to do with "structural similarities" of the code, except in a most general and elementary way. > and that it can be removed in a similar way. Many viruses can be removed in a "similar" way. It doesn't mean they are taxonomically related. Note that I'm NOT SAYING that the Fu Manchu virus DOESN'T belong to the Jerusalem family - it may or it may not. But using a virus- removal program as a taxonomical tool is improper - it isn't intended to be one UNLESS everybody agrees that all our virus classification will be done not on the basis of virus structure, nor on the basis of virus behavior, but on the ability of somebody's virus remover to recognize them... clearly a ridiculous proposition. Fred Waller turtle@darkside.com ------------------------------ Date: Mon, 04 Nov 91 20:24:25 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Efforts Writes padgett%tccslr.dnet@mmc.com (A. Padgett Peterson): > the effort required to breach a software defense is greater > than that required to erect it. This comes about because the > defender has the advantage of being on home ground & has a > "world view" of the system. I believe this is not true. As said earlier, virus-writing is not a cost-conscious activity, while antivirus protection most definitely is. Virus authors have the luxury of spending hours, days, weeks or months probing and testing until they find a weakness. Antivirus authors work to earn a living, sell their products and must perforce be cost-effective. It's really just the reverse of what Padgett claims. And it's not true that defenders are "on home ground" while the attacker is not. Some virus writers seem definitely better acquainted with PC hardware and software than any antivirus publisher I know. Witness, for example, the Whale affair. Anyway, the proof of the pudding is that, until now, the antivirus publishers have been reacting to attack, and usually unable to keep up. To this day, the antivirus publishers have been unable to take the initiative in the virus/antivirus contest. > The attacker on the other hand is faced with a two-dimentional > viewpoint and must peel away a layered defense like an onion: > each layer may reveal a new defense structure - a very hard task > to automate since the attack being via software means that the > attacker must anticipate ALL possible strategies while the > defender needs only one (hopefully unknown). If the attacker thought as simply as the defender seems to in this case, the attack would indeed be made layer-by-layer, as Padgett suggests. But it's often possible to bypass all of those "layers" in one shot. Quite a few viruses have done that. It's all a matter of ingenuity. All it takes is to find a new FORM of attack, and all the layers become useless. It's been done many times, as Padgett must know. For example: one can protect each and every executable and data file on disk with CRC and checksum checkers, etc. Then comes the Companion virus and blows right by all the defenses. So one erects defenses against that. Then comes the DIR II and takes care of _them_. Enough said? Software cannot ever provide a permanent defense against software. Fred Waller turtle@darkside.com ------------------------------ Date: 05 Nov 91 09:12:25 +0000 >From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: where can I get a copy of "When Harlie Was One"? al161926@mtecv2.mty.itesm.mx (JESUS BARRERA RAMOS) writes: c...I've been lookin' for a copy of the book "When Harley Was One" but I've found it yet...does somebody know where can I get it?...please..I'd thank ya more than a lot..c ya. thanx. I'd suggest a public library, or a bookstore that carries used paperback books. Note that there are two editions of Harlie....the second edition, issued in the mid 1980s, was "cleaned up" by the publisher to remove things they felt were too far-fetched. The whole subplot about Harlie and the virus is not in this revised edition (I have been told), so try to read the original edition. - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 Internet: spaf@cs.purdue.edu phone: (317) 494-7825 ------------------------------ Date: 05 Nov 91 09:35:07 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Disk Compression (PC) padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: > >Oh, no! It is enough that the users are trying to force the producers > >of virus scanners to scan inside self-compressed executable files... > >They really don't need to be forced to handle also Stacker/SuperStore/ > >DoubleDisk, etc. formats! > They may not have a choice - I see this as the next real "must have" > utilitiy as no-one ever has enough disk space. Meanwhile LZEXE and > PKLITE have proven that the extra time required to decompress in > memory is less than the time gained from reading half the number of > sectors. [explanation why compression is good deleted] Oh, I didn't mean that there should not be an compressing programs! What I think, however, is that all this has nothing to do with virus scanning. Each producer of compression programs must provide a way to decompress the compressed stuff. The virus scanners must only be able to detect whether a file is compressed or not and warn the user. Furthermore, we also need a shell that is able to decompress the compressed programs, run a user-selectable scanner on them and delete them if any viruses are found. Something like SHEZ does with the archives. Now, we don't require that scanners scan inside the archives, do we? Or inside uuencoded, xxencoded, etc. files and all that jazz... We only need a way to restore the original state of the program and then we can scan it safely. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 05 Nov 91 09:54:43 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Questions about VIRLIST.TXT (PC) mcafee@netcom.com (McAfee Associates) writes: > >and files? If this last hypothesis is true, why the Horse Boot, > >Invader and Virus-101 (all listed as able to infect boot sectors and > >files) aren't listed in the same way? > The Horse, Invader, and V101 viruses are what's known as multipartite > ("multiple part") viruses. What that means is that they infect both > files and the boot area of disks when they are accessed once the virus > has become installed in memory. Sorry, but the Horse Boot virus is -NOT- a multi-partite virus! Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 05 Nov 91 11:21:41 +0000 >From: Fridrik Skulason Subject: Re: from fidonet virus conf: new virus found? (PC) >com's with 1220. It shows a message: > "TRAVELLER (C) BUPT 1991.4 don't panic I'm harmless." >There is no ather payload then the messages. The virus infects >infected files over and over and over end.... Question: Does ^[es >BUPT ring a bell ??? This is not a new virus - It has been known since Aug. 5, when it was first reported by RG Software. It is said to be known in the wild in USA. F-PROT 2.01 can detect and disinfect it, but I don't know about other scanners (except SCAN84, which doesn't). - -frisk ------------------------------ Date: 05 Nov 91 11:39:55 +0000 >From: Daryanani Subject: Re: Zipped files (PC) usgjej@gsusgi2.gsu.edu (Jeffry Johnson) writes: >Are there any programs which will scan inside of Zipped files? There are several menu-driven front-ends for archivers such as ZIP and LHA, that can unpack and scan executables in archive files. One that I've used is SHEZ, which can make use of McAfee's SCAN program to do the scanning. Of course since during setup it asks you the name of the scanner program you could substitute another one if you wanted. It may be easier finding these programs on Fidonet. Raju - -- Raju M. Daryanani raju@dcs.qmw.ac.uk ------------------------------ Date: Tue, 05 Nov 91 12:32:00 +0000 >From: Old Baldie Subject: Am I infected ? (PC) My apologies to all and sundry if this is a FAQ, but I'm wondering if I am infected :-). My PS/2 55sx developed an odd condition without warning - memory is recorded as 639K instead of 640K, but none of the anti-viral packages which I use has been able to identify any virus being present. It's a failure on my part, I know, but I wasn't aware that the RAM had been reduced until I ran NEWDET (the only package which reports the size as being suspicious) after installing a tapestreamer card. At first, I thought that the newly-installed card was the culprit, but I have printout (screen dumps) which record the 639K at an earlier point, and I do recall seeing that size reported earlier without reacting to it. I have asked around and discovered that a number of machines report 639K (one reports 637) although none appear to have been infected. The owners/users are not unduly alarmed. Since my machine is a transfer point for sensitive data via floppy I have no wish to pass any potential infection on to the rest of my unit or indeed to departments outside, hence my mild paranoia. I had wondered if a PS/2 specific virus had somehow got itself into battery- backed system configuration RAM, but I can find no sources of information which would confirm/deny this possibility. I have checked through a list of known viruses looking for one which fits the bill, but without success to date. If anyone can offer advice or (polite and biologically feasible) suggestions, I would be grateful. +--------------------------------------+--------------------------------------- + | Peter G. Q. Brooks HSR4@OX.VAX.AC.UK | | | Health Services Research Unit | | | Dept of Public Health & Primary Care | | | University of Oxford | | +--------------------------------------+--------------------------------------- + | +44 (0) 865 224375 8.30 am - 7.30pm | | +--------------------------------------+--------------------------------------- + ------------------------------ Date: Tue, 05 Nov 91 10:11:42 -0500 >From: FAC_JCLARK@VAX2.ACS.JMU.EDU Subject: Availability of "Harley" book In response to Jesus Barrera Ramos' search for the novel "When Harley Was One," it's available in paperback from Bantam Books, $3.95 (US). It can be ordered from the publisher at: Bantams Books, 414 East Golf Road, Des Plaines, Illinois 60016. If you need to have more ordering information, there's a toll-free number for Bantam: 1 800 223-6834. The ISBN number for the book (though it shouldn't be necessary to order through its own publisher!) is 0-553-26465-6,Spectra. Hope this helps! Jeff Clark Media Resources James Madsion University Harrisonburg, VA 22807 ------------------------------ Date: Tue, 05 Nov 91 15:26:49 +0000 >From: ah10@ponder.csci.unt.edu (Chris Gleaves) Subject: DOS viri on the MAC... (PC) (Mac) Recently I heard a commercial for the Mac advertising a product called "PC Soft" (I think...) it claims to run MSDOS software "just like the pc's at the office" (I don't own a mac and NEVER would). It occured to me...what if an infected program was run using such an interface...would it infect other MSDOS software on the disk... or would fail miserably, poosibly destroying the infected software. I figured that someone here would have a comment... Chris ------------------------------ Date: Tue, 05 Nov 91 15:24:50 +0000 >From: stachour@sctc.com (Paul Stachour) Subject: Re: Regulation of (Medical) Software padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: .... >Again IMHO, the first step must be some form of secure, certifiable >operating system. Though much derided, MS-DOS (or DR-DOS), is an >effective and widely used O/S. Most applications operate under these >libraries & I would be surprised to see any sudden migration away from >them. >ERGO, what is needed is a certifiable (I know 8*) operating system or >shell (more difficult but if MicroSoft & Digital Research continue to >be disinterested -well, maybe not DR-, encapsulation will be the only >answer). >In any event, it may well be the Fed, in the guise of Medical safety, >that will finally force integrity management on the PC. Well, we get >tired of waiting for the lawyers to do someting useful 8*). There are certificates of security. They are provided though NCSC (the national computer security center). In my opinion, MS-DOS does, and always will, have trouble getting off the bottom-rung of the ladder. However, as long as the acrediting agencies (hospital boards or whatever) allow use of insecure, uncertified machines, in the hospitals, we will have problems. When/How/If the FDA or other agency choses to require some degree of integrity, there will be a BIG shakeup in the way in which information is managed. Until then, I suspect they will continue in current ways. Sigh! ..Paul - -- Paul Stachour SCTC, 1210 W. County Rd E, Suite 100 stachour@sctc.com Arden Hills, MN 55112-3739 [1]-(612) 482-7467 ------------------------------ Date: Fri, 01 Nov 91 14:26:46 +0000 >From: Chris Stops Subject: RE: Virus Proof Machine Response In answer to Vesselin's comments about my machine... >cs@nabla.electrical-engineering.umist.ac.uk (Chris Stops) writes: > >> (Side note : In fact, the 80286 had a back door, the LOADALL >> instruction. [Rest of stuff, including the fix, deleted....] > >And how about the LIDT (Load Interrupt Description Table) instruction? >It is supposed (to my knowledge) to in protected mode only, but on a >80286 it runs perfectly in real mode. It allows you to swap the whole >interrupt vector table with something totally different, which resides >at a different address. Was this fixed in the 386? The author of the >Vacsina/Yankee Doodle viruses had told me that one of his advance >viruses (TP 50 or 51) uses this trick to avoid monitoring programs on >a 286. Unfortunately, I never got a copy of that virus. According to the '386 book I have here, LIDT is allowed in real mode so that the processor can be set up for protected mode. The '286 should be the same. But once protected mode is established (as on my virus proof (?) machine), the LIDT instruction can be used only at the highest privilege level. So no virus hiding in an application program can do an LIDT. Incidentally, I don't really like the 80x86 series. They all seem so messy compared to more orthogonal processors, the most obvious example being the 68000 series. I chose the 80386 simply because most people reading this are probably PC people. >> [Deletions] >> ...the operating system limits the operations which can be >> carried out on executable files. For example, executable files may be >> created (so compilers still work) or may be executed (of course!). But >> they cannot be opened for read access. Nor can their executable status > >Why not just deny the write access to the executables? I think you must also deny reading executables. If not, for example, a virus could READ an executable into memory and then CREATE a new copy of the executable which includes the virus. And to the machine, re-creating an existing executable would look innocently like someone re-compiling a new version of an old program. >> be altered to look like a data file (e.g. in DOS terms, *.EXE becomes >> *.DAT, the 'DATA' file is processed, then *.DAT is renamed back to >> *.EXE). If we still allow executable files to be deleted, then about the > >It's enough to forbid the non-executable --> executable extension >renaming. I think you must also forbid executables being turned into 'data' files. If not, for example, a virus could turn an executable into a 'data' file, read the data file, and then CREATE a new copy of the executable which includes the virus. >> only sort of virus left is an overwriting virus, which deletes an >> application and then creates a copy of itself using the name of the >> application. But since the applications will no longer run, it should be >> obvious that something is wrong with the machine. > >Also, don't forget about the companion viruses. Could be knocked out by changing the file and/or executable naming system, so that two executables with the same name cannot exist. For example, if my machine has lots of memory, why don't we simplify things and forget about COMs, and just have EXEs (or their non-80x86 equivalent)? It'll probably be OK, as applications continue to get bigger. >Or viruses that infect >.OBJ, .LIB, .BAT, .MAC, .INC, .H, .C, .PAS, .MOD, .FOR, .BAS, .PRG, or >whatever else gets interpretted/executed... :-) Yes, I was aware of this. In reply, anything in source code or ASCII form should be easy to spot in an editor, or the file dates will be changed, or the files will grow etc. etc. And remember, there can be no stealth viruses to cover up things like files growing! As for anything like an OBJ or similar compiled code infector, I don't think it will spread because... 1) People don't tend to swap .OBJ files like they swap executables. 2) Computer USERs (e.g. people doing word processing) won't tend to have OBJ files anyway, even less swap them. 3) Computer programmers in user clubs etc. can swap source code instead of the .OBJs. ...And that leaves only infected .OBJ files from commercial programming packages being copied amongst users. I would not have thought a virus could spread much in these conditions. True, they can exist. But spread very far? I think not. >> To allow copying of executables (e.g. from floppy to HD) there would need >> to be a new operating system call for copying files, becuase, of course, >> no application (e.g. COPY) can read the source file! > >This is no problem if you forbid only writing, but allow >reading/creating. See above for why I think we must forbid reading. >> Now of couse, there will be some users who want/need read/write access >> to their executable files. In this case, we could have a three position >> switch inside the machine, mapped into a protected I/O location. It >> functions as follows... > >Better implement it as a hardware switch. If it is software (even if >it is protected) either (1) the user will not be able to use it, or >(2) a virus would be able to use it too... I think you got my point, but I don't quite understand your comment. To reword my description: The switch is a hardware switch mapped into a protected I/O location. (Possibly a KEY switch to be secure against rogue users. But that's another matter). The I/O location is accessable only to the high priority O/S kernel. There are NO operating system calls to allow an application to interrogate about the state of the switch or to over-ride the state of the switch. Therefore, the operating system can read the switch, the user can alter the switch WITH HIS HARDWARE KEY, but no virus can have anything to do with the switch, apart from having its operation scuppered! >> Position A All attempts to read an executable file are stopped. > >> Position B All attempts to read an executable file result in a > >> Position C All attempts to read an executable file are allowed. > >Just replace "read" with "write". Maybe I've missed something which you have thought of, but I still think we must disallow reading of executables. >> Now that the operating system is so well protected, we have a problem. > >Yeah, that it is not very useful... :-) Well, I would'nt quite put it like that! What we have achieved is: 1) Stopped all boot viruses. 2) Stopped all viruses hiding in the O/S code. 3) Stopped any virus going resident and patching into the O/S. 4) Stopped any virus attaching to an executable application. What have we lost in the process? 1) We now pay a little more for some ROMs. 2) We pay a little more for a key-switch, but most machines already have a keyboard lock. Maybe the two could be combined? 3) It is a *little* more difficult to write a TSR/device driver etc. 4) Technical Users who want to hack about with their machine have to turn a keyswitch before they can read the executables. What have we gained? A massive improvement in security. I think that viruses would become so difficult to write and spread that the machine would have no noticable virus problem, and certainly nowhere near today's scale of things for the PC. So the machine is USEFUL in the sense that it can run all the applications we ever need to with relatively good security. But it is not USEFUL in the sense that it is not MS-DOS compatible. I agree with this, but see my later comments... >> Not only can no virus modify it, but no extensions can be added either, >> for example, new device drivers. The virus proof way around this is that >> new drivers are supplied on ROMs which can be plugged into the machine, >> and patched into the O/S during initialisation. A slightly less secure > >Updating through ROMs has been already discussed here, as far as I >remember... It is a good idea, but most computer manifacturers >consider it as too expensive. Don't forget - a practicable anti-virus >solution should be also marketable... But please remember my comment about loading device drivers (and indeed, other TSRs) off a disk. >If the hardware supports memory protection, and if it is used to >implement file-access rights, you can get a pretty secure system. >Something like Unix... Ooops, there are already viruses that spread >under Unix, so it doesn't seem to be -THE- solution. True, they spread >very slow, true, they can be catched much more easily, but >nevertheless they exist and they spread. Indeed, they use a completely >different trick. While Mess-DOS virus rely on the abilities to bypass >its protection (huh? what protection?), the Unix viruses rely on the >fact that Unix users share resources intensively... I'm a PC user doing university research in microprocessors. So I know a bit about DOS programming, what a mess PC's are, and I know about the 80386 protected mode. But I don't know much about Unix. >> Of course, my machine would probably be incompatible with Mess-DOS. But > >Almost certainly. Maybe OS/2 ver. 3.0? > >> then, isn't it about time we establised a new microcomputer standard >> based on at least 32 bits of data and address? > >Good idea. It rests "only" to convince IBM about it... :-) ...and about 40 Million PC users who probably don't want to upgrade their machines. Maybe if we could get more people to write disk-trashing stealth viruses, we could *DESTROY* the MS-DOS world and start afresh with *MY* new breed of machine? Oooops, now I'm starting to sound like a baddie from a James Bond film! >Regards, >Vesselin Sorry I can't respond to this list very quickly. I'm not actually on the distribution list. I read the articles when they eventually appear on the Public Domain Software machine at Lancaster, here in the UK. If you (Vesselin) want to answer any of my points, but you think the list readers are fed up with this hardware vs. software discussion, feel free to mail me directly. Chris. ------------------------------ Date: 05 Nov 91 17:13:31 +0000 >From: steve@sleepy.tamu.edu (Steve Rikli) Subject: Re: McAfee84 failed to remove Joshi mcafee@netcom.com (McAfee Associates) writes: >steve@donald.tamu.edu (Steve Rikli) writes: > >>As the subject says, Clean v84 couldn't handle Joshi. It discovered >>and claimed to clean it on an IBM PS2/30, but Scan discovered it >>again. Repeated attempts failed. > >Can you please be more specific about what occurred? Did you receive >a message that the virus could not be safely removed, did it say it >was removed, or what? Where did VIRUSCAN (SCAN.EXE) find the virus >after cleaning? In memory or on a disk? What I said above is exactly what happened. SCAN discovered [Joshi], and CLEAN said "1 virus found, 1 virus removed". Re-running SCAN produced "virus found [Joshi]" again. In other words, CLEAN claimed to successfully clean [Joshi] but apparantly didn't. Each time I ran SCAN, I did so after a powerdown and reboot w/clean floppy, and each time Joshi was found on disk. >>Interestingly enough, Clean v76 DID handle Joshi on a CompuAdd '286. >>I thought this was *really* strange. > >There are a variety of reasons that a virus could be reported after it >was claimed to be removed, these range from actual failure to remove >the virus to "ghost" images of viruses being reported as a result of >remnants of viral code left in the system. I thought about the "ghost" business, so I powered down the PS/2 and rebooted from a clean floppy. The same episode I described above happened again. Several times. I would say that CLEAN really was failing to remove [Joshi] from the PS/2. I dunno why, but I suspect it's some peculiarity of the PS/2 at work here. Because all of the v84 programs worked beautifully on our CompuAdd's and other clones. And not only on Joshi--I've also had the opportunity to use them on Keypress and Sunday. - -- || Steve Rikli ||| Visualization Lab || || steve@archone.tamu.edu ||| Texas A&M University || || (409) 845-5691 ||| College Station, TX 77843-3137 || ------------------------------ Date: Tue, 05 Nov 91 18:48:26 +0700 >From: Cezar Cichocki Subject: Problem with Stoned virus (PC) Problems with SCAN Hi| Small (?|||) problems with STONED virus. SCAN detect it, I used CLEAN program, it raport me that CLEANED and... STONED was on disk again || I killed him with NoStoned programm (Polish cure for this virus). Cezar ------------------------------ Date: Mon, 04 Nov 91 21:49:04 +0100 >From: Mikael Larsson Subject: ViruShell - New Shell for SCAN - Great (PC) ViruShell (C) 1991, NewAge Productions and Virus Help Centre ViruShell is a shell to simplify the use of McAfee's antiviral products VIRUSCAN, NETSCAN and CLEAN-UP. It gives you a very straight-forward and easy-to-use front to these programs as well as adding som functions of it's own. ViruShell lets you setup all options, path's and devices from extensive menus and then run the McAfee programs in a window of the main ViruShell screen. These setups can also be saved for later reloading in different setup files. ViruShell is distributed as ShareWare, giving you a trial period of 30 days before deciding if the program suits your needs. Registration unlocks a few functions as a reward for your support of the ShareWare concept. ViruShell incorporates among others the following functions: * Automatically adopts to your system, sensing monochrome or color modes, as well as adopts to the condensed line modes of EGA and VGA, giving you 43/50 lines on screen. * A swift menu system that makes it easy to access the advanced functions of the McAfee antiviral programs. * Full mouse support, works with all MicroSoft compatible mouse drivers. * Memoryswapping functions to reduce memory requirements while executing external programs. * Runs Scan, NetScan and Clean in windows on the main ViruShell screen. * A context-sensitive hypertext format help system accessable from anywhere in the program with the press of a key. * Current version comes in two flavours, english and swedish, other languages will follow. Registered bonus features: * Loading and saving of different setups. * Autorunning of Clean to remove all infections found by Scan. * Easy access to the VIRUSCAN AV functions, add and remove AV codes with the press of a few keys. ViruShell utilizes all functions of the latest McAfee versions and will be updated as soon as any new function is implemented in the McAfee programs. Available from the main distribution BBS'es: Virus Help Centre NewAge Productions Mikael Larsson Jonny Bergdahl +46-26 275710 +46-36 121323 1200-14400 (HST) 1200-9600 (V32) Will be released at Nov. 5th - 06.00pm (GMT+1) ViruShell will probably be available at anonymous FTP withing 12 hours after release. Rgds, MiL ------------------------------ Date: Tue, 05 Nov 91 11:42:57 -0600 >From: James Ford Subject: fprot201.zip on risc (PC) The file fprot201.zip has been placed on risc.ua.edu in the directory pub/ibm-antivirus. Older versions of fprot (v116 and v200) have been removed. - ---------- Don't marry for money; you can borrow it cheaper. - ---------- James Ford - Consultant II, Seebeck Computer Center The University of Alabama (in Tuscaloosa, Alabama) jford@ua1vm.ua.edu, jford@risc.ua.edu ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 211] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253