VIRUS-L Digest Monday, 30 Sep 1991 Volume 4 : Issue 175 Today's Topics: re: a utility to warn me when I'm accessing a removable disk (PC) Re: Stoned Virus questions (PC) Problems running F-PROT 2.0 on 386 systems (PC) Re: FAT Infection and sundry flames/comments (PC) Re: FAT Infection (PC) Re: FAT Infection (PC) Re: Mutant viruses (PC) Re: OS/2 Viruses (OS/2) Re: Precise identification Re: Scanning LZEXE and PKLITE files (PC) Re: Perfect detectors Re: software approaches Re: Scanning LZEXE and PKLITE'd files (PC) Michealangelo and Stoned (PC) Re: Theory and practice 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: Thu, 26 Sep 91 11:39:54 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: re: a utility to warn me when I'm accessing a removable disk (PC) >From: nstephen@dogmatix.inmos.co.uk (Nick Stephen) About a month ago I wrote such a program: NoFBoot (disallows floppy boots with cntrl-alt-del) and its companion SumFBoot (disallows floppy boots unless cntrl-alt-F is used) as FREEWARE ("worth every penny") (maximum disclaimer implied). However when I tried to send it to Mr. Stephen, the above address bounced. Tried the CUNY router. Bounced again. Nick: if you will send me a usable address, I will reply with the uuencoded .ZIP file. Padgett ------------------------------ Date: 26 Sep 91 15:06:55 +0000 >From: ccml@hippo.ru.ac.za (Mike Lawrie) Subject: Re: Stoned Virus questions (PC) HSVLM@tjuvm.bitnet (Larry Mateo) writes: >I have a couple of questions regarding the stoned virus that perhaps someone >could answer: >1. How does the virus infect a host system? That is, how does a PC's hard >drive become infected? Boot the PC with an infected floppy is one way to do this. At boot time, it infects the hard disk. Subsequent boots from the hard disk cause the RAM to be infected. >2. How is the virus then spread to floppy disks? If you write to a floppy disk once you have the RAM infected. The virus gets written to the boot sector of the floppy, so next time someone boots with that floppy, it hits (or re-hits) the hard disk, and so it goes..... Mike - -- Mike Lawrie Director Computing Services, Rhodes University, South Africa ............................................... Rhodes University condemns racism and racial segregation ------------------------------ Date: 26 Sep 91 10:27:57 +0800 >From: "Fran Holtsberry" Subject: Problems running F-PROT 2.0 on 386 systems (PC) Seems we are having trouble running F-Prot 2.0 on ANY 386 machines. Getting a "Cannot read drive C" error. Anybody else getting this? Fridrik...How about a response? Fran Holtsberry Cal State Chico fran_holtsberry@msmailgw.csuchico.edu ------------------------------ Date: 26 Sep 91 17:41:15 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: FAT Infection and sundry flames/comments (PC) mrs@netcom.com (Morgan Schweers) writes: > >It won't, if the virus modifies the DPB to indicate that there is only > >one FAT copy... > If the virus did that, then DOS would have trouble with the disk. Not, if it is done -well-... > I think that it should be pointed out that you cannot INFECT the FAT, > but a virus might use it as storage space. Correct, but in my initial message I pointed it out - I said that the virus could use the first FAT copy to store its second part there, instead of in clusters marked as bad. > The FATs are PURELY data areas. No executable code, therefore no > possiblity of infection. On that score, you can relax. Sometimes a -modification- of a data area could cause code to be infected... or to -behave- as infected... Think about the DirEntry field... :-) > There is a limited set of areas that can be infected by a virus. > Essentially, the files, the MBR and the Boot Sector. The methods used Essentially, yes. However, let's recall that, according to Fred Cohen, the virus "is able to infect programs by -modifying- (emphasis mine V.B.) them in such a way that they include a possibly modified copy of itself". Therefore, infection is achieved by modification. My point is that there are other areas besides files and boot sectors that can be modified to cause infection. > yet, thankfully. There are some things that viruses CAN not be > written to do, simply because it's impossible. (INFECTING the FAT is > one of these.) True, I meant -modifying- the disk structure (and using the first FAT copy) for the purpose of infection; not infecting the FAT. And, besides, who can say that it is really impossible? :-) Just half an year ago I thought that "infecting" directories is impossible too... > As a side-slam against viral researchers who write viruses > (slamming them is a favorite hobby of mine) they seem to think that > the first category (viral methods which haven't been written yet) are > a prime candidate for showing off their own technical prowess. > Frankly, any viral researcher who writes a virus 'to demonstrate that > it can be done' is doing the community a *GREAT* disservice. I'm not sure to understand completely, but have in mind that the method of using the first FAT copy for purposes of infection has not been implemented neither by me, nor by any other anti-virus researcher. In fact, it has not been implemented at all - yet. Even the idea about it is not mine - it belongs to the author of the Vacsina/Yankee Doodle viruses and even he didn't implement it. > Other side comments: Mr. Bontchev mentioned that to his awareness > VirX was the only program which scanned inside of PKLite'd files as > well as LZEXE'd files... That's not true. McAfee Associates places > high import on the ability to scan inside of compressed executables. > PKLITE and LZEXE detection have been standard inside our programs for > some time now. I stand corrected on this. Several other people also sent me private mail about this. Thanks for the information. Now, how about the DIETed, TINYPROGged, PGMPAKed, etc. files? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 18:07:31 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: FAT Infection (PC) RZOTTO@DKNKURZ1.BITNET (Otto Stolz) writes: > Another observation from the same incident bears on the epidemology > of the Stoned Virus. That group has two secretaries equipped whith > identical computers. Both had Stoned on their hard disks. When I checked > all diskettes in that environment, I found that one secretary had > infected more than half of her stock, while the other one had > infected but 1 diskette. It turned out, that one usually worked whith > drive A, and the other one usually whith drive B of her computer. Yes, this is one of the Stoned peculiarities. It infects only floppies in drive A:, and only of the disk drive motor is still spinning when the boot sector is accessed. This reminds me of another thing. It is possible to disinfect Stoned "manually" (e.g., with Norton Utilities) both from the hard disk and from the diskettes, even if the virus is still active in memory. Since this particular virus (ONLY this one!) infects the hard disk only at boot time, it won't re-infect it if you restore the original contents of the MBR. And the diskettes could be disinfected by doing this with the B: drive... Of course, this is just a curiousity; letting a virus lurking in memory is EXTREMELY bad practice, so you should ALWAYS boot from a non-infected write-protected system diskette before dealing with viruses... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 18:02:15 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: FAT Infection (PC) grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) writes: > >It won't, if the virus modifies the DPB to indicate that there is only > >one FAT copy... > If a virus will modify the BPB in such a way, then a start of a root > directory and data area will be calculated wrong - file system will be > corrupted. Not, if all the appropriate DPB fields are also modified... > Moreover, I experimented with formating a floppy with one FAT copy > (using my own program). DOS (3.30) ignored BPB data saying "one FAT > copy" and considered there were two of them - so it calculated the > start sector of a root wrong and showed a nice picture both with DIR > command and Norton Commander. Yeah, that's because DOS doesn't use the DPB when working with floppies. To force it to do that, just put 0F8h as media descriptor byte in both the DPB and at offset 0 in the FAT(s). This was the diskette will look as a... hard disk. :-) > Brian is wrong, of course. CHKDSK will not help because such a virus > MUST be stealth - see my previous message on the same subject to the > VIRUS-L. The virus does not -have- to be stealth, but it will help it a lot, of course. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 18:31:57 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Mutant viruses (PC) grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) writes: > I can E-mail uuencoded PKZIP'ed infected program to you together > with disassembled source. (I didn't participate in "Disassembler > Info" discussion but I prefer DEBUG for myself.) Listen, Dimitry (and all the others), PLEASE, NEVER send unencrypted virus source/code by e-mail - even to persons whom you trust. I'll contact you privately and shall explain how to send the virus. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 18:55:19 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: OS/2 Viruses (OS/2) Seanor@DOCKMASTER.NCSC.MIL writes: > Does anyone have information on computer viruses that infect OS/2 files? > I thought I had heard something about an OS/2 virus. If anyone has any > information I would like to hear about it. Thanks! Currently, there are none. However, they are damn easy to implement, since OS/2 is still a single-user system (inspite of being multi-tasking) and the user still has full access to the files. However, the techniques to write such viruses will be very different from the ones used in the Mess-DOS environment. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 19:01:44 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Precise identification turtle@darkside.com (Fred Waller) writes: > > Precise identification is undispensable if your program has to > > disinfect the infected media. If it tries to disinfect the wrong > > virus variant (even if it differes by only one or two bytes), it > > may damage that file beyond repair. > If providers of antiviral measures are incompetent enough to allow > infection in the first place. But why not *avoid* infection > instead, rather than dedicating all our resources to just curing > it? Isn't that the reasonable approach? It is. One of the approaches, that is. There are three main lines of defense against viruses - monitoring programs, integrity checkers and specific anti-virus programs (i.e., scanners/removers). The monitoring programs are usually TSRs which hook several "dangerous" functions (e.g., direct disk write, modification of executable code, etc.) and warn the user if a program tries to perform any of them. The good thing with such programs is that they are not virus-specific - they target illegal activities in general. The drawback: all such software solutions can be circumvented (some of them easier than others). That's what most of the "modern" viruses do. Another drawback: it is algorithmically undecidable whether a "dangerous" function is really caused by viral behaviour, that's why such monitoring programs usually cause a lot of false alarms and the users consider them as annoying - and do not use them. And even the best anti-virus program is totally useless if it is not used. :-) The integrity checkers take some kind of "fingerprint" of the executable areas of the disk (usually this is achieved by the so-called checksumming) and store it in a database. Periodically, the user is supposed to run the checksummer and if any changes in the executable code are detected, they are reported as potential viral behaviour. This is the most secure approach to stop (more exactly, to detect at very early stage) the virus infections. If implemented well enough and used correctly, it can stop any virus. Drawbacks: the method detects CHANGES, not viruses. It leaves to the user to decide whether a change is caused by a virus or not - something that the avarage user is often not able to do. That's why this method triggers false alarms often - especially if self-modifying programs are widely used. Another drawback - if there is a stealth virus in memory, the checksumming program will not be able to discover the changes that are made in the code. That's why you have always to boot from a non-infected write-protected system diskette, prior to run the checksummer. Unfortunately, this is very unconvenient, and few users do so. The third and, as you correctly pointed out, the weakest method of defence are the specific anti-virus programs that are able to find and/or remove specific virus(es). Drawbacks: when a virus is discovered, there is always a signifficant period of time, before is is analyzed, a program that is able to find it is written, and this program reaches the end user. Therefore, such programs are always a step behind the viruses. I personally strongly discourage the usage of scanning techniques alone as sole anti-virus measure. The only good thing with such programs (especially with disinfectors) is that when you alread have a few hundreds infected files, it's a bit late for prevention (the first method) and unless you have a good backup (you MUST have one, but how many people don't?), it's pretty useless to be informed that these few hundred files have been modified (the second method). What the users usually want is a program that is able to find and disinfect all infected files - a thing that I strongly discourage (restore from backups whenever possible! do not disinfect!), but am forced (by the users) to implement in my anti-virus programs. Oh, yes, there is yet another method, but it is so useless, that I almost forgot it. It is called "vaccination" and consists of adding a small piece of code to all executables that checks whether they are infected and reports it (or sometimes even tries to auto-disinfect). Unfortunately, when such "immunized" code becomes infected and executed, it's always the virus which gets control first. Afterwards it can do anything - go stealth; trigger the payload; fool the immunizer (and even remove it); etc. It's important to note that none of the above method is perfect and can stop all viruses forever, but the usage of a combination of all of them (together with a good backup strategy, of course) is a pretty good deffence. > viruses while curing it does not. The question then is: what is the > ultimate goal of the virus scanners: to prevent viruses from > spreading or simply to be widely-used but not very efficacious > utilities? Their goal should be to detect known viruses in the executable code. The fact that some well-known anti-virus programs (no names here) are more indended to persuade the user to pay for them, instead of to defend him/her against viruses is another and completely different story. > In the final analysis, no software approach can ever be expected to > provide a complete defense. A software attack will defeat it, then > the next round will start... _ad infinitum_. There is no end to this > sort of thing. Software defenses and software attacks will alternate > forever, to the great joy of the antivirus publishers, but to the > detriment of users worldwide, large and small. Yes, it is true, but the ultimate solution is unachievable, regardless whether it is implemented in soft- or in hardware. > Only hardware/firmware defenses can definitively stop such software > attacks. Hardware defenses can be much *less expensive* in the long > run, and even in the short run, do not encourage the production of > ever-improved viruses and do not need to be frequently upgraded. The question whether a good defence does or does not encourage the attacker to defeat it can be argued and it has nothing to do with the method used to implement the defence itself. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 20:12:20 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning LZEXE and PKLITE files (PC) pshuang@ATHENA.MIT.EDU writes: > > Furthermore, it's stupid to claim that files compressed by the > > customized version of PKLite are unexpandable. They have to be > > expanded in memory when run, don't they? > Yes, it is true that PKLite'd programs have to be unexpandable so that > they may be executed, but your statement is more or less equivalent to > "Encryption isn't effective because the receiver has to be able to > recover the plaintext." Any decent encryption makes the decryption No, my statement is equivalent to "encryption isn't effective as long as the decryption code and data are sent together with the encrypted message". Sounds correct, doesn't it? > process non-trivial. In this case, I don't know exactly what PKWare > does for these customized, numbered versions of PKLite, perhaps > crpyotgraphically it is a trivial change which can be broken, but it is > non-trivial to the end-user to recover the original. Non-trivial to the end-user - yes. Impossible - no. > > They're just not expandable to their -exact- (byte by byte) original > > source. But, of course, the code (which contains the instructions and > > where the virus hides) -can- be expanded exactly. > Out of curiosity, if you state that the code can be expanded exactly, > then what is your intended pronoun reference in "They're just not..."? I meant that the EXE header information for instance (the relocation items, more exactly) cannot be restored exactly to its original form - only to an equivalent one. The same maybe holds for the stack and the data areas, but I'm not quite sure. > I'll try to remember to grab VirX to look at its documentation, but does > anyone know of shareware/public-domain programs which have been > compressed with a customized PKLite which I can play with? Try PKWare's own PKMenu. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 21:12:04 +0000 >From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) Subject: Re: Perfect detectors Ray.Mann@ofa123.fidonet.org (Ray Mann) writes: > [ much deleted ] > Are we seeing here a problem of social norms or another effect? > > Social norms didn't change that much in a couple of years. The > most obvious variable seems to be the presence of antivirus > software. It appears that viruses and antivirus utilities have > more or less encouraged one another in time. What's especially > notable is that most known viruses started to appear =after= > the initial appearance of scanners. > > Anyone care to elaborate or make some comments on this? While I can't argue with the observations you make concerning the mutual growth of virus and antivirus software, I would like to point out that there have been social changes in the last few years. If only that there are a lot more machine out there to be infected, and a lot more virus-ignorant people out there sharing floppy disks. Even without the "challenge" to the virus writers from the anti-virus writers, there would still be growth in the number of machines infected and the number of infections per machine, simply because of the growth in the industry. > Ray Mann Jesse Chisholm | Disclaimer: My opinions are rarely understood, let jesse@altos86.altos.com | tel: 1-408-432-6200 | alone held, by this company. jesse@gumby.altos.com | fax: 1-408-435-8517 |----------------------------- ======== This company has officially disavowed all knowledge of my opinions. - -- | "I've UNDERSTOOD IT! Well, that is, ..., | I'm not exactly sure WHAT I've understood, | but I have the impression I've understood | SOMETHING." -- Anselm Lanturlu ------------------------------ Date: 26 Sep 91 20:22:45 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: software approaches turtle@darkside.com (Fred Waller) writes: > Vesselin Vladimirov writes this, yet he knows that all virus > scanners make it a prominent point of announcing many (useless) > hundreds of viruses they can "detect", with the obvious intention of > impressing the public into (debatable) confidence. He also neglects No, I don't know this. I claim that the increasing number of anti-virus programs is a consequence of the increasing number of viruses. However, I cannot prove this claim (neither can you prove yours), so let's drop this stupid discussion. > to take into account the fact that well-known hardware approaches, > such as recently described by Padgett Peterson here (posting of 16 > Sept 91 on `Interesting Laptop config') provide a much more > effective means of protection than software. The hardware solutions are indeed very useful and I wellcome them, but just as the software ones they cannot be the ultimate solution to the problem. A dignifficant improvement can be achieved by a total change of architecture (e.g., non-von Neumann computers), but then you lose all compatibility with the current machines. > By definition, software cannot defeat software. All it takes is > the next generation of viruses, and the antivirus programs must > be updated. And all it takes is the next generation of antiviruses, > and the *viruses* must be updated! This is true, but unfortunately the same holds for the hardware solutions, at least for the ones currently used. > Unfortunately, the reverse is true: since the virus/antivirus > utilities have appeared, the number of infections, and the number > of viruses have both increased dramatically. The number of affected > machines is higher, not lower. The overall number of virus types > is increasing at a mad pace. The incidence of cases around the Speak only for the IBM PC world. In the Mac world exactly the opposite is true - very few virus variants. > > If the scan strings are carefully chosen, they give few false > > alarms and detect many future virus modifications. Oh, yes, and > > they also get sometimes fooled by Rosenthal's program... :-) > Does this mean, then, that IBM's and McAfee's, and Microcom's, > and Skulason's and Central Point's and Symantec's and Jim Bate's > and Sophos' and TBScan and.... so many other scanners have all had > their strings not "carefully chosen", since they are ALL fooled > by the Virus Simulator? Should all of them choose their strings No, read my quote again. According to it, it means that their scan strings -are- carefully chosen, since they get fooled by the Virus Simulator. :-) > more carefully? Would choosing them "more carefully" prevent > false alarms (100% in many cases)? No, I don't think so. Show me. False alarms can be prevented by exact virus identification. This will miss slightly modified new variants, however. > It most certainly does. That's exactly what it does, and it does it > rather well. What better demonstration of the inadequacy of string > scanning than Rosenthal's Virus Simulator? It proves that virus > scanners can be fooled into giving false alarms at the rate of nearly > 100%, an incredible figure. Recall that the original Rosenthal's claim was that his program tests how well scanners detect viruses. Since he recently acknowledged that this was a misunderstanding and in fact his program only shows that some virus scanners can be fooled to cause false positives, we'd better drop this discussion, shall we? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Sep 91 20:08:02 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning LZEXE and PKLITE'd files (PC) PEPRBV@CFAAMP.BITNET (Bob Babcock) writes: > The "unexpandable" PKLite compression is actually quite easy to expand > on a '386. Load the program into td386 (Turbo debugger), single step > one instruction, set a hardware instruction fetch breakpoint at the > entry address (cs:100), and run the program. The built-in This usually holds only for COM files. > nonminally unexpandable files.) A scanner could use the same technique > without the memory overhead of the debugger; the td386 technique is for > examining a file which you have reason to suspect may be infected. I Then it would depend on being run on a 386 machine. > would think that a scanner could also extract the decompressing code > from the executable, remove the jump to the expanded program, and use > that to expand without executing. Much better is to -understand- how the decompressing code works and to implement its algorithm in the scanner. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Thu, 26 Sep 91 23:20:08 +0000 >From: ccusg@wombat.newcastle.edu.au Subject: Michealangelo and Stoned (PC) Recently I have been having to deal with multiple partition table viruses. That is machines being infected with either Michealangelo or Stoned and then being infected with the other. This causes the machines to hang. The first virus copies the MBR to sector 7 (on the Hard Disk) the second infection copies the first virus over the top of the now moved MBR at sector 7. The machine now has no MBR and will not boot from the hard disk but will boot from floppy disk. If you run a virus checker over the machine the checker will report the second virus. If the second virus is removed on a further check the first virus will be present. On using a virus removal agent the program reports the virus to be cured but! all it has done is recopied the first virus back from sector 7. A quick and dirty cure is to use Nortons disk editor to zero out both sector 1 and sector 7. The let Nortons disk doctor re-instated the Partition table. PLEASE NOTE !! I have only tried this on single partition 20MB drives and If you do not back up your data before you try this I'm not to blame!!!!. An interesting note is that none of the Anti-virus programs I used altered sector 7 after disinfecting the viruses. Bruce Hodge Computer Support Officer University of Newcastle Australia ------------------------------ Date: 26 Sep 91 20:53:15 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Theory and practice turtle@darkside.com (Fred Waller) writes: > If it did just that I wouldn't have objected. The "heuristic virus > analyzer" boldly proclaims: "A BADLY WRITTEN PROGRAM" when it finds > something that, in its opinion, is not the way it should be. But Indeed, I see that the message may sound upsetting for some people. Maybe Frisk should change it to a more appropriate/polite one, in order to keep such people happy. Frisk? > > Well, when I tried Mark Washburn's program, it just hung my > > system, so I stopped using it at all. Well, to be honest, it > > was a rather old version - 2.11 or something like that. I have > > to try version 2.30 and see if it works. > Perhaps reading the .DOC files might have helped. SECURE will I did... :-) and -before- running the product. I even examinated it a bit before testing it. You see, one gets suspiccious when he receives a program that is written by a well-known virus writer... ;-) > -stop the CPU- at the first notice of infection because even a > single instruction that's allowed to be executed after an illegal > attempt is detected could be enough to give control to the virus. Yeah, but a small message, explaining what happened would be appropriate, don't you think so? As soon as the program was started, it just hung the machine without any notice. I don't call this a good anti-virus program, especially having in mind that there was no virus around at that time... > The freezing is intentional, and is the best defense: to -stop- > a virus from infecting, -before- it invades a system, rather than Yeah, yeah, but when I inverstigated the problem, it turned out that SECURE was too confident about the INT 2Fh/AH=13h function... :-) > software. However, it's also possible to make reasonable choices > as to what is the -best method- for designing protective software. There is no best method. There are just several methods, which when combined can give a reasonably good protection. That's all. > While it's not easy to disable SECURE, it's indeed possible and has > been done in the laboratory. In order to do so, one must have the > particular issue of the program which one wishes to subvert. You > can't write a program to defeat SECURE ahead of time - you can only > do so for versions that have been already published. And it doesn't > have to be a virus. A demo program was written that allowed the > removal of -one- specific version of SECURE from memory. Since > SECURE is updated frequently, this provides more than enough > security and SECURE is indeed able to stop every known virus from > infecting a system. Correct, but the above argument perfectly holds for SCAN as well. It also has been subverted - but only particular versions of it. It also is frequently updated - much more often than SECURE. Of course, this does not mean that SCAN is better, worse, or equal to secure - just that both of them can be aim of similar attacks. > Whether it is or is not possible to design a bypass to SECURE, the > important consideration is that, of the currently known viruses, > none can bypass it. In practice, it's almost irrelevant whether > some "researcher" can design some way to bypass SECURE's protection. > Such theoretical bypass is not infecting computers anywhere. > It is not a practical threat. The problem is that besides of researchers, there are also virus writers. And while the researchers contend themselves to speculate how a particular protection scheme could be bypassed, virus writers implement such things in their nasty creatures. And this -is- a practical threat! > If we further consider that there are only 40 or so -actual- viruses > spread in the field [and not the 600/900 that some "scanners" > purport (what for?) to "detect"], it becomes even more obvious that > a program such as SECURE is by far the wiser choice. In an ideal The consequent does not follow from the antecedent. It would be also possible to use a scanner that scans only for those 40 viruses and just forget about the others. Unfortunately, this does not work. And, - -who- can say -which- these 40 viruses are? > infection, they only detect it after it occurs. But if every > computer in the world were protected by programs such as SECURE, > infections by viruses as we know them today would cease to occur. If every computer in the world were protected by one and the same program, it would be a disaster! This would mean that any virus, which manages to bypass the program, can spread wery widely and almost instantly. > > I have also to test it against some of the most clever > > Bulgarian viruses... > Well, I don't know. Would these be still unpublished ones? Well, the Darth Vader viruses cannot be stopped by SECURE (or any other soft/hardware thingo that checks for illegal behaviour), since they don't use anything illegal... It is true that they are damn slow to spread, but if they are not stopped... I also have the feeling that the Compiler viruses won't be stopped either, but I'm not quite sure and have to check this. > If you have any viruses that can bypass SECURE, you should make > a copy of them available to the author, so that he can improve > his program and eliminate any loopholes you might have found. > If you have found any loopholes. This is undoubfully how I would react towards any legitimate anti-virus researcher. NOT in the Mark Washburn's case, however. He has discredited the word "anti-virus researcher" (just as Ralf Burger) and I will by no means help him, unless I feel that it would be good for the whole society, which I don't. Besides, if he wants these viruses so much, he could contact the Virus eXchange BBS in Sofia - it is made, run, and used by people like him. > > Just try to use PC Tools or Norton Utilities, without > > registering them properly in the database file... :-) > The immense majority of computer users do not employ programs > designed to edit executables. Those who do, usually have enough > knowledge of computers to deal with virus threats in a much > more effective manner anyway. > > And if you -do- register them and give them the appropriate > > rights to modify executable files, a virus which infects them > > will gain the same rights. > Only to infect -one file-! As soon as *that file* tries to infect > another, it will be stopped for good. No more virus spread. No OK, OK, maybe the example used wasn't the most appropriate. How about a compiler/linker then? Does anybody who uses such thing have the appropriate experience to deal with viruses? And if you register the program in the database, and compiled file will contain a virus (if the program becomes infected). If the virus spreads only during the compilation process, it will go unnoticed. This is exactly how the Compiler virus works. > damage to program or data files. No crosslinking of clusters. > No scrambling of FATs. No encrypting of hard disk contents. No > deletion of valuable files. No loss of data. No further spread > to friends or associates. No virus. Don't tell me that it is not possible to -destroy- the information on a disk, protected by SECURE. It isn't. I'm refering to your own remarks about software defeated by software, with which I totally agree. > > I strongly suggest you to read the paper "Computer Viruses - > > Theory and Experiments" by Fred Cohen. It explains the very > > basic things in computer virology - a knowledge that you > > really need to avoid some theoretical traps when dealing with > > the computer virus problem. > I strongly suggest you read the .DOC files that come with the > programs you try to use. :-) Doing so may help you understand > the difference between theory and practice. By the way, consider > this my third request to ease up on _ad hominem_ comments. I -do- have the (boring) habbit to read the documentation before trying a program. My remark about Cohen's paper doesn't seem to be inappropriate, since at least 11 people sent me messages, requesting more info - that's why I published the short bibliography. This is a public forum, after all. As to the "you" in my second sentence, it does not refer to yourself in particular. Maybe I had to use the "one really needs" form. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 175] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253