VIRUS-L Digest Monday, 5 Aug 1991 Volume 4 : Issue 137 Today's Topics: Infects on ANY access? Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16 Re: ME Re: Proposal for standard virus signatures notation Re: Info re viruses in shrinkwrap software? Floppy Door Close TSR? (PC) Viral operations in brief 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: Mon, 05 Aug 91 10:49:00 +1000 >From: STEVED@vaxc.cc.monash.edu.au Subject: Infects on ANY access? In trying to get myself upto speed on anti-viral techniques I came across the following. I quote from "The Complete Computer Virus Handbook", Price Waterhouse, Issue 2, September 1989 - Appendix 1, Page 19. Re the boot sector virus "Search" = "Den Zuk" = "Venezuelan". DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....." Now it may be just my understanding and usage of english words, but have I really missed something about how DIR accesses a floppy disk? SteveD@vaxc.cc.monash.edu.au ------------------------------ Date: 26 Jul 91 01:01:40 +0000 >From: andrew.mckendrick@p3.f854.n681.z3.fido.oz.au (Andrew McKendrick) Subject: Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16 Will it possible to request a copy of the transcript of the this conference after it has finished???? Andrew@fido - --- LED 1.00 * Origin: 520StE... Is Modula-2 wirth it?. (3:681/854.3) ------------------------------ Date: Sat, 03 Aug 91 17:22:58 >From: c-rossgr@ingate.microsoft.COM Subject: Re: ME >From: xa329@city.ac.uk >I was somewhat taken back with Ross Greenberg's abraisive response >(issue 125) to my posting (issue 119) about the anti-virus product >review in the UK magazine PC Plus. Without plumbing the depths of >personal abuse I would like to defend myself and respond to a couple >of the 'criticisms' made. Sorry: when someone attacks the professional integrity of a man I have respect for and of a journal I further have respect for, it ticks me off. > My discussion was of the review in PC Plus, not of the similar review > recently in the Virus Bulletiin. However if you are interested; Edward > is certainly aware of our product but he did not request a copy for > review. In fact the subject has never come up in our occasional > conversations. Hmmm. So, then you were aware of activity in the area, had made Wilding aware of your package but didn't get around to sending him one for review? Wilding probably should have requested a copy, but you should certainly have sent him a copy. If you want to be included in reviews, this is a good practice to start following. >>Ah, but what you write *does* suggest that you have a problem with >>either Hamilton's credibility or VB's or both. >My intention was to raise awareness of magazine readers of the possible >partiality of magazine reviews. Having seen all issues of VB, and even >having contributed (at a time when I had no other commercial interest in >the subject), I have had 2 years to form an opinion. However I shall >not force this on anyone, but rather respect that other people's range >from Ross's unstinting praise (well almost) to outright incredulity. Not unstinting. I've had many a complaint about VB, but not about its integrity. As for the potential problems with the accuracy of a review in any pub, I would assume that most readers of this list have seen many a review of a product in some publication that was totally off base. That accuracy is based upon the individual reviewer as edited by the editor; I've seen some factual errors in VB, but not incorrect slants. >I was present at one event that Hamilton subsequently reported on, and >my recollection differed from his report in only one area; the behaviour >of Hamilton himself and the subsequent response. This only underlines >the lesson I learnt from seeing events and names mangled in local >newspapers, seek corroboration of any news item that may affect you. I've been in a pub and witnessedd Mark spill a pint on himself. That does not somehow reduce his integrity. Ross ------------------------------ Date: Mon, 05 Aug 91 12:27:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Proposal for standard virus signatures notation nl84479@eamsvm2.vnet.ibm.com (Jan R. Terpstra) writes: > After lengthy discussions with a number of people, three independant > authors of virus scanning products and myself (as the keeper of the > VIRSCAN.DAT virus signature file) have agreed upon a standard notation > for virus signatures... Good. A nice wee standard. Now watch someone come along and complicate it! :-) I didn't see anything about where the name comes into it. How about having any line starting with a "#" giving the virus name(s) for the signature string in the line (or lines) below. Furthermore, the first name following the hash could be a hashcode (I gave the definition of my method of hashcodes for boot sectors a while ago - I'll post the updated algorithm and format, which now includes all sorts of file types as well as boot sectors and MBR's as soon as possible). And a "#" in a signature line could allow end-of-line comments. Also, it might be useful to extend the signatures by including an "@" to indicate absolute positions, with respect to the start of the file of boot sector, or offsets from the initial instruction, or the end of the file, etc. Such things might not be important now, but could be in the future, and could make scanning a lot faster. example... # This is an imaginary signature file, by msa@phys.canterbury.ac.nz; 05-aug-91 #05BXP7B.E1R, "Stoned (variant 7a)", "PORTUGESE STONED" @00:00@017B:B40206CD130914 #0TEEGYB.RB0, "Not harmful, MS-DOS 3.3 immunised by V-Basher 1.2" 17675A6C34D0@007E:17FFFF000023 #X587BG6.37Z-1280, "Dim Revenger virus" 19A6????53CD21ABBADABBAD00 ##IF OS=OS/2 - -147:AC??55C9129B # for code segments >64K ##ENDIF (What this means is... *The first line identifies the file; it is taken as a comment, since there are no signature lines before the next # line. It would be nice to finish each first line with a date, since some methods of transferring files from computer to computer cause the date-time stamp to be changed. * Each field in the hash lines finishes with a comma and one of more spaces, except the last. * If a hashcode is given, it is straight after the "#", otherwise you would have a space or spaces (no comma) before the first "name" field. I like to leave 17 bytes for the whole hashcode field, so the first name field will always start at column 20. * The first name field is the main, preferred, easily understood, name. * All name fields are enclosed within quotes (char 34), and end with a comma. Probably it is okay having a comma within the quoted field. Most high level languages should be happy with that. * The first letter of the hashcode indicates the type of file - 0 - F indicate boot sectors, G indicates a general file infector - could have any extension I indicates an invisible-file (IO.SYS, etc) infector M indicates an MBR (Master Boot Record, = Partition Table) virus O indicates an overlay file infector (okay, these are rare) P indicates a program infector (.COM or .EXE or .PRG or .BAS or whatever) R indicates a string to search for in RAM, rather than on disk S indicates a .SYS (system device driver) file T indicates a text file infector (such as .BAT, or some application data files) W indicates a worksheet (spreadsheet) infector of some sort X indicates a virus that only exists in .EXE files * Any line starting ##IF specifies a block of signatures, etc to skip unless a given environment variable has a given value. If environment variables "TOM" (for Top Of Memory), "VER" (for O/S true version number), or "HIDOS" aren't found, the program should make up a sensible value for them. Note that is doesn't hurt if a simple scanner simply ignores any line starting with "#", or a not-so-simple scanner remembers the last "#" line as a comment to emit whenever it comes across a file matching a signature. But ultimately, the signature file's format should remain useful for a long time, and scanners based on such files could be made to run very fast (by applying a limited range of scan patterns to some files, for instance, and by working on positional information). Comments on my comments are welcome, of course. TTFN, Mark Aitchison, Physics, University of Canterbury, New Zealand. ------------------------------ Date: Sat, 03 Aug 91 17:22:58 >From: c-rossgr@ingate.microsoft.COM Subject: Re: Info re viruses in shrinkwrap software? >From: greg@agora.rain.com (Greg Broiles) > >The latest issue of Byte has a cover story on viruses and security software - >a rather disappointing article, truth be told. They do some rudimentary >testing of a few antivirals and come up with a simplistic little >reccommendations-box. Blech. :( I did a tech article for BYTE on viruses a coupla years ago. Well, that is I *wrote* a tech article. What appeared in print was some horrid random assortment of words with verbs and nouns and everything except any accurate statements. What was printed was a "co-authored" piece, except that the co-author took what I wrote, pulled out things she didn't understand ("Vectors? They only have direction and speed...why would an interrupt have a vector?"), wrote a bunch of inaccurate stuff about Mac's, changed code sequences I used to identify one virus, decided that she, in her infinite wisdom, would never have a need to show me the article she destroyed, and printed it. My coplaints rose high up into the BYTE masthead -- to the top -- and were never responded to except with a "Gee, that's something that will never happen again". No retraction. No apology. Forget about BYTE's technical accuracy, at least with regard to viruses. Ross ------------------------------ Date: Mon, 05 Aug 91 11:58:47 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Floppy Door Close TSR? (PC) >From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) > Is there a TSR program available that scans a floppy whenever >the floppy door closes? Is it even possible to write one? Are any of >you all working on one (McAfee, Padgett, ...)? Considered this but think it would not be the "best" solution. Unlike the MAC, a PC does not execute anything merely by vitue of the door being closed. Executables have to be invoked by the user (even ANSI bugs are just designed to induce the operator to issue a command that was not intended - an executable still has to do the work). Consequently, there are two choices available that would have approximately equal value: 1) Detect that a new disk has been placed in the drive & do a full checkout. (time-consuming) 2) Examine executables as requested (includes warm-booting). (relatively little performance impact) For the above reasons, I personally prefer #2 and one of the layers on my personal machines is McAfee's* VShield. As far as I know (& am sure someone will correct me if wrong), this is the only currently available software that will trap a warm boot and scan relevant structures for known viruses before permitting the boot to continue as well as checking anything requested from the disk. Since my PCs are running DOS 5.0, I can afford the 25k for three different anti-viral TSRs that IMHO give me ample protection from malicious software, known & unknown, no one being considered sufficient. Just FYI, one goes resident during the BIOS load, one from CONFIG.SYS, and one from a .BAT file at startup (some other checking/reporting goes also on but this is not resident). Since a program to do this already exists and am still on negative free time, what time that is available is reserved for software that does not exist (yet). Padgett Disclosure: * is one of the lines the company I am associated with handles. (properly worded, disclosure notices can provide free advertising, no?) ------------------------------ Date: Sun, 04 Aug 91 20:36:27 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Viral operations in brief FUNGEN2.CVP 910804 Viral operations Although the "original" definition of computer viral programs refers to reproduction by attaching to other programs, viri that act in this manner having been less successful than those that use other means. In the personal computer world, boot sector infectors have been much more effective. (Examples in the MS-DOS community are the BRAIN and Stoned viral programs. Examples in the Mac realm are not as clear, but the WDEF virus could be said to be a type of boot sector infector, as the WDEF resource is one that is run automatically as soon as any Mac disk is inserted, although this has changed under System 7.) In larger systems, mini and mainframe computers, network and mail viral programs have, so far, had the greatest impact. The Morris/Internet/UNIX worm managed to spread and reproduce using the facility of networked machines to submit programs to each other. (A VMS program, WANK, used many of the same techniques.) The CHRISTMA EXEC used mainframe mail commands, and the ability to submit programs by mail, in order to reproduce copies which eventually flooded the network. Network and mail viral programs carry, in a sense, their own payload. The reproduction of the programs themselves uses the resources of the hosts affected, and in the cases of both the Morris and CHRISTMA worms went so far as to deny service to users by using all available computing or communications resources. Most other viral programs seem to be written "for their own sake". A kind of electronic graffiti which writes itself on further walls. However, even these can do damage, as with the Stoned virus, which overwrites sections of the FAT with the original boot sector. Some appear to be written as pranks, and others as a kind of advertising, although the potential for damage from even "benign" viri cannot be considered funny, and the "advertising" viri probably don't engender much goodwill. Relatively few viral programs carry a deliberately damaging payload. Those which do attempt to erase infected programs or disks are, fortunately, self limiting. The last payload, or function, which a viral program may carry, is some kind of intelligence to enable it to evade detection. So far the various kinds of evasive action; self-modification, multiple encryption and "stealth" activity; have not proven to have any advantageous "survival" characteristics. In one sense, this is to be regretted, as it demonstrates that the majority of computer users are not taking the most elementary precautions to defend against viral programs. copyright Robert M. Slade, 1991 FUNGEN2.CVP 910804 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 137] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253