padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (09/20/90)
>The protection of "protected mode" could cut both ways, however. >Although it would be harder for a virus to gain access to a system, it >would also be harder to detect and kill. You can't scan memory for a >virus if you get nailed by a segment violation whenever you look >outside your own data. Must disagree on this one. I "own" my PC. As on mainframes, most of the time my processes are denied access to "privileges" - this does not mean that privilege is not available when requested, just that 99% of the time it is unnecessary, and, for many years I have had the habit of only taking on those privileges I need - that way programs requireing privileges not available to most users are identified early. Point is that just because you choose to protect the O/S from your "accidents", this does not mean that you are permanently locked out, nor that a virus is either. Already, in some cases, booting from a protected floppy is the only recourse for recovery (though EVERY virus I have seen so far, including 4096 and Joshi, are easily detectable in memory. - ---------------------------------------------------------------------------- > Our informal survey showed >that only 25-30% of the campus bothered to check their disks for the >virus. Part of that was the fact that users a) don't understand >viruses -- they don't WANT to understand them and b) they're so >amazingly apathetic. I have found that a small dose of education plus an easy, effective means of screening software does wonders. For too many years we just pointed people at a PC and expected them to use it like a typewriter or calculator. If users of systems in our care do not understand viruses or are apathetic about precautions, that is our fault, not theirs. - ------------------------------------------------------------------------------ (except from FidoNet posting provided by Frisk) > when we discovered the motherfish, the > decision was made to disavow its existence and any > public comment on it was prohibited...the file was > never made available through normal distribution based > on two findings 1. the virus can not be detected by > present methods 2. the virus is modularly constructed > to allow it to "learn" the methods used to detect it, > and then integrate this coded thought into its arsenal > of defense mechanisms This is pure B.S. and sounds like a politician. I know, am going out on a limb again since have not seen the "mother fish"/"whale"/"Gordius" as yet but am relying on the fact that by definition a virus must change things and ANY change is detectable. If the change is hidden then the mechanism used to hide the change is detectable, etc. 1st, any virus is detectable if not resident since it cannot hide itself from observation. If it is resident, then it must be resident somewhere. This is not to say that there are not some very tricky possibilities for residency, but even these are detectable. In the last few months my old three-byte test has grown to six-bytes (Joshi is easier to find when resident than when dormant unless you look specifically for the 1fh signature and I do not like signature tests - not that they are not effective, but that they require constant updates) Of course, my job is made much easier in that I do not have to identify infections, John McAfee and Morton and Frisk do an excellent job, all I need to know is that SOMETHING has happened & then reel out the arsenal. Similarly, this should be the attitude of users / generic detection software: determine that something has happened & call for help. This can be done with virtually no impact. To provide this environment is our responsibility. <end_of_soap_box> Padgett
padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (11/09/90)
>From: Dave Goodwin <GOODWIN@SMCVAX.BITNET> >We've recently picked up the DARK AVENGER virus on some of our >systems, and I'd like to see if anyone can detail the activity this >one engages in. It has been a while since I looked at this one but there are at least two strains: one which is a normal TSR detectable with MAPMEM, and the other is in upper memory detectable with CHKDSK. It is quite nasty and fast- spreading. After a certain delay (xx files infected) it will start corrupting files by writing a copy of a low disk sector into random locations on the disk. It does not use any "stealth" mechanisms not does it affect the boot sector or partition table. Infected files grow by c.a. 1800 bytes. >From: Michael_Kessler.Hum@mailgate.sfsu.edu > although anyone >knowing how to get to the shell from a software package can of course >bypass the protection. Some time ago I "fixed" COMMAND.COM so that a batch shell could not be aborted. All that is necessary is to find the "Terminate Batch Job (Y/N)?" string, back up to the INT 21 call that prints it, and then change the preceeding branch (JN if I rember right) to a JMP. It is a touch more difficult to remove the "system" feature from software packages, but possible. >2. To avoid infecting the network should a student use outside >software on various stations, we recommend that all stations be turned >off after use so that nothing stays in memory (Jerusalem B survives >warm reboots). This seems to be a common mythconception about the Jerusalem but good practise nonetheless. I suspect a direct invocation of INT 19 with POST would have the same effect (but haven't tried it). >3. Administrative and academic usage will be kept on separate servers. >We had one network utility which required an open directory that was >shared between the two sides, and I think that this is how the >infection migrated. Have seen this happen more than once & can be very nasty. Separate directories are essential. Network administrators need special training & tools. (editorial) >4. Until the infection, WordPerfect was in a single open directory. >Now it is in a read-only directory, but linked to its SETUP files in >an open directory. The common wisdom around here is that write >protected files can get infected, but files in read-only directories >will not be infected. It is not well documented, but if the directory files in SETUP (sft-F1,6) are left blank, WP will work in the current default directory. Typically, we just point the DOCUMENTS entry this way, but any of the others should also work. This will give you more freedom in location. Padgett
padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) (11/26/90)
- --------------------------------------------------- >From: s37775d@taltta.hut.fi (Pandy (A. Holmberg)) >Subject: Re: List of known viruses urgently required. >From: JAN-LIEN@vera.stacken.kth.se >Subject: Virus info databases I strongly recommend Patricia Hoffman's Virus Summary List (PC) and the Disinfectant by John Norstad (MAC) documentaion (both available from any number of electronic sources as REQUIRED reading. Having access to a VAX, the SEARCH command allows selective extraction and resorting of just about anything. On the PC, Q&A (by Symantec I think) is a good flat-file database or a custom flat file analysis routine is trivial (well, an evening) to write in BASIC. - ---------------------------------------------------------------------- >From: cjohnson@acsu.buffalo.edu (charles johnson) >Subject: Yale/Alameda (PC) >From: "Daud.R..Matthews" <D03T005@SAKSU00.BITNET> >Subject: Removal of EDV? (PC) These are both boot sector infectors. The Yale/Alameda originally just infected 360k floppies and the EDV could also infect the Partition Table though heaven only knows what varients have been cooked up. From floppies, just replace the boot sector using DEBUG (L100 0 0 1 with a good floppy in A and W100 0 0 1 with an infected floppy in A), however, any sector overwritten or marked bad by the virus will remain that way. (the bad sectors can be recovered, overwritten data cannot) According to my data, the Yale stores the original boot sector at head 0 track 39 sector 8. The EDV stores it at head 1 track 39 sector 8. Both go resident at the TOM & reduce total system memory (CHKDSK or the three bytes again). As to EDV surviving CLEAN, I have seen cases of Ghosting (viral code still attached to a file or in memory but disconnected from the execution path) & would suggest following CLEAN by: 1) COLD (power off) boot from a clean floppy. POST should wipe memory. 2) use DEBUG to read the HD partition table & boot record 3) if ok, boot from the HD, check for the TOM movement & run SCAN again. If the /m finds it in memory BELOW the 640k segment & CHKDSK returns 655360 bytes (640k) total memory, one of the files in CONFIG.SYS or AUTOEXEC.BAT used to be infected & is ghosting - try copying these files to a floppy and back to the HD in a different place. The smaller floppy cluster size should strip the remnant off. NOTE: this is not a one-size-fits-all procedure: TOM is only ONE of the "three bytes" but will work for Yale/Alameda or EDV original recipes. p.s. I would rather have a few "false positives" thatn ANY "false negatives" - ------------------------------------------------------------------------------ keithm@ashtate.A-T.COM (Keith Mund) writes: >Speaking personally as a software author, buy software from the >manufacturer or a legitimate dealer. The same fears you have are felt >by them manyfold... When the software houses start distributing their wares on notchless floppies like IBM, Norton, Intel, and Iomega (plus a few others) do, I'll believe it. Not perfect but a BIG step in the right direction. Padgett, had my Judge out yesterday & had nearly forgotten what a RA400/4spd was like. Now if I can just get the electrics fixed...