cs106132@uunet.UU.NET (cs106132) (05/04/91)
Hello, I was testing the new release of F-PROT 1.15a the other day, and came across an interesting problem. It happened when a variant of 4096 was active. Since F-PROT did not know this strain, it could not detect it. This is expected as the documentation hints. However, when I ran F-OSCHK, the virus infected the system files (IBMBIO....), the result was a non-bootable hard disk. This indicates that F-PROT can actually contribute to the spread of this kind of viruses. This is not a bug type of thing, it is a design flaw! I repeated the same test using FluShot+ (1.81), the same thing happened in a slightly different manner. But the system again became impossible to boot from the hard disk. I had to run SYS C: to restore the sanity of the system. Any comments? Regards, Tarkan
c-rossgr@uunet.uu.net (05/07/91)
>Date: Fri, 03 May 91 17:10:20 +0000 >From: umbc3!umbc3.umbc.edu!cs106132@uunet.UU.NET (cs106132) > >.... It happened when a variant of 4096 was active. >...., the virus infected the system files (IBMBIO....), the result >was a non-bootable hard disk. This indicates [it] can actually >contribute to the spread of this kind of viruses. This is not a bug >type of thing, it is a design flaw! > I repeated the same test using FluShot+ (1.81), the same thing >happened in a slightly different manner. But the system again became >impossible to boot from the hard disk. I had to run SYS C: to restore >the sanity of the system. Any comments? Obviously I have a comment! :-) Please let me know more about this varient on 4096 and I'll fix it up in the next release of FLU_SHOT+ (Current release, by the way, is version 1.82, released 4/7/91...next release is due out shortly). Ross M. Greenberg Author, FLU_SHOT+ & Virex-PC
padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (05/07/91)
>From: umbc3!umbc3.umbc.edu!cs106132@uunet.UU.NET (cs106132) >I was testing the new release of F-PROT 1.15a the other day, and came >across an interesting problem. It happened when a variant of 4096 was >active. Since F-PROT did not know this strain, it could not detect >it. This is expected as the documentation hints. > However, when I ran F-OSCHK, the virus infected the system files >(IBMBIO....), the result was a non-bootable hard disk. > I repeated the same test using FluShot+ (1.81), the same thing >happened in a slightly different manner. But the system again became >impossible to boot from the hard disk. Simple integrity checking (e.g. intelligent use of CHKDSK-type values) would have revealed that something unusual was going on, particularly with the varieties of 4096 that I have seen since a memory mis-match occurs. You get what you pay for. Warmly, Padgett
frisk@rhi.hi.is (Fridrik Skulason) (05/09/91)
umbc3!umbc3.umbc.edu!cs106132@uunet.UU.NET (cs106132) writes: >It happened when a variant of 4096 was active. Since F-PROT did not know >this strain, it could not detect it. This is expected as the documentation >hints. However, when I ran F-OSCHK, the virus infected the system files >.....This is not a bug type of thing, it is a design flaw! This problem is of course not unique to F-PROT - every other scanner has this same problem. In fact, the DOS 'COPY' command can also cause a similar effect - infection of files when they are read. Is it a design flaw in DOS ? The reason for the problem is as follows: If a file is opened for reading, with a virus active in memory, the file may become infected when it is read. A scanner may therfore infect the entire system, just by scanning the files. This is the major reason why one should generally only run a scanner after having booted the computer from a write-protected system disk. The problem is harder in the case of a "stealth" virus, like 4096, as no change may be apparent after the files are infected. This can be avoided by either scanning the memory for viruses before scanning the files, or by running a resident virus-monitor which will prevent the virus from ever being activated. However, in the case of a brand new "stealth" virus, as in this case, these methods are of no use. Memory scanning will not detect anything, and file scanning will just help spreading the virus, and will not pick up any infection. So - with the current generation of scanners, this problem cannot be avoided. - -frisk
c-rossgr@uunet.uu.net (05/09/91)
>From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) > >Simple integrity checking (e.g. intelligent use of CHKDSK-type values) >would have revealed that something unusual was going on, particularly >with the varieties of 4096 that I have seen since a memory mis-match >occurs. You get what you pay for. Oh! I see now. Anybody know where I can get six bytes worth of integrity checking, cheap? A simple problem was posted to the mailing list, and it'll be fixed in my code shortly and, I would presume, in frisk's code, too. By stating that you "get what you pay for", I would presume that you're advising both frisk and me to raise our rock bottom prices? Sorry.....Homey don't play that. Ross M. Greenberg Author, FLU_SHOT+