VIRUS-L Digest Monday, 12 Feb 1990 Volume 3 : Issue 37 Today's Topics: Appleshare Servers and WDEF Re: Are virus sources public domain software ? Re: WDEF and AppleShare (Mac) Universal virus detector / Biological analogy Which checksum algorithm? The Executable Bit Re: Disinfectant 1.6 (Mac) Re: More about WDEF (Mac) WDEF report from Detroit (Mac) Re: More about WDEF (Mac) Re: programmable virus scanner Re universal detectors. 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: Fri, 09 Feb 90 08:58:35 -0500 From: Joe McMahon Subject: Appleshare Servers and WDEF Hah! Another good defense for your hard disk. I believe there's an INIT available which adds the Appleshare desktop management code to your Mac (if I remember right, the "Oscar" program includes this). Install that on your hard disk in the System folder, blow away the old Desktop file with ResEdit/Disktop/et al, and there you are. As Brian puts it, there's nowhere for WDEF to live. Does Apple support using the Desktop Manager INIT on a non-Appleshare Mac? --- Joe M. ------------------------------ Date: 09 Feb 90 13:48:13 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Are virus sources public domain software ? ZDEE699@ELM.CC.KCL.AC.UK writes: >Well, how about some reliable organisation (the CERT, for example) >registering the source code under copyright laws ? There are numerous reasons why this would not work - the most simple one is that the original author holds the copyright, even if there is no "Copyright (c) 19xx, xxxxxxxxxx" message visible. - -- Fridrik Skulason - University of Iceland, Computing Services. frisk@rhi.hi.is Technical Editor, Virus Bulletin. ------------------------------ Date: Fri, 09 Feb 90 08:50:00 -0500 From: Peter W. Day Subject: Re: WDEF and AppleShare (Mac) Re the discussion of infection of AppleShare servers by WDEF and whether to run GateKeeper there, and Brian Bechtel's point that the server does not use its desktop file, so the disktop file can be removed, after which the server can not be infected by WDEF. Even if you leave the file "desktop" on the server, that file is not seen by clients (even using programs that can see the desktop file on local disks), so it appears that there is no way a client can infect an AppleShare server with WDEF. Clearly you could do so by putting an infected diskette in the server when it was running as a workstation (e.g. by booting it using an infected diskette). But could you infect the server by inserting an infected diskette in it while it was running as a server? Once infected, will the server infect local disks of clients? ------------------------------ Date: Fri, 09 Feb 90 16:08:24 +0000 From: "Dr. A. Wood" Subject: Universal virus detector / Biological analogy There has been much rhubarbiage about the possibility of writing a program which will detect viruses in incoming programs, not only a set list of viruses that it has been told about. I suspect that this is partly motivated by trying to achieve the efficiency of biological immune systems - there have been a few 'biological analogy' articles in Virus-L before. This analogy will not work - biological immune systems are set up in a different way. Long before birth, all possible antibody-producing cell types appear in the body. As in the womb before birth in the normal case, no foreign matter can get in, everything in the fetus is native and belongs. And, at that stage, every antibody-producing cell that loses its antibody, dies, for it must have lost its antibody by an auto-immume reaction. Thus all auto-immune antibody-producing cell lines are eliminated. Time passes and the baby is born. Then, any antibody-producing cell that loses its antibody must have lost it to some foreign matter. So it multiplies, and its descendants produce much antibody to combat the invader. After birth, nothing else gets unopposed into the body. The only way to imitate this in computers is to have an immune program which knows every program which will be run on that computer, and rejects all strange programs. No good! So, is there any point in this email-space-wasting discussion continuing? Bodies have a permitted list and exclude all others; computers have a forbidden list and admit all others. To a computer, a new virus is merely a new program, and some human has to find that it is harmful and then add it to the forbidden list. Also, any two bodies' cells (except identical twins) have different immunotypes, and attempted grafting fails, thus any bacterium that learns to masquerade as a legal cell of body A, is rejected on trying to invade body B. The computer analogy of this would be for each individual microcomputer's copy of each authorized program to be different. The only thing that I can suggest is for microcomputer designers to start using the mainframe technique of preventing programs running under ordinary mode from writing to system areas, and for only the suppliers of the computer to be allowed to write system programs which run under everything-permitted mode. That will exclude damaging viruses, but will still allow the sort of virus that merely multiplies and wastes time and storage space. {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Fri, 09 Feb 90 15:38:12 GMT ------------------------------ Date: Fri, 09 Feb 90 11:54:00 -0500 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Which checksum algorithm? >To make the question a little more specific, of the checksum routines >available today, which would you select. This is slightly a less, rather than more, specific question. Your original question suggested that strength would be the basis of my choice. In fact, crypto theory teaches that knowledge of strength is very expensive. I would prefer to make my selection based upon knowledge that comes a little cheaper. The answer will be influenced by application and environment. However, in general: If I were an employee of the U. S. Government, I would choose the DES. It is available and the authorities have told me that it is strong enough for their purposes. In other cases, I would choose from among CRC, DES, and RSA. We know their strength with sufficient confidence, it is sufficient for most applications, and they are available. In the absence of more knowledge about the application and environment, deeper analysis is not warranted. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Fri, 09 Feb 90 12:26:00 -0500 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: The Executable Bit The data object marked with an "executable bit" that Jerry L. and Dave Chess are discussing is an example of a "strongly typed data object." A "typed" data object is one upon which only a limited set of operations are valid. A "strongly typed" object is one in which the rules for the type are known to and enforced by the environment. In this case, for environment, you may substitute hardware. The IBM AS400, with which people in Yorktown, if not Poughkeepsie, should be familiar, implements such strongly typed objects. In this system it is not normal for something to be both executable and modifiable at one and the same time. As a rule, programs can never be modified. They can be replaced, but not changed. That is to say, the name of a program is unique; if you replace it, it automatically receives a new unique name. This meets Jerry's requirements, if not his objectives. While changes to programs will be hard to conceal, for reasons of useability, progams are invoked by their short names. A person might have to note the change for protection to result. And of course, it might be possible to create a new environment on top of the one provided by the system, and not visible to it, which would execute modifiable objects. A REXX interpreter of Hypercard interpreter, for example, could be so implemented. However, in response to Dave's question about whether such objects would "get the bit", it is also possible to do it the other way. Scripts for the AS400 command language (named CLs in the Poughkeepsie style) are typed objects. I hope that REXX scripts, for that SAA interpreter, when it becomse available for AS400, will be typed objects. (Will Rochester prevail over Poughkeepsie; will fair Harvard conquer Princeton at last; or has von Neumann vanquished Aiken forever? Watch this space.) William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Fri, 09 Feb 90 14:28:00 -0600 From: John Norstad Subject: Re: Disinfectant 1.6 (Mac) LAU@ricevm1.rice.edu(Fung P Lau) writes: > I have recently read something about Disinfectant 1.6 from this > newsgroup. Its author said that there was no Disinfectant 1.6 and it > maigt cause potential porblems on virus detection. Someone in our lab > downloaded it and has been using it without any obvious trouble. I > would appreciate any further comments on this application. So, again, > is there any upgraded version of Disinfectant after version 1.5 ? If > not, is there any more information about this "fake" Disinfectant ? Disinfectant 1.6 is a bonafide new release. There was some confusion on the UseNet newgroup comp.sys.mac before 1.6 came out about a possibly "bogus" version 1.6, but nothing ever came of that confusion. Version 1.6 contains important new generic nVIR clone detection and repair code. All Disinfectant users should upgrade to the new version. (I am the author of Disinfectant) John Norstad Northwestern University jln@acns.nwu.edu ------------------------------ Date: Fri, 09 Feb 90 14:37:16 -0600 From: John Norstad Subject: Re: More about WDEF (Mac) wcpl_ltd@uhura.cc.rochester.edu (Wing Leung) writes: > Can someone tell me is WDEF an illegal string in the resource code? > How about the program called WDEF uploaded in comp.binaries.mac? > In fact, I've found some WDEF resource code in system version 6.0.3. > Please tell me more about this resource code. WDEF resources are a normal part of the Mac operating system. You should only be concerned if you find a WDEF resource in a Finder Desktop file. John Norstad Northwestern University jln@acns.nwu.edu ------------------------------ Date: Fri, 09 Feb 90 16:13:30 -0500 From: "Dennis P. Moynihan" Subject: WDEF report from Detroit (Mac) Yup, Wayne State in Detroit got hit about Feb 3. The embarrasing thing is that we found it on one of the Computing Center's servers (where all our anti-viral people work) and on, um, my machine. Sigh. We're putting a notice out to the rest of the campus and we'll see if the hills are alive with WDEFs.... - -------------------------------------- Dennis Moynihan (DMOYNIHA@WAYNEST1) Computing and Information Technology Wayne State University Detroit, MI ------------------------------ Date: 09 Feb 90 18:38:40 +0000 From: "David N. Schlesinger" Subject: Re: More about WDEF (Mac) wcpl_ltd@uhura.cc.rochester.edu (Wing Leung) writes: > I've found some WDEF resource code in system version 6.0.3. Please tell me > more about this resource code. WDEF is, in fact, the signature of a standard resource type: the "W"indow "DEF"inition porcedure resource. The WDEF _virus_ is distinguished by being a resource of type WDEF in the invisible file "Desktop" in the root directory of a volume. Hope this helps... Lefty =========================================================================== David N. Schlesinger || "There's a word for it: words don't The Wollongong Group || mean a thing. There's a name for it; Internet: Lefty@twg.com || names make all the difference in the POTS: 415/962-7219 || world..." -- David Byrne =========================================================================== ------------------------------ Date: Fri, 09 Feb 90 14:42:18 +0000 From: "David.J.Ferbrache" Subject: Re: programmable virus scanner Yes, the idea is an excellent one. The concept of a programmable virus recognition system has already been adopted on the Mac, specifically in release 3.0 and later of Jeff Shulman's virus detective package. This desk accessory uses an abstract definition language for the detection of viruses by resource patterns or code signatures. Jeff's patterns allow quite complex expressions and sub expressions tied with the cand operator (&). The product can test for the creator and type of any file; the resource type, name and size; and a code string to be searched which can be offset by a fixed value from the start or beginning of the resource. Jeff allows wildcarding in a limited form to occur in his search strings. This takes the form of a skip over non-significant bytes, thus the search string "3C#500" would match 3C, skip 5 bytes and then match 00. Thus matching the string 3C12C9006A800. This adaptability has proved virus detective to be one of the most useful anti-virus utilities on the Mac. Thus a new virus (such as the WDEF strain) can be reported along with a virus detective identification string which can be rapidly added by the user to his virus detective copy. Finally virus detective incorporates generic detection patterns for most Mac viruses, thus eliminating the problem caused by the regiment of nVIR virus clones (most of which are produced by a simple binary or resource edit of the infected file). Obviously the general virus detection system may be less efficient than the alternative specialist detection software, however the use of precise offsets may cause significant improvements in pattern scanning. Other extensions could include test expressions for the file alteration date and length information in the directory (catching the 648 seconds signature and the Oropax rounded file size signature); and extended wildcard matching to deal with the 1260 decryptor scrambling routine. (With a possible syntax allowing ?X to match up four random characters before a further match, we could have ?20B8#4?20B9#4?20BF#4?20310D?203105?2047?2040?20E2 this rather complex pattern would allow for up to 32 random bytes to be inserted between each significant byte in the 1260 decryptor string and would also skip the variable values in the MOV instructions. Naturally as the form of the expression becomes more complex (ending in full regular expressions with exponential search time and memory requirements) search times will increase. In summary the requirements for filter expressions are: 1. Directory entry filters - file length (including modular value test, eg MOD 51), file alteration date, attribute settings and file extensions 2. File characteristic filters - possibly including the destination of the initial jump instruction, definitely including a form of code scanning using wildcarded expressions (either in a specified scan range or at a number of scan ranges based on offset from the start and end of the file). Naturally such a virus detector could be extended to allow scan of memory or of a range of disk sectors, thus allowing one program to deal with application, boot sector and partition record viruses. (In a similar manner to the way norton utilities allows for a variety of data sources - sector, file, cluster etc). Anyway just a few thoughts. ------------------------------ Date: Fri, 09 Feb 90 23:39:54 -0400 From: GEORGE SVETLICHNY Subject: Re universal detectors. Enough has been said on this list to convince most people that a universal virus detector (UVD) is impossible, and I've given my own two cent's worth in favor of this position. If by "virus" we mean to include a whole range of "nasty" programs, then one also runs into problems of correctness of code and bugs, and gets tangled up in questions of human intent, which makes the discussion, though still mathematically viable, (given sufficient abstraction) rather trivial in the end. The answer is that no UVD exists. Even defining viruses as some types (not all) of "self-duplicating codes" and leaving trojans and other nasties aside will not improve the situation much, as one still faces quite general undecidability theorems. As I have tried to point out, almost any question about a program's performance is undecidable. In Virus-L v3, issue20 russ@Alliant.COM (Russell McFatter) argues that one should not try to determine what a program *will* do but what it *might* do and just not run those that might infect others. In principle this sounds like a good idea, since a-priori such a rephrasing of the problem could make it decidable. What makes it totally unviable is the present hardware (at least on PC-type machines, I'm not that familiar with Macs) as I tried to point out in Virus-L v3 issue22. Now there just _*MAY*_ (note the triple enphasis) be a theorem of the following type: I. Given such-and-such memory and microprocessor architecture, then any program containing a virus (however that is defined) will necessarily have a certain patern P in the object code. II. Any program that does not contain a virus can be written in a way that does not lead to pattern P in the object code. This would not conflict with the undecidability theorem since the presence of pattern P is not a UUV as having the pattern does not mean that the program *is* a virus, only that it *might be*. And part II allows any honest program to be written and not be dubbed dangerous. I'm actually mixing mathematics and technology in the above. The purely mathematical conjecture would be (having defined "virus" in some appropriate useful way): There is a decidable set W such that 1) all programs containing viruses are in W and 2) all programs that do not contain viruses *have an equivalent* (identical input-output behaviour) that is not in W. Program equivalence is undecidable so this does not contradict the undecidability of virus detection. The technological part would consiuAof expressing W in some convenient way through hardware architecture. Is this plausible? Frankly, it doesn't sound so to me, but I wouldn't discard it off hand. It's the only hope I see of some general mathematical result being useful for anti-viral strategies, so maybe we should look at it more closely. ---------------------------------------------------------------------- George Svetlichny | When it is not your mother who is Department of Mathematics | in danger of being eaten by a Pontificia Universidade Catolica | wild animal, the matter can wait Rio de Janeiro, Brasil | until the morrow. | usergsve@lncc.bitnet Fido 4:4/998 | Baganda Proverb ---------------------------------------------------------------------- ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253