VIRUS-L Digest Tuesday, 15 Oct 1991 Volume 4 : Issue 190 Today's Topics: re: Virus-writing course for teenagers Re: Azusa Virus hits University of Kentucky (PC) Ohio Virus #5 (PC) Re: Hardware/Software/Safe Machines Hardware Manners Theory Interesting? Gymnastics 15xx virus info?? SafeMBR v1.3 (PC) What damage does the Jerusalem virus do? (PC) Re: Forget Turing... Re: Hardware, hardware... A new version of virus (PC) Bontchev paper finally available in ASCII now Version 84 of McAfee anti-virus programs now available (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: Sat, 12 Oct 91 00:22:06 +0000 >From: Rotan Subject: re: Virus-writing course for teenagers On 10 October Y. Radai observed the syllabus of a science for yourth program which proported to include: (Comments from radai@hujivms) > Assembler. In this language you'll be able to acquire tools for things > which cannot be done in any other language, like: how to 'create > viruses', how to write protection programs and how to crack them. Furthermore, it is stated that: > Needless to say, the matter has been brought to the attention of the >program director, and it is expected that the above applications will >not actually get mentioned when the course is presented. It has also >been suggested that part of each course be devoted to a discussion of >computer offenses and rules of ethics. I don't see how avoiding mentioning such matters would avoid the further proliferation of virus-like entities. To deny our most able members of society the knowledge of such matters is a form of censorship that, frankly, I cannot accept. Certainly, I accept the worries that to afford people the knowledge of how such "viri" are constructed would possibly invite further development of the offending viri. But denial is not the correct manner or civilized way in which the problem should be tackled. To co-present the techniques of virus construction with the ethical considerations is perhaps the most desirable approach. Personally, I think the "course" as described, was so presented to attract a large audience with the heightened "mystique" of the latest and most pertinent problem concerning computer professionals. To do so, I think, was not correct. The motive may have been to encourage more people to attend the course. If this is the sole motive, then such a presentation is unjustified. Nevertheless, the virus problem is with us today. It should not be ignored. The most able people should be given the knowledge to tackle this problem. I suggest that such courses in "virus construction" be given. However, it is essential that this knowledge not be misused. Therefore careful guidance in the ethics is required. Sadly, in a world which seems to belittle the rights of software/hardware developers, it is hard to find any ethical foundation amongst the computing community (except where there is an obvious or potential financial risk). The medical community have established reasonable ethical frameworks. Isn't it time the computer community did likewise? Let's not hear any more about cencoring information about viri and concentrate more on ensuring that the people who compose our community are more responsible with the knowledge that is given to them. In times past, knowledge of a computing technique was always considered beneficial, now such knowledge has the potential for harm. The circumstances in which the computer professional finds h**self have changed. It is time we changed too, and stopped trying to deny the apparent reality which surrounds us. Rotan Hanrahan, Department of Computer Science, Belfield, Dublin 4, IRELAND. ------------------------------ Date: Sat, 12 Oct 91 01:11:46 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: Azusa Virus hits University of Kentucky (PC) tanu@beach.csulb.edu (Tanu Kartawiria) writes: >The Azusa virus was also found in Long Beach State University Lab, >SCAN and CLEAN found it, HOWEVER, VSHIELD doesn't seem to be able to >block it. Hello Tanu, VSHIELD will prevent you from rebooting the system off of an Azusa-infected disk (or a disk infected with any other boot sector virus that it recognizes), however, if a student were to cold boot the system off of his/her infected disk and then access the hard disk, the virus would transfer to it. VSHIELD would not report it's presence until the next time it was run. Regards, Aryeh Goretsky McAfee Associates Technical Support - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | aryehg@darkside.com(personal) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ Date: Sat, 12 Oct 91 04:14:45 +0000 >From: chris@MorningStar.Com (Chris Miller) Subject: Ohio Virus #5 (PC) Does anyone know anything about a virus called the Ohio Virus #5? It supposedly affects the boot track on msdos machines. Our entire dos lan at school is supposedly infected with this virus, and I would very much like to know how to detect it and eliminate it . If you know anything about this, I would appreciate some E-mail from you. Thanks in advance, - -Chris Miller ------------------------------ Date: Sat, 12 Oct 91 12:42:00 >From: UH2M@DKAUNI2.BITNET Subject: Re: Hardware/Software/Safe Machines In his reply to Fred Waller (virus resistant machine) Henk de Groot writes: >He forgets that some data-files are also program files (not for the >cpu but for a program on the program-disk) and a virus written in the >interpreted language can infect all the other "data" files of this >interpreter. >(...) >(...) but if I write a virus in his spread-sheed language and put it on >his machine, then after usage all his spread-sheeds are infected. If it >is a distructive virus than I may distroy all his spreadsheeds on >friday the 13th. I admit that Fred's machine won't make any sort of virus impossible - but that's not needed. They are like biologic germs: if they aren't too contagious, not very destructive or easy enough to cure, you can live with them. I think Henk's `interpreter-viri' would be much easier to live with than the machine-code-viri of today: 1) As today's viri need only a compatible Operating System to infect a computer, there are a lot of potential victims for them. Interpreter viri need `their' interpreter *running* on the target system, so the density of infectable computers is much lower in space/time. This would slow down the spreading speed of this viri. 2) A machine code virus uses the instruction set of the OS/BIOS, which is specially designed to do things like deleting, formatting, bending interrupts... An e.g. `spreadsheet virus' would have to do with the instruction set of the spreadsheet's interpreter language, designed for totally different tasks. While it might be possible to write self-propagating destructive programs in such a language, the coding of such neat things as stealth techniques would be quite difficult. The Antivirus-programs could still use all of the (BI)OS's services for their task and so the fight would be no longer `software vs. software' but `machine level program vs. high level language' - much better, compared with today! Axel ************************************************************************ * Axel Gutmann, UH2M@DKAUNI2 Internet: UH2M@IBM3090.RZ.UNI-KARLSRUHE.DE* ************************************************************************ ------------------------------ Date: Sat, 12 Oct 91 08:57:25 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Hardware Writes dave@tygra.Michigan.COM (David Conrad): > 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. If we could, just for a moment, stop and think, and not get carried away by impulse (or habit), we'd realize that the simplest hardware devices offer us, already completed, the solutions that software producers have been promising us for years... If the humble write-protect tab presents problems as well as a solution, why not try to work around the problem, rather than throw away the baby with the bath water..? Fred Waller turtle@darkside.com ------------------------------ Date: Sat, 12 Oct 91 08:58:17 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Manners The thread is lost to me but someone wrote not long ago: > This whole thread is rediculus. > -------..... -------.....-------- > I hope this will stop this stupid converstion. The subject of hardware protection is not ridiculous nor is the series of articles on it a "stupid conversation". If a given subject is of no interest to someone, s/he can always skip it. Or marshall argument, if not agreeable. However, qualifying someone else's postings as "ridiculous" or the articles as "stupid conversation" is not likely to cause the targeted author(s) to stop writing or to change their mind. In fact, it's almost guaranteed to have the opposite effect. Mature persons do not reject contradiction; they handle it. Inability to face contradiction is a sign of immaturity. Fred Waller turtle@darkside.com ------------------------------ Date: Sat, 12 Oct 91 08:59:25 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Theory Writes WHMurray@DOCKMASTER.NCSC.MIL: > Cohen has described a hardware mechanism that cannot be > subverted by software. It is called the application machine. > It is a computer such as... I would hope that just because Cohen has described it, it isn't the *only way* to do things... :-) > We recognize that progammability is too valuable to give up > simply in the name of resisting viruses. For some users, that may depend on how many viruses they end up meeting, or how frequently, or how valuable data integrity is for them. But no one has asked to give programmability up yet. What may be necessary, however, is to give up certain habits and modes of hardware implementation, the same ones that have made the virus threat possible. Such changes are related only moderately to ease of use, or flexibility, or data interchangeability among users. (*my* understanding of "moderately", of course...) It may also become necessary to modify certain programming habits/ methods. Ultimately, nothing is free. To ask for protection and be unwilling to sacrifice any freedom is quite unrealistic. Neither software nor hardware will ever give us that. Fred Waller turtle@darkside.com ------------------------------ Date: Sat, 12 Oct 91 08:56:27 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Interesting? Writes CHESS@YKTVMV.BITNET (David.M.Chess) on hardware protection: > Sure, no one's disputing that. The point is, though, > that that fact isn't really interesting. I think that depends on the direction of one's interest. If one is mainly a theorist and seeks ultimate (or at least very basic) theoretical justification, the statement may seem unattractive at first if it wasn't presented in a theoretically-attractive form. But if one is a practically-oriented person who seeks to solve problems on a day-to-day basis, the statement may seem very attractive and interesting. The reason is simple: hardware protection DOES stop viruses. In reality. > It doesn't, for instance, imply that a hardware-based > protection method would keep a system free of viruses > in the real world. The fact is, it has done that. In practice. Hardware protection doesn't need taxon-specificity and the large amount of constant disassembly work that this, in turn, requires. Hardware protection can be implemented at lower long-term cost than software protection, in part because it's of a more general nature. Hardware protection *doesn't care* what variety of bug is coming your way, or what it's name is, or whether it's ingenious or not - it just stops'em! All these are good reasons. > A virus can't defeat hardware protection by itself; on the other > hand, it will invariably have help, because people always want to > run new software on their systems, or otherwise want to open up > the software-space of their storage media for writing now and then. But doesn't the same reasoning apply to software protection? Users can defeat both hardware protection and software protection just as easily. However, while activated, hardware protection is more nearly totally invincible than any software scheme I know of. Fred Waller turtle@darkside.com --------------------------------------------------------------------- Eppur si muove! --------------------------------------------------------------------- ------------------------------ Date: Sat, 12 Oct 91 09:01:10 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Gymnastics Writes spaf@cs.purdue.edu (Gene Spafford): > The problem comes about when trying to reduce the > frequency of these errors to an acceptable threshold, > and to be sure that no Type II errors occur. Picking > any arbitrary levels of confidence may result in an NP > problem, but not an intractable one. That is so true. As we engage in mental gymnastics trying to determine whether Fred Cohen does or doesn't understand his own theories, one thing tends to be relegated to the background: physical reality. Viruses have become, more than anything, a practical problem. If a practical solution is stumbled upon, we can forgive the stumbling and adopt the solution. At least, I certainly can. The modified computing machine described in Fred (Waller's) reply to Jay Skeers works. It works at stopping incoming viral infection, and it works at restricting spread of infection after it has started. No software product is capable of doing that. It works better, longer and more reliably than any software antivirus product known. It is not a perfect solution, perhaps because there are no perfect solutions to any problem. Like any other protection, it can be disabled. Yes, a user can flip the switch OFF and disable it. But the same user can also disable any software protection with the same ease. There is no inherent vulnerability in hardware that software is not also vulnerable to. In fact, software has a great many more vulnerabilities than even the simplest hardware protection scheme. > So, could we please stop claiming that it has been proven that > no perfect virus detector can be built, or that finding viruses > is an intractable problem? I've seen this claim of a "perfect antiviral detector" over and over here. Many people make this claim, and many have announced it - but NOBODY is able to produce such marvel. As soon as someone writes an antiviral program that is as effective as a write-protect switch at stopping virus infection IN REALITY (not just in theory), I'll stop suggesting that such dream cannot be achieved. In the meantime, we can continue saying: while no viral attack is known that cannot be defended against with software, the reverse is also true: no antivirus exists that cannot be subverted, also by means of software. It's an endless merry-go-round. You say it isn't so? Then prove it. In practice. > It's not surprising, really, as the concepts of Turing > machines and intractability are not well understood -- > especially by systems hackers. :-) Well... let's keep in mind that all programmers are hackers. They explore and learn to use (more or less well) the machines that hardware designers create, build and make available to them :-) Fred Waller turtle@darkside.com ------------------------------ Date: 12 Oct 91 18:21:07 +0000 >From: gt7187c@prism.gatech.edu (Thomas Oates) Subject: 15xx virus info?? Can anyone give me any information on the 15xx (1591/1575) virus? My computer was just infected with it. I found it the same day that it was infected and got rid of it using Clean, but I would still like info on it. E-mail is ok. Thanks, Thomas Oates PS: if this is a FAQ, please let me know. - -- *********************************************************************** ** Thomas Oates gt7187c@prism.gatech.edu ** ** Georgia Institute of Technology - ICS(CS) Undergrad ** *********************************************************************** ------------------------------ Date: Sat, 12 Oct 91 17:59:50 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: SafeMBR v1.3 (PC) Version 1.3 of SafeMBR (FreeWare) now checks to see if it has been already installed to prevent multiple installations from overwriting the original MBR code. It is still recommended that the MBR be backed up to floppy before installing SAFEMBR just in case. Padgett ------------------------------ Date: 12 Oct 91 22:38:46 +0000 >From: D.W.Wright@bnr.co.uk (David Wright) Subject: What damage does the Jerusalem virus do? (PC) Sorry to ask a naive question to this group, but I don't know where else to find the info I need. I don't have FTP access so I can't go find the latest and greatest virus info list even if I knew of one. A friend has a PC on which "Characters slide off the screen when running Wordperfect and you have to hit some keys twice. I think we've got that Friday 13th virus, and I don't know how to get rid of it". Fortunately they had a disk that came on one of the PC mags with an old version of the McAfee anti-viral kit (v61), plus an old DOS system disk, which unlike most of their floppies were write-protected, so we scanned and cleaned their disk. Scan said it was the Jerusalem virus, and clean [Jeru] removed 127 infections from 20 odd different files (as you'll know, Jerusalem merrily re-infects files). I'll go over it again when I next see them with a more up to date package, but I think the system is clean now. However, their copy of Wordperfect no longer works - the machine crashes with "Illegal Instruction Trap". The latest McAfee Virus Characteristic List shows that Jerusalem "corrupts program and overlay files" but I can't find more details. Possibly clean did the damage - the documentation does warn that it can truncate files that use overlays. But it is also possible that the virus had started currupting things. They were probably running the machine over a month with the virus (given the likely source) and that included Friday 13th September. What is Jerusalem likely to have done to their system, and particularly to their files? Technical details of machine - early 386DX with 32M disk (all one partition) running DOS 3.3. CHKDSK shows no errors. Please reply by mail as most readers of this news group will either already know or not be interested - I'll summarise if anyone wants me to. Thanks, David Wright BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA, UK dww@bnr.co.uk ...uunet!mcsun!ukc!stl!dww PSI%234237100122::DWW ------------------------------ Date: Sun, 13 Oct 91 19:15:00 +0300 >From: Y. Radai Subject: Re: Forget Turing... Gene Spafford writes: >What Cohen proved in his thesis was that a program to exactly detect >all viruses on a Turing machine was an intractable problem. That is, >you cannot write a program that will run on a Turing machine and will >print "infected/not infected" with 100% accuracy for any arbitrary >program on that same Turing machine. ..... >#2. The proof shows that you cannot build a perfect detector on a >Turing machine. However, the proof depends on the fact that the >theoretical Turing machine has unbounded space for programs/data, and >has unbounded time to run. If you bound either, the proof no longer >holds. ..... >Now, consider that real machines have bounded time and space for >execution of programs. The intractability result DOES NOT hold on >these machines. First of all, a terminological point. Infallible detectability of viruses, the halting problem, equivalence of programs, truth in formal systems, etc. have been proved *UNDECIDABLE*, not "intractable". The term 'intractable' means something quite different. Informally, it means *computationally infeasible*, i.e. the problem is solvable, but the amount of time (or of space) required is too large to be practi- cal. A classic example of an intractable problem is factoring a very large number, say 200 digits long. This is possible, but apparently intractable because the currently fastest general-purpose algorithm (PPMPQS) on the fastest computer (Cray 3) would require hundreds of thousands of years. The formal definition used in computability theory, complexity theory, and modern cryptology goes something like this: For each solution there is a function giving the amount of time required for a given length of input. Then an intractable problem is defined as one for which there is no solution for which this function is bounded by a polynomial. (In particular, if the best solution is exponential, the problem is by definition intractable.) In this sense, factoring by an algorithm such as PPMPQS is intractable, independently of the size of the number and the computer used. Now to the main point: Cohen's theorem shows that whether a given program is a virus or not is undecidable. I.e., there cannot exist a procedure which inputs an arbitrary program or program segment and always correctly decides whether or not it is a virus, where a virus is a program which infects other programs (Cohen adds: "by modifying them to include a possibly evolved copy of itself", but the definition of 'infect' is not essential to the proof). The proof (which was obviously inspired by the well-known proof that whether a program halts is undecidable) is extremely simple: If there were such a decision procedure D, we could write a one-statement program P: If D(P) = non-virus then infect something. If D(P) = non-virus then P infects, so D is wrong. If D(P) = virus then P never does anything, so again D is wrong. Note, however, that the proof depends on the fact that a virus is defined, not as a program which *contains* viral code (and which is therefore only *potentially* a virus), but as a program which *actual- ly* infects other programs in some cases. Moreover, Cohen states that what has been shown by the above proof is that determination of a virus *by its appearance* is undecidable. (He claims that determina- tion by behavior is also undecidable, but he does not draw that con- clusion from the above proof alone.) But given these two assumptions, it is easy to see that the result is true even *without* resorting to Cohen's proof. For if P contains a statement of the form "If then infect" where is something that can be determined only at *run* time, then it is clear that D, by merely examining the *appearance* of P, cannot tell whether or not that condition is sometimes satisfied or never satisfied. Moreover, the proof *does not depend on the assumption of a Turing machine*. That leaves the possibility of D's decision being based on the *behavior* of P instead of on its appearance. I'm willing to suppose, purely for sake of argument, that in this case, the fact that an actual computer is not a Turing machine *might* allow the possibility of a correct decision procedure *in principle*. However, I'm sure that if such a solution exists, it would be *extremely impractical*. We agree that Cohen's result need not discourage us too much. How- ever, the reason is simply that a procedure which never has any Type- II errors and only very rarely gives a Type-I error is not ruled out by his theorem and would still be very useful. However, I do not agree with your main thesis that the distinction between a Turing machine and an actual computer is significant here. I think almost anything you can say about a Turing machine is also true of an actual computer if you add the phrase "for all practical purposes". Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Sun, 13 Oct 91 19:19:00 +0300 >From: Y. Radai Subject: Re: Hardware, hardware... Henk De Groot writes: > If you claim that a virus can not go >resident on your system than that implies that your system is clean. >If your system is clean you can not infect a floppy, protected or not! I am not going to get involved in the hardware issue per se; I only wish to take exception to the above statement of yours. Haven't you heard of the Vienna virus (with its 42 variants)? of DataCrime? of 1260 and the other V2P* viruses? These are *direct-action* viruses, i.e. they spread on execution *without going resident*. Even if you haven't heard of them, I think you should have taken into account the possibility of their existence before you started throwing around phrases such as "rediculus" and "this stupid converstion" [sic]. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Sun, 13 Oct 91 16:17:11 -0400 >From: Bhanu M. Kuchibhotla Subject: A new version of virus (PC) Hi folks, I recently heard from a friend of mine who says ther is new virus on the prowl which changes its signature fron time to time (frequency unk- nown). Is this true? If at all this is, then the all the virus detection software which rely on signature detection ( I guess all detection software do) will prove futile. I guess it would be very hard to detect such viruses. Any comments or discussion welcome. Bhanu MK ------------------------------ Date: Tue, 15 Oct 91 10:50:12 -0400 >From: Kenneth R. van Wyk Subject: Bontchev paper finally available in ASCII now Special thanks to Axel Gutmann for TeXing Vesselin Bontchev's paper, "The Bulgarian and Soviet Virus Factories," and sending me the .DOC file! The paper is now available in TeX, PostScript, and ASCII document formats on cert.sei.cmu.edu in the pub/virus-l/docs directory. Ken ------------------------------ Date: Fri, 11 Oct 91 18:23:16 -0700 >From: mcafee@netcom.com (McAfee Associates) Subject: Version 84 of McAfee anti-virus programs now available (PC) I have uploaded to SIMTEL20 and Garbo: pd1: SCANV84.ZIP Scans standalone and networked PC's for viruses CLEAN84.ZIP Virus removal program for PC's, LAN's VSHLD84.ZIP Infection-prevention TSR for PC's NETSCN84.ZIP Scans network file servers for viruses NEW RELEASE OF McAFEE ASSOCIATES SOFTWARE Version 84 of the VIRUSCAN, VSHIELD, CLEAN-UP, and NETSCAN programs has been released in order to detect a new virus that has been reported from Eastern Europe. The new virus, named DIR-2, is a stealth virus that uses a new way of infecting files that required this rewrite of the software in order for it to be 100% effective against it. The only other change to the software is that the VSHIELD program can now be loaded into high memory on systems running DOS 5. Beginning with this release we have compressed the software in order to save disk space and file transfer time. The validation information is as follows: CLEAN-UP V84 (CLEAN.EXE) S:68,283 D:10-04-91 M1: 35DE M2: 0AAC NETSCAN V84 (NETSCAN.EXE) S:50,345 D:10-07-91 M1: 04F9 M2: 1773 VIRUSCAN SCANV84 (SCAN.EXE) S:51,870 D:10-07-91 M1: 9008 M2: 03A7 VSHIELD VSHLD84 (VSHIELD.EXE) S:33,819 D:10-07-91 M1: EC7E M2: 0334 Aryeh Goretsky McAfee Associates Technical Support - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | aryehg@darkside.com(personal) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 190] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253