From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V4 #182 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Friday, 4 Oct 1991 Volume 4 : Issue 182 Today's Topics: Anti-virus sources off the nets? Checksumming (was: SunOS virus checker needed) Why Bulgaria? Re: DIR II (Cluster) Virus (PC) Disabling floppy boot on Packard-Bell Help! NOINT Virus Info? (PC) Re: New Virus Warning (PC) Ultimate solution I class DIR II as destructive (PC) Re: Hardware vs. software Bulgarian virus writers (PC) Re: DIR II Removal Information (PC) new programs by Padgett; report (PC) 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, 03 Oct 91 17:21:21 +0000 From: lunde@casbah.acns.nwu.edu (Albert Lunde) Subject: Anti-virus sources off the nets? I will be talking to some people on virus prevention. They are from business, and don't have much access to the "academic" nets like bitnet, internet and uucp. What is available from sources like Compuserve, GEnie, Delphi, BIX? I know Disinfectant is posted to a lot of these systems, but I have no idea about PC stuff, or about where (what SIG or library, etc.) this stuff would be kept. This might be another question to add to the periodic postings. [Ed. Don't forget that Compuserve and MCIMAIL (probably others also) are connected to the Internet; they can both exchange e-mail with any Internet site. In addition, I'd suggest looking at NIST's Computer Security Bulletin Board at 301 948 5717 (2400 baud) or 301 948 5140 (9600 baud), or one of the various commercial services. The NIST board, by the way, is also accessible directly from the Internet - telnet to csrc.ncsl.nist.gov and login with the username and password of "bbs". There is also an anonymous FTP archive on the same machine.] - -- Albert Lunde Albert_Lunde@nwu.edu alunde@nuacvm.bitnet ------------------------------ Date: Thu, 03 Oct 91 19:44:00 +0300 From: Y. Radai Subject: Checksumming (was: SunOS virus checker needed) Due to a 5-week vacation, I've only now caught up with the back issues of Virus-L. Out of the mass of postings, one interested me in particular, partly because it's on my favorite topic (checksumming) and partly because it was a challenge to try to figure out why the author wrote what he did. I'm referring to the posting by Tommy Pedersen, which starts out as follows: >Well using a regular CRC integrity check does help, but it is not a general >solution. A virus can easily fool the checksumming program by simply adding >a pattern which makes the checksum correct. This approach would therefore >only work if the checksumming algorithm is kept secret, but that is of course >not a good solution. Sorry, that's incorrect. It is not necessary to keep the *algorithm* secret. (In fact, we are assuming that the algorithm is CRC, which is publicly known.) Only the *generator* (divisor) must be kept secret. And there's no reason whatsoever why that would not be a good solution. >A better and general solution is to use cryptographic checksums. It is then >free to distribute the algorithm used since the secret relies upon a small >key which can be changed very often and individually for the users. A virus >can not add a pattern which makess the checksum correct since it not knows >which key that has been used. The only way would be to break the crypto, and >that is much more involved than just adding a pattern. It's my guess that what Tommy has just affirmed of cryptographic algo- rithms, he denies of CRC. That is, he correctly states that with the former the key is separate from the algorithm and is never distributed together with it. But for some strange reason, he seems to consider each combination of the CRC algorithm with a different generator as if it constituted a *different algorithm*. This in itself would be nothing more than a terminological quibble, were it not for the fact that it is apparently this which leads him to think that with CRC the generator must be publicly distributed together with the algorithm. Well, my guess as to the source of Tommy's confusion might be all wrong (I'm just trying to "read between the lines"). In any case, the fact is that the generator never has to be made public when CRC is used for detection of viral infection on a given computer (as opposed to when it is used for an integrity check on transmission of files from one user to others). For this purpose, the generator can and should be chosen randomly or personally by each user. It is only necessary to keep the checksum table inaccessible to hostile programs so that they cannot compute the generator from file-checksum pairs. (Is this requirement inconvenient? No more so than ensuring that no stealth virus is active when checksumming is performed, and that is a *much* greater risk to checksumming than is checksum forging.) If this inaccessibility is maintained, then for detection of viral infection, CRC (with an unknown generator) is not the least bit less secure than cryptographic algorithms and it is much faster than the great majority of such algorithms. (Apologies to veteran readers of Virus-L who have heard me say similar things in the past, and to all readers for the late reply to a two-week-old posting.) Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Thu, 03 Oct 91 15:17:39 -0500 From: ROsman%ASS%SwRI05@D26VS046A.CCF.SwRI.EDU Subject: Why Bulgaria? This may be a FAQ, but I haven't seen it go by in the last year, so here goes? I have noticed that a large number of viruses are listed with Bulgaria as their origin. Does anyone have a notion why? Is it that the Bulgarians aren't on the net to defend themselves? A twisted sense of national pride? A single prolific and perverted programmer? What? Oz [Ed. See also Anthony Appleyard's related question below.] ------------------------------ Date: 03 Oct 91 21:07:53 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DIR II (Cluster) Virus (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > The virus is not able to infect disk partitions, which are accessed > through an installable device driver. Therefore, partitions accessed > through programs like Disk Manager are immune against this virus. Just for got to add this. The virus will not run on MS-DOS 5.0 or any other version, for which the disk device drivers to not reside in segment 70h in memory. Don't have a copy of DOS 2.0 to check. It runs perfectly, however, on any DOS version 3.0 to 5.00.223-beta. 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, 03 Oct 91 17:20:16 -0400 From: jones@mips1.info.uqam.ca (Jones*Peter) Subject: Disabling floppy boot on Packard-Bell Is there a way to configure a Packard-Bell PC in such a way as to prevent booting from its floppy. I understand that there is a way of configuring a PC so that disks will be tried in the order A (configured as non-existent), C (hard disk) and B (floppy). However, the local technicians tell me there is no way to do this on a Packard-Bell. I have read Padgett Peterson's approach using TSR's to prevent booting from the floppy. ------------------------------ Date: 04 Oct 91 00:07:51 +0000 From: wdh2866@zeus.tamu.edu (HAWKINS, WILLIAM DARYL) Subject: Help! Does anybody out there know of a virus which affects only floppy drives, and not hard drives? Whenever I try to read, write, or format a floppy disk in either a 5 1/4" 1.2 MB or a 3.5" 1.44 MB drive, I get errors ranging from data errors to track 0 bad..... I am cuurently running MS-DOS 5.0 on 386-25. Could this be a virus, or is it more likely a hardware problem ( i.e., disk drive controller)? Any help would be greatly appreciated.... Thanks in advance. Wm. Daryl Hawkins WDH2866@ZEUS.TAMU.EDU N106EX@TAMVM1.TAMU.EDU ------------------------------ Date: 04 Oct 91 11:15:23 -0500 From: boxall@qut.edu.au Subject: NOINT Virus Info? (PC) Does anybody no anything about the NOINT virus?? Vague details have been floating around Australia, but Exact information is required. Any info would be appreciated. Regards Wayne Boxall Computer Systems Officer Computer Virus Information Group Queensland University of Technology Australia ------------------------------ Date: Fri, 04 Oct 91 15:06:00 +1200 From: "Mark Aitchison, U of Canty; Physics" Subject: Re: New Virus Warning (PC) >... booted from a clean floppy, and then a CHKDSK /F > is run, then all executable files in the system will be destroyed. I am in the process of writing a replacement CHKDSK to put on our own machines (and could make it freeware if anyone wants it), to be less dangerous (but still helpful) in the hands of average users. It is going to check for oddities like viruses in memory, and viruses on disk (without, hopefully, making the situation worse), as well as check for file structure faults and bad blocks. It isn't meant to be a very fancy virus scanner, rather it aims to (with the aid of pre-assigned information about the system when clean) spot the easy viruses - including this new one. The important thing, though is to avoid anything that worsens the situation. What I'd like to know is: Am I safe in assuming that just looking at the directory entries, and at absolute sectors on the disk (or even via int 25h) will not cause a virus to infect a file that wasn't infected before? (Other than the boot sector) For that matter, any tips on "safe" simple tests would be appreciated (yes, I've already thought of the 6-byte method). While I'm on the scrounge for information... has anyone tested those programs that automatically squash data on your disk (Stacker & DrDOS's SuperStore) to see what various viruses do. My guess is that file infectors either won't work or will totally mess up the whole compressed partition, but even more I'm worried about disinfectant programs ruining the disk. I do have SuperStore, a few viruses, but not enough nerve to risk my data on the tests! Thanks in advance, Mark Aitchison. ------------------------------ Date: Thu, 03 Oct 91 20:41:20 -0700 From: turtle@darkside.com (Fred Waller) Subject: Ultimate solution Writes bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): > I claim that the increasing number of anti-virus programs is > a consequence of the increasing number of viruses. Such a claim might be more believable if most viruses had appeared *before* scanners first started to appear. They did not. > 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 great deal depends on how one defines "ultimate solution". If, by "ultimate solution", it is meant that people will stop writing viruses (or stop writing any other kind of program), then of course there will never be one. But if by "ultimate solution" is meant that the computers will become so much less vulnerable to virus infection that, for practical purposes, the threat will become more nearly insignificant, then it is certainly possible. Hardware defenses are the only reliable defenses. This is simply because no software attack is ever capable of overcoming a hardware defense. Conversely, it is not possible to design a foolproof, or even a reasonably-effective, software defense. The attempt to do so is a delusion, a hopeless pursuit of the Holy Grail. Software can defeat software only for a short while - until the next generation of software attack is designed. Then the cycle starts all over. Ad infinitum. Nor can hardware defenses be derived from symbolic/ software considerations. They must be designed on their own. Hardware, on the other hand, stops software attacks - and no new or improved software version can overcome it - ever. > 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. Oh, I would certainly hope that such drastic steps would not be necessary... I really hope not... :-) After all, a simple write- protect tab, which is nothing more than a humble fragment of black paper, stops ALL known viruses 100% of the time... far more effectively than ANY software written to date. And far more cheaply, too. >> 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. No, it doesn't. The next generation of viruses will be just as impotent against the humble write-protect tab as was the first --- and all generations after it. There will NEVER be a virus capable of defeating a write protect tab. The write-protect tab DOES NOT NEED to evolve, or be improved, or redesigned to stop viruses. It will continue stopping them - forever. That's how hardware protection works. > Speak only for the IBM PC world. In the Mac world exactly the > opposite is true - very few virus variants. It is much more difficult to write "illegitimate" code for the Mac OS because Apple does not make its details known, and additionally keeps changing the OS at every redesign of the machines. No, the comparison is not valid. Also, do all the antivirus software publishers service both markets? And what is the relative size of each? The Macintosh population is but a small fraction of the PC population. It's less interesting as a market, both for viruses and for antiviruses. >> 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. Well, when such "exact virus identification" is achieved, I'll take a close look at it. And, as soon as it is achieved, new viruses will emerge that will require a different identification... In the meantime, we don't have any "exact identification", as Rosenthal's Virus Simulator demonstrates. > 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,.... It wasn't Rosenthal who said that, it was me. And it seems I was in error, as it turns out. Rosenthal wrote afterwards that his engine extracts strings, position, and other information obtained in real time, as the scanner searches for viruses. This may provide validation to his claim that the Virus Simulator does indeed test the scanners in their function. >.....we'd better drop this discussion, shall we? In my experience, people who feel vulnerable in an argument are the ones who ask to drop a particular subject. If the manner of the discussion had been coarse or discourteous, I would understand the request. But since it has returned to a more decorous level I, for one, do not object to it. Certainly, Rosenthal has presented his points in scrupulously-decent format and I believe mine and other's postings on the subject are publishable too... I wish that everybody who writes for this newsgroup would post as decorously as Rosenthal has been doing. ------------------------------ Date: Fri, 04 Oct 91 09:28:40 +0100 From: Anthony Appleyard Subject: I class DIR II as destructive (PC) On 01 Oct 91, Vesselin Bontchev (Subject: Re: New Virus Warning (PC)) wrote: "since it [=DIR II] 's not intentionally destructive.". But it seems to me that (booby-trapping then affected store so (existing recovery programs which users are likely to use) destroy the affected data) counts as the same as directly destroying it, like ordinary explosive bombs with anti-handling devices. {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Fri, 04 Oct 91 09:20:28 BST ------------------------------ Date: Fri, 04 Oct 91 07:43:31 +0000 From: dave@tygra.Michigan.COM (David Conrad) Subject: Re: Hardware vs. software turtle@darkside.com (Fred Waller) writes: >Writes Dr. Chess: > >[...] > > But hardware alone is enough. To illustrate: there's no virus in > the world that can bypass a simple hardware device called a write- > protect tab. This humble little piece of black paper doesn't care > one bit about Cohen's theories. Disobeys them every time. :-) > >[...] > > But I repeat: a humble > paper write-protect tab comes as close to perfection, in this sense, > as anything can. Certainly close enough, and infinitely closer than > any software ever could. Can we not learn something from this? Yes, a write-protect tab will stop all viruses. It will also stop all application programs which write any data to the disk. In fact, it renders disks almost useless for storage, except for invariant programs and data. Recall the two 'Laws' for protection which someone has in their sig: "First Law: Don't buy a computer." "Second Law: If you buy a computer, don't turn it on." Let us not become too paranoid, and remember that the goal is not only to recognize or stop all viruses, but also to allow all valid programs. If this were not the case, then a perfect virus detector would be: begin (* cycle through all program on the disk *) writeln('WARNING: Program ',name,' is infected.'); end. - -- David R. Conrad | Telebit, Digiboard, Western Digital, Adaptec, Sales & Technical Support | DPT, Micropolis and Interactive Systems UNIX. Michigan Network Systems | Voice: (800) 827-6349 FAX: (313) 343-2928 dave@michigan.com | GREAT DEAL on new Telebit V.32bis 'til Oct 1! ------------------------------ Date: Fri, 04 Oct 91 09:36:52 +0100 From: Anthony Appleyard Subject: Bulgarian virus writers (PC) On 01 Oct 91, Vesselin Bontchev (Subject: Re: DIR II (Cluster) Virus (PC)) wrote: "The virus [=DIR II] has been created and released in the wild in May 1991 in Varna - a town on the Black Sea in Bulgaria. It has been created by two kids from the Mathematical Highschool there. They are also authors of the Shake, Dir, and MG viruses. <> The virus has been first discovered by Nikolay Spahiev from Varna and was reported by him on the VIRUS echo on FidoNet, but nobody payed any serious attention... I have reports that this virus is escaped Bulgaria and is extremely widespread in the Soviet Union, Poland, and probably Norway.". If these two disastrously productive virus writers are operating openly, as seems from the above, can't the government or law courts of Bulgaria act against them?? like the USA courts did with Morris and his Internet worm that time. {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Fri, 04 Oct 91 09:29:28 BST [Ed. This message is closely related to Rich Osman's (ROsman%ASS%SwRI05@D26VS046A.CCF.SwRI.EDU) question in today's digest. Vesselin Bontchev presented his paper, "The Bulgarian and Soviet Virus Factories", at last month's Virus Bulletin conference. The paper addresses both of these questions.] ------------------------------ Date: 04 Oct 91 09:09:56 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DIR II Removal Information (PC) 0004886415@mcimail.com (Joe Wells) writes: > here is the info needed to remove the DIR II (which Igor, Glen, and I > would like to see renamed the Cluster virus). More specifically, here Maybe Cluster virus is not that good as a name... The reason is that it describes a general method that this virus uses. What shall we do when another virus that uses the same method appears? IMHO, Cluster virus is as unappropriate, as Stealth virus. > A disinfector should be written only by a qualified (preferable asm) > programmer and tested extensively. A test prototype using the system Very true! I had to rewrite my own disinfector about ten times due to bugs, which caused it to malfunction with different disks... I had even to correct a bug in the Borland C++ 2.0 libraries... :-) > EXE extentions. The key is rotated left 1 bit for each entry WHETHER > THE EXTENTION IS EXE, COM, OR WHATEVER. > > Even though a directory may span several sectors, the internal key is > used to start each one. Yes, because each sector contains 16 directory entries, and after you rotate a 16-bit word (the key length) 16 times, you get the original number back. Besides, the virus infects the directory entries on a sector basis, this means that it may not infect the whole directory at once. One funny thing is that the directory entries, marked as deleted, are also infected - if they belong to COM or EXE files, of course. > The prototype simply checked all sectors and did simple testing to > determine if it was a directory listing or not. Any other method of > finding the sectors would work as well. Once a sector is found, set a Much faster is to search for all directories (with FindFirst/FindNext) and then for each directory traverse the clusters that it occupies in the FAT. Afterwards, for each of these clusters, check all their sectors. This method is of an order of magnitude faster than checking all sectors of the disk (especially for large disks), but it requires DOS 3.0 or higher, in order to get some of the needed information. > pointer to the first entry. Check the word at [ptr + 1Ah] for the > last cluster number. The word at location [ptr + 14] is normally 0 in > directories (unused by DOS), but here will be the original file start > cluster in encrypted form. If infection is found, get the original, > xor it with the key and put it at [ptr + 1Ah]. > Rotate the key (rol key,1) for every entry, infected or not. Yes, regardless whether the directory entry belongs to an executable files (infected or not), or not. A bit faster is to first generate all 16 possible rotations of the key and to store them in an array. > Add 20h to pointer for the next listing and repeat. There will be 16 > entries per sector to check. If infection was found and fixed, write > the sector back to disk. When done, overwrite the virus code. And, of course, when fixing the infection, don't forget to zero the word at location [ptr + 14]. :-) > Testing will be hard, unless you have the virus. If you don't have it, > don't bother. If you do have it and write a disinfector, let me know. Yes, I have one. It's written in Turbo C and besides of the disinfection process described above, is able to find and deactivate the virus in memory and to free the cluster(s), marked as used by the virus. It also performs a simple checksum on the virus body, so it is able to detect variants. The latter is extremely important, since if you rely only on a virus signature, it is sufficient that someone releases the virus with a slight modification of the directory entry encoding algorithm, and your program will begin to destroy the files, instead of disinfecting them. Of course, this is true for any virus, but particularly this one is extremely easy to modify in order to fool simple disifectors that do not perform exact identification. I'll send my disinfector to Ken and shall ask him to make it publicly available. My disinfector has a major drawback - it has no documentation (more exactly, the documentation is in Bulgarian ). However, I'll make its source available. I'll release this program to the public domain. [Ed. The disinfector has been received intact. I will forward it to the VIRUS-L/comp.virus PC archive sites. Any _archive maintainers_ who want a copy can contact me and I will e-mail or FTP it to them.] 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: Fri, 04 Oct 91 06:08:00 -0400 From: HAYES@urvax.urich.edu Subject: new programs by Padgett; report (PC) Hi. Now available: NOFBOOT.ZIP SAFEMBR.ZIP the new programs created by A. Padgett Paterson (and sent directly by him). Both programs are "freeware". NOFBOOT .ZIP Sent by Padgett Paterson. Alpha v.50. NoFBoot is a small (500 byte) TSR designed to prevent inadvertant booting from a floppy disk. With NoFBoot, a cold start (reset button or cycle power) will be necessary to boot from a floppy. SumFBoot (provided in the same .ZIP file) is an alternative to NoFBoot that may also be used. It allows a floppy boot when Ctrl-Alt-F is pressed. In this case if a floppy is NOT present the boot will be aborted. The programs will run under versions of MS-DOS from 2.10 to 5.0 and are designed to be transparent to the user unless a warm boot is requested from a floppy. In that case a warning message will appear. SAFEMBR .ZIP SAFEMBR v1.2 is an integrity checking Master Boot Record for IBM-PCs and Clones by Padgett Paterson. Sent by the author. This program is designed to replace the standard MS-DOS master boot record program with code that does more than just find the active partition and jump to the O/S boot record, SAFEMBR first checks the disk access integrity, its own integrity, and validates the indicated partition. SAFEMBR will detect all known Master Boot Record virus infections including those using "stealth" such as JOSHI and the EVIL EMPIRE as well as the most common infector, STONED. Used in conjunction with NoFBoot (C), the likelyhood of an undetected BIOS level infection going undetected drops to near zero. - ----- Bug report: the program included XXencoded in virus-l 4.180 arrived garbled; I was unable to decode it (got an "illegal character in line 3" error message). Any luck anyone? Regards, Claude - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 182] ******************************************