VIRUS-L Digest Wednesday, 13 Nov 1991 Volume 4 : Issue 216 Today's Topics: Generic scanning - a small test (PC) Re: Organ music/black monitor-Mac (Mac) re; F-Prot 2.01 (PC) Theory : definition & classification Re: A couple questions (Mac) (Commodore) Re: Only Scan Floppies? (general) Re: A couple questions (Mac) (Commodore) Re: Disk Compression (PC for now) two (2) excerpts from FIDO VIRUS echo conference Re: A couple questions (Mac) (Commodore) Re: Virus Proof Machine Response Re: Regulation of (Medical) Software Re: Hardware? How about software...? 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: Sat, 09 Nov 91 17:39:08 +0000 >From: Fridrik Skulason Subject: Generic scanning - a small test (PC) I just did a small test and I hope the results are of general interest. In the week since I released version 2.01 of F-PROT I have received 16 samples of new viruses (in addition to a lot of "old" stuff of course). I ran my scanner (as well as McAfee's V84) on the new viruses, and the results were as expected - some were detected, but others were not. I would have Included Alan Solomon's scanner as well, as I consider it to be the best of the products competing with my own, but I am not sure I have the most recent version of it. I then ran my experimental ANALYSE (or ANALYZE, if you prefer) program, which applies a set of rules to determine if a program contains a virus or not. It should be noted that none of the samples have been analysed yet, or classified properly. In fact, I have not even verified that the viruses work, but my (reliable) sources claim they do. I also want to point out that these are new viruses, and there was no guarantee beforehand that they would be detected at all with my scanner (or any other scanner for that matter). Finally - I just wanted to make clear that I made an effort to make this test fair - I have not yet modified my signature tables to handle these new viruses, and I have not updated the ANALYSE heuristics. Also, I have not excluded any of the viruses I have received the last week. And yes - "Sample name" is just the name of the sample file I received, not the virus name - the viruses are new, and some of them don't have a name yet. Sample name: IRISH.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: Found Irish Virus [Irs] Analyse: No virus-like code found Sample name: DAM-11.COM 2.01-Secure: Infection: Plovdiv 2.01-Quick: Infection: Plovdiv Scan 84: not detected Analyse: This program moves itself to a different area of memory using a method which is normally only used by viruses. Sample name: DAM-13.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This program contains several features which are normally only found in virus programs. It is almost certainly virus-infected. Sample name: MURPHY5.COM 2.01-Secure: Possibly a new variant of Murphy 2.01-Quick: not detected Scan 84: not detected Analyse: This program contains very suspicious code, which seems to have been added to the end of the file. It is almost certainly virus-infected. Sample name: TERROR-N.COM 2.01-Secure: not detected 2.01-Quick: Infection: Terror Scan 84: not detected Analyse: No virus-like code found Sample name: BRAINY.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This file appears to have been modified by adding some code at the end. This might be a virus infection or just a harmless modification by some other program. Sample name: CD-10.COM 2.01-Secure: Infection: DIR-II 2.01-Quick: Infection: DIR-II Scan 84: not detected Analyse: No virus-like code found Sample name: CD-11.COM 2.01-Secure: Infection: DIR-II 2.01-Quick: Infection: DIR-II Scan 84: Found DIR-2/FAT Virus [D2] Analyse: No virus-like code found Sample name: CD-12.COM 2.01-Secure: Infection: DIR-II 2.01-Quick: Infection: DIR-II Scan 84: not detected Analyse: No virus-like code found Sample name: KARIN.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This program moves itself to a different area of memory using a method which is normally only used by viruses. Sample name: STINK2.COM 2.01-Secure: Infection: StinkFoot 2.01-Quick: Infection: StinkFoot Scan 84: not detected Analyse: This program contains several features which are normally only found in virus programs. It is almost certainly virus-infected. Sample name: QMU_COM.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This program contains very suspicious code, which seems to have been added to the end of the file. It is almost certainly virus-infected. Sample name: V-472.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This program contains very suspicious code, which seems to have been added to the end of the file. It is almost certainly virus-infected. Sample name: CS.COM 2.01-Secure: Possibly a new variant of Vienna 2.01-Quick: not detected Scan 84: Found 1014 Virus [1014] Found Lisbon Virus [Lisbon] Analyse: This program contains several features which are normally only found in virus programs. It is almost certainly virus-infected. Sample name: 800_COM.COM 2.01-Secure: not detected 2.01-Quick: not detected Scan 84: not detected Analyse: This program contains very suspicious code, which seems to have been added to the end of the file. It is almost certainly virus-infected. Sample name: NUMLOCK.COM 2.01-Secure: not detected 2.01-Quick: Infection: PC-Flu Scan 84: not detected Analyse: This program modifies itself in a highly suspicious way. It is either infected, or a badly written program which overwrites code with data. So, what can be said about the results? Each of the three scanning methods detected only a minority of the new viruses, but the ANALYSE tool was able to detect 11 out of 16 infections, although it only claimed that 7 files were almost certainly infected. Nevertheless, this was better performance than any single scanner provided. What is also interesting is the fact that it totally missed 5 viruses, including all three versions of the DIR-II virus. Why ? For a simple reason - it uses a set of rules to determine what a virus looks like. The DIR-II virus is different from any other virus, and ANALYSE has no rules covering its behaviour. What is also interesting is that in four cases (DAM-13.COM, QMU_COM.COM, V-472.COM and 800_COM.COM) ANALYSE was able to correctly determine that the programs were infected, although scanning did not reveal anything. Generic analysis is not yet a substitute for virus scanning, but it is improving.... - -frisk ------------------------------ Date: Sat, 09 Nov 91 18:38:47 +0000 >From: johnsonr@news.colorado.edu (Richard Johnson) Subject: Re: Organ music/black monitor-Mac (Mac) SUEHAY@BROWNVM.BITNET (Sue Hay (tm)) writes: >from Fran Holtsberry: >>We have two systems playing organ music and no monitor response... >That chord means that your Macintosh has a hardware problem and it >needs to be taken to an authorized Apple service and repair technician. >No virus is involved. If your Mac is playing the normal startup chord one note at a time, it doesn't always mean a hardware problem. We've had two instances of a badly damaged SCSI driver on the internal hard disk causing the Mac to fail its startup tests. If you can, try swapping drives between one of the offending Macs and a known-working one. If the problem follows the drive, then reinstalling the driver or reformatting the disk might fix things up nicely. Even if it is a hardware problem (bad SIMMs, SIMMs in the wrong slots, etc.), it's almost certainly not a viral symptom. >Susan Hay, User Services Consultant/Analyst, Brown University - -- Loudyellnet: Richard Johnson Internet: johnsonr@hoshi.Colorado.EDU Phonenet: 303.786.8502 (USA) ------------------------------ Date: Sun, 10 Nov 91 09:00:00 -0400 >From: "Bob Martin --> Acsmartin@eku.bitnet" Subject: re; F-Prot 2.01 (PC) >Date: Thu, 07 Nov 91 11:06:37 -0500 >From: MONAT%UOTTAWA@acadvm1.uottawa.ca > >I have some questions/wish list for F-Prot. > >1. I have a lot of clients who work on their stand-alone computer > for quite some time and then decide to access a network. They > load virstop.exe at boot time but then at network time, the load > gets rejected with an "already installed" message. Couldn't > virstop.exe disable its first copy and then reload itself? > (P.S.: Until this problem is resolved, I'm still loading > f-driver.sys from version 1.16 at boot time, then virstop.exe > at network login in). You may have missed it in the documentation, which can certainly happen to the best of us; VIRSTOP.EXE can now be loaded as a device driver. I belive that is on stand-alone cpus, but I haven't had the chance to try it on my networked computer at work yet -- it may still work okay! >2. What are we suppose to do with the file virstop.bin? It's exactly > identical to virstop.exe and both can be loaded at boot time. If I remenber correctly, the BIN file is the 'uninstalled' verion of Virstop. If you put a custom message in the program with the Install part of F-prot, it changes Virstop to reflect your site's message. [...] stuff deleted (because I didn't know the answer. :-) Hope this helps a bit! Bob Martin -- Acsmartin@eku.bitnet -- PS. Thanks for the upgrade Frisk! ------------------------------ Date: Sun, 10 Nov 91 16:31:01 +0000 >From: xim@prima.icie.msk.su (Maxim Titov) Subject: Theory : definition & classification I'd like to propose some thoughts. 1. Formal definition An automaton description D(A) is symbols's set for creating the automaton A or its behaviour ( see von Neumann's works). VIRUSABLE automaton is one can be able to modify descriptions of other automata so that (i) modified description contains the description of the modification algorithm, (ii) after modification, automata with changed descriptions can be able to modify other descriptions in the way satisfied (i) and (ii) rules. Denote the modification as INFECTION. Consider rules of virusable behaviour to define a virus. Consider three Turing machines TM1, TM2 and TM3. There're three external TM programs (descriptions) D(Ak), k is in {1,2,3}. There're they on a common tape. There's non-empty description D(v1), and D(A1) includes D(v1). D(A2) and D(A3) don't include D(v1). There's a recursive function f (D(A1),D(A2)) = h(D(A2')) and 1 D(A2') is TM2's program (here h - morphism {D(A1),D(A2)} => {D(A2'}) ). There're non-empty D(v2) ( D(A2') includes D(v2) ) and recursive function f (D(v1),D(A2)) = h(D(v2)). v1 There's recursive function f (D(A2'),D(A3)) = h(D(A3')) and D(A3') is TM3's program. 2 There're non-empty D(v3) ( D(A3') includes D(v3) ) and recursive function f (D(v2),D(A3)) = h(D(v3)). v2 Finally, there's recursive function f (D(v1), ... ,D(vk),D(Ak)) = h(D(Ak')) k By Kleene's s-m-n theorem there's recursive function f such as v f (D(Ak)) = h(D(Ak')) , otherwise f (D(Ak)) = h(D(Ak')) f (D(v1), ... ,D(vk)) f v v Let's minimize lengths {|D(vk)|} so that above mentioned rules are acceptable. Let D'(v min) conform to some "effective" algorithm U generated by Markov's normalization principle applied to minimal |D(v)|. Then VIRUS v of automaton A (otherwise, automata's set {Ai}) in environment E, which executes algorithm U ( denote as v (A ) ), U E i s either (a) An automaton which realizes an algorithm of the A automata's infection -1 over environment E (otherwise, some E' = h (f (E)) ) and v can be normalized to the algorithm U, or (b) A description with which some automaton B can be able to realize an algorithm ... ( and so on as in (a) ) Denote set {D(vk)} as VIRAL set (See also F.Cohen's paper "Computational aspects of computer viruses"...) 2. Classification ( Re: taxonomy ... ) Classification should combine as well as environments and viruses classifi- cation. I see four environment (E.) classes: (I) Stationary E. Software is never modified. (II) Computer time-shared systems with software under design and debugging. (III) E. with self-modifying or/and self-reproducing software. (IV) Viral E. Automata's modification by one to another is allowed. a3 Use signature a1a2 a4a5a6 to denote viruses's classes. Here a1 - a way of structure modifications during infection a2 - type of an attacked object's function change a3 - infection intensity a4 - degree of concealment a5 - infected level's specification (in hierarchy systems) a6 - sign of ability to recognize a previous infection We may omit signs which are not vital important. In brief, these signs are following. a1. Denote "S" if virus Substitutes an attacked program's piece for own code. Denote "I" if virus Inserts own code into attacked program. There're prefix- (denote "p"), suffix- (denote "s") and kernal- (denote "k") viruses in von Neumann's machines. I.e. Insertable prefix-virus (Ip-virus) is such as if D(A) = "w1w2...wn" and D(v) = "u", Ip U then there's yield D(A) =>* D(A') : D(A') = uD(A) = "uw1w2...wn" Denote "m" if virus is self-modified. a2. Let there're morphisms h(D(A))=f , h(D(A'))=f , h(D(v))=f and v (A) k m v U D(A) =>* D(A'). There's function g(f ,f ) = f k v m Denote "A" if virus "Add" its function to the function of attacked automaton ( function f is union of functions f and f ) m ----- k v Denote "S" if "power" of f is less than "power" of above union. m a3. W.Gleissner introduced an integral sign of infection process : (v) "Let p_ denote the probability that starting from viral state v,k _ v viral state v will be reached after exactly k program calls." (See W.Gleissner. Theory for Spread of Computer Viruses) (v) If there's function f(t) = k then denote p(v,t) = p _ . v,k Let It(v) = d p(v,t) / d t denote the intensity of infection (if there's the derivative, of course). Denote a3 = max It(v). a4. Denote "C" (Conceal) if virus uses i-level and doesn't use resources of another levels (not equal i) or use them by miss all allowed procedures. You see, it's analogous to "stealth". We can denote "pC" (partial-conceal viruses), "nC" (non-conceal viruses). It seems the definitions are clear. a5. Denote "m-n" if vurus infects m higher levels, current and n lower levels. a6. Denote "R" if virus can be able to recognize earlier own infections. 0.001 Example: Let IpmS C-1R denote an insertable, prefix, self-modified, substitutional with intensity of infection 0.001, conceal, infecting an initial and one lower levels, recognizeable VIRAL CLASS. Thanks. Comments are welcome. ps Excuse my possible awkward style, please. May be above ideas will be useful to develope a computer viruses's theory? I'd like to introduce compact record to denote CV classes, and to make more precise Cohen's formal virus definition. MxT Maxim Titov, software analyst xim@prima.icie.msk.su International Centre on Informatics and Electronics (InEVM) Moscow, Russia ------------------------------ Date: Sun, 10 Nov 91 23:49:08 +0000 >From: rlvd_cif@troi.cc.rochester.edu (Robert Levandowski) Subject: Re: A couple questions (Mac) (Commodore) AB5891A@ACAD writes: >constantly be shut off. On a Mac, (OR IBM for that matter) if you >want to increase the ANTI-virus protection, just after EACH >application shut the system off. The virus MAY still spread, but then >again, it may not. DON'T DO THIS ON A MAC! If you turn off a Mac without quitting to the Finder and selecting "Shut Down" from the "Special" menu, you risk corrupting your disk and damaging any files you may have been using--including your application. Simply turning off the Mac after using an application does not give the Mac the chance to properly update the disk or any open files. ..and some Mac viruses will continue to spread anyway. In fact, most of them will if you are using MultiFinder or System 7. - --Rob Levandowski Computer Interest Floor / University of Rochester ------------------------------ Date: Sun, 10 Nov 91 20:42:11 -0500 >From: flaps@dgp.toronto.edu (Alan J Rosenthal) Subject: Re: Only Scan Floppies? (general) jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) writes: >A perceived delay every time the user runs a program is sand in the gearbox. agreed. But Disinfectant init on the mac scans each time the program is run, and it is not a perceivable delay. ------------------------------ Date: Mon, 11 Nov 91 00:59:28 +0000 >From: plains!umn-cs!LOCAL!aslakson@uunet.uu.net (Brian "Zamboni" Aslakson) Subject: Re: A couple questions (Mac) (Commodore) I tried to e-mail this, but all my attempts bounced. In comp.virus AB5891A@acad.drake.edu writes: >Well, I use this MacIntosh SE that the school has provided me and it >works nicely, but recently my roommate erased all of the anti-viral >programs and thus I was prone for an attack, which occurred. An OLD >virus, nVIR B, hit. No biggie, but the ANTI-virus program VIRUS >DETECTIVE removed the virus resource, but didn't redirect the >pointers, so I had a useless System, Finder, and Term program. Why stress OLD? What makes it OLD anyway? (minor nit-picks) Use Disinfectant and your chance of having the virus removed and your System (and etc.) still working are greatly increased. 2.5.1 is current, if you can't find it, let me know... >I also own a Commodore 128. Strangely, over the 6 years I have had it >What makes the difference between the two is this, one is constantly >on - going from one application to another, while the other has to >constantly be shut off. On a Mac, (OR IBM for that matter) if you What??!! Are you wacked? >want to increase the ANTI-virus protection, just after EACH >application shut the system off. The virus MAY still spread, but then >again, it may not. Oh, I see your point. That is not the proper attitude to preventing infection, and stopping the spread. If you have a virus-infected app, it can spread to another app without it running (many IBM viruses work that way). Also, viruses that infect the system won't care what app you are running. Your solution doesn't provide anti-virus protection, it just annoys the user and MAY slow the spread of a virus. BUT it probably won't. If you let a virus sit on your machine, you are making a big mistake. The real solution: Use Disinfectant (or something current and respected such as SAM 3.whatever) from a locked, known clean, bootable floppy. Boot from it and check your harddrive and floppies (don't forget to check all floppies). Install the Disinfectant INIT (from the menu, very simple), and check new things coming in (including shrink-wrapped material). Also, install GateKeeper (1.2.1 is current) in your system. Disinfectant (& INIT) look (and watch) for known viruses, while Gatekeeper watches for virus-like activity. Both products are FREE!!! Both products are available on the net (both authors are on the net) and are well respected. >Another reason why my Commodore can't be infected is that it has its Can't? >DOS in ROM not in a modifyable DISK which is then loaded into RAM. You don't know much technical about Macs then. There is a lot of the Mac's Operating System in the Mac's ROM. In fact, the Classic can boot from ROM. BUT ROM's _can_ be patched (otherwise bugs would kill you, and old models couldn't be improved). >Both are loaded into RAM, but on the Commodore, it cannot be changed >with software. What I think you mean is "If I boot from ROM only on my Commodore, the ROMs can't be infected". >ParaPsykotically Yours, Uh-huh. Brian - -- .signature: No such file or directory ------------------------------ Date: Mon, 11 Nov 91 16:59:00 +1300 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Disk Compression (PC for now) padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: >> [ what I wrote about viruses having trouble with compressed partitions] > Doubt it - the Jerusalem (& any other virus that follows DOS Disk access > techniques) will work just fine. What is going to have trouble is anything > that tries to lock/access the FAT directly. What I meant was the combination of compressed disks plus other (simple) software protection. For example: User programs --> DOS --> Compression system --> ReadOnly driver --> int 13 (Or, perhaps, DRDOS password protection in there as well). Obviously viruses that go via DOS get blocked by the "readonly" software protection driver (say, DMDRVR.BIN or DISKGARD or DS II?), but (as many have debated recently) it is easy to bypass software protection and call interrupt 13 directly. But in this case it doesn't do the virus any good, since they bypass the compression system when they bypass DOS and the Readonly driver. This leaves them with junk which the virus will either not be able to interpret, or will make a mess of, or will require much more complexity in the virus to do the same job as whichever compression system was used. Now, my worry is with viruses that do, in fact, try to manipulate the disk behind a compression scheme. That's probably getting too far ahead of the play, of course, since few people use the above combination of software yet, so I doubt anyone has started writing viruses to get around it! However, that is inevitable in the future, if (a) such combinations of software block other viruses and (b) that software becomes popular - not just with the relatively few people that bother with anti-virus measures at the moment, but others interested mainly in saving disk space, etc. >... Windows...blows up & am left with a corrupt disk... That might be the requirement that the TEMP dir be placed in a non-compressed area, highlighting the problem some software has if it tries writing directly to areas on the disk. In effect, Windows is "naughty", I guess, since it tries to bypass too much. Programs like Norton's DS are only slightly naught, and go in at the interrupt 26 level (I think), which is still possible - I don't know what fraction of viruses use interrupt 26 instead of interrupt 13 or interrupt 21 (anyone with an approximate percentage?) but these are the ones that probably get past a combination of compressed partition plus DRDOS password protection, but not read-only software in conjunction with compression. Mark Aitchison. ------------------------------ Date: Mon, 11 Nov 91 07:12:00 -0500 >From: HAYES@urvax.urich.edu Subject: two (2) excerpts from FIDO VIRUS echo conference - ----- begin forwarded message #1 --- To: All Message #: 3574 >From: Gary Watson Submitted: 09 Nov 91 16:35:00 Subject: H/w anti virus idea Status: Public Received: No Group: VIRUS (30) I think I have a way to modify an existing product that we manufacture at my company into a virtually infallable anti-virus device for scsi disk drives running MS-DOS. We currently build a RAID-0 controller, which is a device that fits between a SCSI controller in a PC-AT and an array of target disk drives. Our code name for this device is "SSPT." The firmware on the SSPT is in EPROM. The SSPT intercepts all disk requests and parcels them out to the target disks according to certain rules. My firmware has the option of rejecting operations that it doesn't like, and the PC can't get around it. So here's the plan: the user flips a switch on my SSPT board to the "System Configure" setting. The SSPT allows all operations to go through, except a bit of the disk is reserved for internal use. The user loads up MS-DOS, including the boot sector and hidden files, and all application software from KNOWN CLEAN master floppies. He then turns off the "System Configure" switch. The SSPT then goes out and makes a record of all .EXE, .COM and .OVL files, the hidden files, and their corresponding FAT and directory entries. This info is stored on the reserved disk area. On subsequent boots, this information is loaded into SSPT ram. Obviously the SSPT's job is to make sure that disk writes do not hit any of the protected files, nor delete their directory entries, nor fiddle the appropriate FAT bits. There could be a "System Upgrade" switch that allows new .EXE etc. files to be added to the protected list. The SSPT board as currently produced has a microprocessor, eprom, ram, two scsi chips, two scsi connectors, a serial port, a 2x20 char LCD display, led's, switches, and a loud buzzer. It could be programmed to raise hell when someone is trying to infect the scsi hard disks. Or, in a university setting, it could send a signal down the serial rs-232 link to a professor's office so he could catch the culprit in the act. This board would sell for about $400, so it would be most applicable to network servers, bbs's, or large and expensive scsi disks (say, 1.2 GB and up.) In the longer term future, this stuff could be incorporated into the scsi controller in the AT system, for little additional cost. The user would have to insert an electronic key into a port on the board to allow tampering with protected files. The only type of virus that I can think of that this system couldn't guard against is the one that adds a .COM file with the same name as a legit .EXE file. But there are easy preventions for that trick, like a program, included in the protected list, that on boot up it scans all directories for any file that exists in both .EXE and .COM form, and screeches at you if they are found. Of course, a sloppy user could add add'l programs to his system that are infected, but since the critical system boot stuff is protected, the virus can't become memory resident unless that program is executed after boot. Any comments? - --- VP [DOS] V4.09e * Origin: The Programmer's Inn - FeatherNet Home (619)446-4506 HST (1:10/301) - ----- end forwarded message #1 --- Any comments from our resident hardware gurus? Seems an interesting concept, except for its price, which will deterr a lot of individual users... Cl. - ----- begin forwarded message #2 --- To: All Message #: 4207 >From: Antony Purvis Submitted: 09 Nov 91 19:02:00 Subject: Destruction! Status: Public Received: No Group: VIRUS (30) The news agency NEWSBYTES recently carried this report: VIRUS UPDATE Canada Virus kills FDD A particularly nasty virus has forced Queen's University to replace diskette drives in three personal computers. A fourth infected machine was caught in time to save the drive. Doug Crowe, manager of computing services at Queen's, told Newsbytes three personal computers from a public lab were brought in with their diskette drives "just cooked." Apparently the virus, a variant of the 1575 virus also known as the Green caterpillar virus, forces repeated accesses to track 0 of the diskette until it wears out the drive mechanics if not stopped in time. Crowe said the IBM diskette drives cost C$375 each to replace. Publicly accessible computers at Queen's are protected by virus detection software, Crowe said, but the software failed to catch this particular virus. A fourth PC was brought to computing services staff with its diskette drive making a repeated clunking noise. Crowe said the noise was rather like that of an eight-inch diskette drive like those used on minicomputers, word processors, and early personal computers in the late 1970s and early 1980s, but definitely abnormal for today's 3.5-inch drives. In this case staff were able to remove the virus before the drive was destroyed. ----- Anyone got any comments? Newsbytes isn't exactly the most reliable of agencies, it must be said. (No disrespect to them) Ant * SLMR 2.0 * House House House House House ... ARGH! AAAGH! - --- WM v1.01c/91-0104 * Origin: SANCTUARY BBS 44-329-236612 HST/DS (2:251/17) - ----- end forwarded message #2 -- I know nothing myself about "Newsbytes". Our Canadian readers may be able to give us more details about that new/mutated (?) virus. I myself found information about the so-called "ansi-bombs" (embedded escape sequences doing dirty tricks), but nothing like that. The closest description to the above mentionned virus called for an ansi-bomb capable of doing the same trick on a hd, and not a floppy. The usal target of ansi-bombs, btw, are BBS's, where bombs left inside an e-mail msg can do a lot of damage (e.g. refformatting the hd, creating enough files to fill the hd, etc). Best to all, Claude. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Mon, 11 Nov 91 11:20:19 +0000 >From: alexis@panix.com (Alexis Rosen) Subject: Re: A couple questions (Mac) (Commodore) AB5891A@ACAD.DRAKE.EDU writes: >Well, I use this MacIntosh SE [infection story deleted] >I also own a Commodore 128. Strangely, over the 6 years I have had it >I have never once had a single virus in it. Recently a few trojan >horses appeared, but they were easy to spot. >What makes the difference between the two is this, one is constantly >on - going from one application to another, while the other has to >constantly be shut off. On a Mac, (OR IBM for that matter) if you >want to increase the ANTI-virus protection, just after EACH >application shut the system off. The virus MAY still spread, but then >again, it may not. Bad analysis. On the Mac, you will still infect the Finder, and in many cases the system. From there, any binary you run will be infected. On DOS, the possibilities are endless, and I'll leave them to those better equipped to discuss them. >Another reason why my Commodore can't be infected is that it has its >DOS in ROM not in a modifyable DISK which is then loaded into RAM. >Both are loaded into RAM, but on the Commodore, it cannot be changed >with software. Now, that's a lot more cogent. Unfortunately, there's little there to help Mac users, or most DOS users (there are a few rare DOS machines with DOS in ROM, but that's not likely to prevent many PC viruses from attacking). - --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NYC alexis@panix.com {cmcl2,apple}!panix!alexis ------------------------------ Date: 11 Nov 91 14:38:18 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Proof Machine Response cs@nabla.electrical-engineering.umist.ac.uk (Chris Stops) writes: > 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. Oh, sure, if the machine already is in protected mode, it can stop that. I was talking about the current machines, running Messy-DOS. What I had particularly in mind, was a virus I was told about by the author of the TP family. I don't have an example of it, so I don't know how exactly it worked, but I'm sure that it ran in real mode only and used the LIDT/SIDT instructions. I thought that these instructions are supposed to run in protected mode only, that's why I asked. I was wrong, obviously. > >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. Yeah, because a compilers fits Cohen's definition of a virus... :-) But, you can deny file DELETION as well. Or ask for confirmation. Or allow a program to write only to those files that it has created and/or those that have been supplied at the command line as arguments, when the program has been called... BTW, even if you forbid reading from files, you still have the possibility to build a virus that simply deletes the file and creates a new one (with its body inside) with the same name... Something like the current overwriting viruses... > >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. It can CREATE it, OK, but it won't be able to WRITE it on the disk, if you forbid writing to the executables... This will cause problems on compilation, however. > >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. Hmm, the above seems a good idea... More exactly, one can rename all EXE files to COM extensions and compile all BAT files with something like BAT2EXEC... If all executable files have only COM extensions, the companion viruses will simply not work. (DOS itself will be able to recognize the file type, by the first two bytes of the file.) The problem is: are the companion viruses such a threat that one must perform the above operation? I don't know... > 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 "Easy to spot" is easy to say... Will you be able to spot a source-infector if I give you the source of a chess program, which is some 60,000 lines in C? And everybody who has won the "Obfuscated C contest" is able to "hide" his/her source's meaning in a much smaler program... > 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. Yes, but they do swap the executable that are made from those .OBJs... > 2) Computer USERs (e.g. people doing word processing) won't tend to have > OBJ files anyway, even less swap them. Yes, but even USERs love to play games that are linked from those (possibly infected) .OBJs... > 3) Computer programmers in user clubs etc. can swap source code instead > of the .OBJs. See my remark above about the possibility to hide a virus in source code. > ...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. You are probably right, but I didn't say that the virus will spread far, just that it will be possible to design it. And maybe, if everybody relies on this protection and gets a false sense of security, it will spread unnoticed anyway? There is a Bulgarian virus, called Compiler, which infects only when the files change their size or are created. This usually happens only in program developpment environments. Nevertheless, this virus did spread in Bulgaria, although not very widely... > >This is no problem if you forbid only writing, but allow > >reading/creating. > See above for why I think we must forbid reading. Note that Creating a file is not enough to put code in it. You have also to Write to the created file... > 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! Oh, I didn't get that you're speaking about protected mode and memory protection in general... Then indeed, you are right, it is equivalent to the hardware switch and it will work as well. > 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 did you left? 1) Viruses that infect files that will become executables (sources, OBJs, LIBs, etc.). 2) Viruses that infect interpretted code (macros). 3) Viruses that spread only when the protection is off. Is it good? Sure, it is. Much, much better than the Messy-box. Sounds much like a Unix-box. Did you stop the viruses completely? Of course not, this is not possible. Did you get a useful machine? Yes! Is it compatible with the Messy-box? No! and needs not to be... Now you have only to convince all these Messy-box users to forget about their messy programs and to switch to the much better conception... :-) A though task, IMHO... > 3) It is a *little* more difficult to write a TSR/device driver etc. In fact, as you are going, you could implement multitasking, device monitors and all that jazz and just forget about the TSRs... :-) > A massive improvement in security. I think that viruses would become But, in order to stop viruses, you need to improve the integrity... > 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. True. They will probably become as widespread as the current Unix viruses. Which is just fine for most users... :-) > So the machine is USEFUL in the sense that it can run all the > applications we ever need to with relatively good security. The point is that you still haven't solved the problem with the possibility of a virus attack. When Cohen pointed out this security threat, he didn't have in mind that lots of smart kids with some (or even none) system knowledge will begin to write huge lots of nasty viruses, that exploat the total lack of protection on Messy-DOS. He said that even the most well protected machines are not invulnerable against this (completely new) form of attack. > 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. Oh, give it a try... You'll love it! It's an OS for REAL PROGRAMMERS... :-)) > ...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! No, you are sounding like some people that created and distributed sophisticated self-encrypted and mutating viruses just to show that scanning is unreliable. Or that released a worm on 6,000 computers on the Internet just to show that it's security is not good enough... No, this is not an acceptable solution. > 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. Oh, I don't mind if this arrives to you late. I just thought that some of the points expressed here might be interesting to the other readers as well... 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: 11 Nov 91 13:46:20 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Regulation of (Medical) Software stachour@sctc.com (Paul Stachour) writes: > There are certificates of security. > They are provided though NCSC (the national computer security center). It depends on what do you call "security". The guys at the NCSC seem to mess "security" with "integrity". In fact, what most people understand under security is secrecy, not security. This is normal, since before the advent of computer viruses, most of the demands of the market came from the military, who needed secrecy. Just an example. The Bell-LaPadulla model of secure computer environment, on which (I was told) the most secure military computers of the USA are based, is just as helpless aginst a virus attack, as any IBM PC computer. The protection protects the information on these systems from being leaked, but it does not protect it from being infected... since computer viruses are not a secrecy problem, they are an integrity problem. Now, there is also the so-called Biba model of integrity protection. It can stop viruses from infecting protected areas, but does not stop the information from being leaked from these areas. At last, one could combine both models and achieve a system, which no virus can prenetrate, and from which no information may be stollen. As a side-effect, unfortunately, you also get a pretty useless system, on which no user can send any information to another, or even get any updates of any programs. Not to speak that no information about the system resources is available (that is, you are forbidden even to ask about the available disk free space), in order to close the covert channels... :-( > In my opinion, MS-DOS does, and always will, have trouble getting > off the bottom-rung of the ladder. IMNSHO, Messy-DOS does enven have problems to climb to this bottom-rung... :-) 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: 11 Nov 91 13:13:49 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Hardware? How about software...? turtle@darkside.com (Fred Waller) writes: > > We have UNIX systems with a Software-switch-off function. If an > > "Antiviral" package immediately activates this function the system > > will be switched off and can not be infected. Is this Hardware > > protection? No, because Hardware alone can not do it (it will not > > switch off by itself). Is this Software protection? No software > > alone can not do it (after software triggered the hardware, the > > hardware will switch the system off). > Fascinating. That's exactly how Mark Washburn's SECURE program > works under MS DOS, only I was led to believe here that SECURE Yes, SECURE is not useful, since it works under MS-DOS, where there is no memory protection, so any sufficiently clever program can disable it. This does not mean, of course, that the -method- on which SECURE is based is also useless. It can be pretty useful (although not virus proof!) if implemented correctly under a correct operating system. Unix has had something similar for years. And it was even not the first one... > wasn't useful. Could it be that such methods, first pioneered by > Ross Greenberg in FluShot, and then expanded by Washburn in SECURE, > are a good way of doing things, after all? Better than string > scanning? These methods are just one of the good ways to do things. The problem is that because of the lack of memory protection, they all can easily be circumvented on a PC, and updating them is much more difficult than updating a scanner. As a result, the scanners are easier to produce and sell. Neither of the methods (capabilities or scanning) is virus-proof, regardless of the memory protection, but you said that you want only virus-resistence, not virus-proofness... > I always thought it was better, but with all the protestations here, > I had more or less given it up. Should we retake the subject of > SECURE, then? If it's good, then we should look at it much more > carefully, even as a model for other antivirus software. No, it is not good, unless there is a method to protect the program in memory. A version of SECURE that runs in virtual mode might be a good idea. Again, I repeat that it won't be able to stop all possible viruses. Another useful idea is the integrity shell, according to Fred Cohen... 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 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 216] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253