VIRUS-L Digest Friday, 17 Mar 1989 Volume 2 : Issue 66 Today's Topics: re: Virus hysteria. overprotection, lowercase VM filenames, corporate espionage Re: File lock protection? (Mac) Virus Publicity & the Media Re: File lock protection? (Mac) notarization New virus (PC) nVIR infection on MAC --------------------------------------------------------------------------- Date: Tue, 14 Mar 89 15:07 EST From: Eric Thies Subject: re: Virus hysteria. >Date: Mon, 13 Mar 89 08:40 EST >From: Cincinnati Bengals. >Subject: Virus hysteria. > > I was wondering if anyone has comments on the way reports of >viruses seem to be given too much attention by the media. As an [...] >Surely this is newsworthy, but front page? This seems comparable to >placing reports on the front page every time the common cold breaks >out on campus. Comments? Yeah. We got about the same reaction a while back when we had a few problems with a virus. And about a week later, the internet virus hit. The papers sort of lumped everything together; one even claimed that we had 25 or so computers hit by the internet virus. Actually we had 25 or so floppy disks hit by the PC virus and weren't touched by the internet virus (we aren't on the internet (yet) :-) I get the feeling that computer viruses are the new boogie man. For most people, computers are these big, mysterious things which sort of 'control' things...and the idea that these viruses can 'destroy everything' is terribly frightening to most. This parallels the fear that the word Communist used to (and for some still does) invoke. Something that most don't know much about and that can destroy everything... something we can't control...since it has control...makes us feel HELPLESS. The media love to pick up on things that scare the hell out of folks...fear and sex sell. Just wait for a virus that draws sexy pictures...:-) >Tom Kummer - -eric ++==++==++==++==++==++==++==++==++==++=++==++==++==++==++==++==++==++==++ Eric Thies, Systems ethies@uncg.bitnet Academic Computer Center ethies%uncg.bitnet@cunyvm.cuny.edu Univ. of N. Carolina at Greensboro ethies@ecsvax.uncecs.edu Greensboro, NC 27412-5001 Tel: (919) 334-5350 "Peace, love, waterbed." ++==++==++==++==++==++==++==++==++==++==++==++==+==++==++==++==++==++==++ ------------------------------ Date: Wed, 15 Mar 89 04:22:11 EST From: Steve Subject: overprotection, lowercase VM filenames, corporate espionage I just wanted to comment on some things: Reed Rector suggests that he'd be willing to pay more for a program that incorporated some kind of anti-viral or virus-detection feature. I wouldn't. First of all, I am very picky and have enough trouble finding software that has precisely the features I want, so I could care less about an added new-fangled and probably ineffective anti-viral feature. Second, I rarely come across viruses (none so far that I know of. In fact I don't think I even know anybody who has actually seen a virus. Yes, I got a copy of CHRISTMA EXEC, but I wasn't stupid enough to run it...). Second, I prefer to protect myself by keeping backup copies of things I care about (on write-locked diskettes); this is also good protection against the most common problem I encounter: corrupted portions of a disk (NOT due to a virus or the like, but instead due to a bad or marginal sector, or a program that doesn't check to see that you haven't switched diskettes before it writes). Sophisticated file encryption schemes would waste my time (but it wouldn't hurt to have checksums somewhere so I could check the integrity of my files should I ever suspect viral activity). I am in agreement with what Don Alvarez said so very well about all this a few months ago. Bruce Ide mentions a program that changes all your (VM) filenames to lowercase on an IBM mainframe system. I encountered lowercase filenames by accident initially (created by one of my own programs). I now have EXECs which rename mixed-case filenames to or from uppercase. This sort of thing is really not a problem. And there's always VMBACKUP (automatic backups) if one finds a few files missing... Joe Sieczkowski raises the very interesting issue of a company patching a trapdoor into a competitor's computer. I would think that no company would be willing to risk their reputation on such an escapade. The secret would very likely come out eventually (or even serve very well as blackmail material for a disgruntled systems programmer). However... Steve Woronick | Disclaimer: Always check it out for yourself... Physics Dept. | SUNY at | Stony Brook, NY 11794 | Acknowledge-To: ------------------------------ Date: Wed, 15 Mar 89 09:10 EST From: "Brian D. McMahon" Subject: Re: File lock protection? (Mac) >MacUser magazine reported in the Tip Sheet section of their April >issue that locking individual files using the Locked bit of the Finder >info (using the Locked button in the Get Info window, or a file >utility program) will prevent virus infection. [ . . . ] >My question -- will this really accomplish anything? Can any known >viruses infect an application file that has its Locked bit set? No. A file that has been locked by software can also be *unlocked* by software. On the Mac, this is darn near trivial -- I think it would be a matter of only a few bytes of code in the virus, to call the appropriate unlocking routine. (Where is my _Inside Macintosh_ when I need it?) While I don't know for certain whether any of the known nasties actually do this, relying on software locks is definitely unsafe. >Mark H. Anbinder >Department of Media Services >Cornell University Brian McMahon Administrative Computing University of Maryland University College ------------------------------ Date: Wed, 15 Mar 89 09:02 MDT From: "Craig M." Subject: Virus Publicity & the Media I agree with Tom Kummer--I think there is too much "sensationalizing" of a virus outbreak. An even more obvious example than the front-page newspaper article is our University of Utah's Mac outbreak. It not only hit the Deseret News and Salt Lake Tribune (although not front page), all three network station carriers reported it on the evening news. It also hit a cable news station, but it was later at night. They must think that something like this is outstanding and will capture more-than-normal public attention; I can't imagine what else it could be. ------------------------------ From: Danny Schwendener Subject: Re: File lock protection? (Mac) >MacUser magazine reported in the Tip Sheet section of their April >issue that locking individual files using the Locked bit of the Finder >info (using the Locked button in the Get Info window, or a file >utility program) will prevent virus infection. All currently known viruses will fail to infect a file if the latter is locked. All viruses (current and future) will fail if the *disk* the file is on is locked. The difference is that locking a file merely causes a bit in the file information to be changed, while (hardware-)locking a disk physically disables all write-accesses to the volume. Software-locking of files or volumes may be bypassed, albeit not easily. Moreover, some applications, which save their settings in the data fork or in a resource within the application file, won't work correctly if they have been previously locked. So it is not a good idea to rely on software-locking as only protection against viruses. - -- Danny Schwendener ETH Macintosh Support ------------------------------ Date: Thu, 16 Mar 89 08:55 EST From: Lambert@DOCKMASTER.ARPA Subject: notarization >You STILL need a clean channel for transmitting the decryption key; >else anyone can modify a decrypted version of the signature file, >encrypt it again with another public key set and distribute the >new decryption key with the new signature file. This is a trivial >step for anyone who actually desires to modify the signature file. >Public-key cryptography is just begging the question. Not true. All signatures for a hierarchical notarization system would be verifiable to a single primary authority. The ONLY trusted distribution required for the system would be the public certificate of the "root" certification authority. The following illustration should clarify this proposal. Pa is the public certificate of authority "A" Sa(Pb) is the public certificate of "B" signed by "A" Pa | ------------------- | | | Sa(Pb) | Sa(Pc) ------------ ------------ | | | | | | | | Sb(Pd) Sb(Pe) Sc(Pf) Sc(Pg) A more formal description can be found in ISO DIS 9594-8 where ASN.1 is used to define a certificate as: Certificate ::= SIGNED SEQUENCE { signature AlgorithmIdentifer, issuer Name, validity Validity, -- a time period subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo} The important part of this certificate defintion is that the certification authority (CA) binds the subjects name, the subjects public information, and the certification authorites name (issuer) together with a digital signature. Extending the definitions in 9594-8 for the notarization of files a posible "dataseal" would be: DataSeal ::= SIGNED SEQUENCE { filename OCTET STRING, filelength INTEGER, algid AlgorithmIdentifer, issuer Name, filehashvalue ENCRYPTED OCTET STRING -- where the octet string is the -- result of the hashing of -- data in 'filename' } The definition above would allow the sealed data, the "dataseal" and the certificates to be distributed separatly. Paul A. Lambert Motorola GEG, Secure Network Section Lambert -at docmaster.ncsc.mil 8201 E. McDowell (602) 441-3646 Scottsdale, Az. 85252 ------------------------------ Date: Thu Mar 16 09:16:13 1989 From: utoday!greenber@uunet.UU.NET Subject: New virus (PC) Just a quick note on a relatively new virus, and a "directed" virus at that: One of my larger clients called me in because they discovered that some of their dBase files were corrupt. Wanted me to fix them up. When I got there, I discovered that a database file (all have .DBF extensions) worked on machine A, but when the files were copied to floppy, they didn't work on machine B. But they would work on a machine which had Machine A's copy of DBASE brought over to it. Upon investigation, I discovered a small TSR virus on Machine A. It had infected the DBASE program which was later run on MAchine C, hence why it worked there. The virus, after spreading to all .COM and .EXE files in the current directory, would look for an open operation on a .DBF file. All writes to the file would have two bytes transposed at random. These bytes' offsets were stored in a file called "BUG.DAT" (a hidden file) in the .DBF's directory. Subsequent reads of this data would cause the transposition of the same data, and everything would look nifty. After this code had run for 90 days (after the BUG.DAT file was 90 days old), it would trash the disk (eat the FAT and root directory). Getting rid of the virus wasn't difficult: just copy in new executables from your backup. However! If you did this, your data is history - nothing to transpose it back into "real" form. What I did was to debug the heck out of the virus, find the *write* transposition and null it out, then read each corrupted data file and write it back out. Look for the sequence "MOV AL, ds:[bx+si] MOV AH, ds:[dx+di] XCHG AH, AL MOV ds:[bx+si], al MOV ds:[bx+di], ah" and either null out the XCHG operation or all of the above. This effectively will remove the transposition only only on the write (for some reason, the reverse transposition on the read used substantially different code). After nulling it out, simply use the infected DBASE program to read all the corrputed files and to write them back out to a new file. Viola! Now, copy over the infected code with your backup copy of the executable and things should work out well. Since this is a TSR virus, make sure to do a boot operation after you've done the "repair" on the DBASE program. Obviously, you'll have to disinfect all the other programs on your disk as well. Look for the sequence "ssi" at offset location 7. If found, you've found an infected file. The scary part: if you're infected and just remove the infection, your data becomes worthless. I've only seen this virus at one site so far. Ross M. Greenberg UNIX TODAY! 594 Third Avenue New York New York 10016 Review Editor Voice:(212)-889-6431 BBS:(212)-889-6438 uunet!utoday!greenber BIX: greenber MCI: greenber PCMagNet: 72241,36 ------------------------------ Date: 17 March 1989, 01:30:05 ECT From: Anders Christensen +47-7-59-3004 Subject: nVIR infection on MAC Some users at our university claim that their Macintoshes have been infected by nVIR after they inserted and then removed an infected diskette, without executing any program on (or booting from) the infected diskette. One of the users claims this happened: - He booted from a writeprotected 'clean' original diskette - He formated the harddisk, and moved the system and some other software there (all writeprotected and 'clean') - He then tested the system with VirusDetective and Interferon without getting any warnings - Then he inserted an infected diskette, and removed it immediately without running any program - He then ran VirusDetective and Interferon and got a message that the harddisk has been infected by nVIR. The above would be possible if the Mac loaded executable code from the diskette into memory and started executing it whenever a diskette is inserted. Is there any Mac-Wizard who can tell me if Macs behave like this or not? Anders Christensen User Consultant Computer Center (RUNIT-D) Norwegian Institute of Technology ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253