VIRUS-L Digest Tuesday, 9 Apr 1991 Volume 4 : Issue 56 Today's Topics: UNIX & Viruses (UNIX) Partitions without hidden sectors (PC) Mac virus question (relayed) (Mac) Am I subject to viruses? Re: F-PROT 1.13 vs. 1.14 Bug? (PC) Re: MDC questions How big is the virus problem ?? Re: F-DRIVER.SYS (v 1.14) problems & questions (PC) Re: Unix viruses and damaging programs (UNIX) Need help with Beijing Virus (PC) My final comments on the six-byte method (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: Wed, 03 Apr 91 13:34:30 -0500 >From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: UNIX & Viruses (UNIX) >From: micor!esleng!esleng.ocunix.on.ca!dag@uunet.UU.NET (Dave Gilmour) Basically, the sheer diversity of UNIX platforms provides the best defense against malicious software. Mix in the user/kernel and "rights" requirements and you have the basis for a good protection scheme. Mr. Morris's worm was directed at only two platforms: DEC Ultrix and Sun/OS as I recall and it had to carry separate code modules along for each. Viruses are remarkably sucessful on PCs, not because of the operating system, though DOS certainly does nothing to stop a virus, but because every machine from the lowliest 8088 to the mightiest 486 runs the basic 8086 instruction set at startup. Add in the fact that every function and every entry address defined in the 27 October, 1982 BIOS specification still exists and you have the key to the spread of malicious software. With UNIX on the other hand, not only is a certain amount of integrity checking built in to the O/S, but malicious software (and many users) have no idea if the architecture is based on an Intel 80386, a Motorola 680x0, the CVAX chipset, or some other RISC or CISC architecture. To the user, the biggest question is usually whether it is a C or Bourne shell. When we talk about "portability" in the UNIX world, we are usually referring to the fact that ASCII is ASCII and that source code that compiles on an Apollo can also compile on a VAX. That they use wildly different run-time-libraries is unimportant at the source-code level. In comparison, writing a virus that can attack both an IBM-PC and a MacIntosh would be simpler than one that could affect just the different varieties of Sun microsystems - no I am not picking on Sun, I just happen to have those manuals on hand. In addition, UNIX being a "real" multi-user operating system has had to layer in many integrity checks to protect users from each other. These same checks make it much more difficult to spread a virus without notice. I am not saying that it cannot be done, just that it would be first, difficult, and second, would have to be targetted to a particular platform or platforms. As yet, we have not seen any real threat to the UNIX platforms that cannot be countered with effective use of the tools built in. The biggest danger is still an "accident" by someone with root privilege and a managerial lack of proper training of system administrators. (off the soapbox, Padgett) ------------------------------ Date: Wed, 3 Apr 91 13:34:30 -0500 >From: Padgett Peterson Subject: Partitions without hidden sectors (PC) >From: con_jdc@selway.umt.edu (John-David Childs) >Subject: FDISK; partitions starting at 0,0,2; Stoned virus; (PC) >When used in conjunction with F-DRIVER.SYS at startup, I've had no trouble >with removing the virus. If F-DRIVER.SYS or some other detection utility >was not loaded at startup (F-DRIVER.SYS halts the PC if a virus is >detected), then Nick's and Padgett's comments about corrupted FAT's >etc. would be apropos. I would still recommend that people having disks formatted without "hidden" sectors whose machines are at risk, do a thorough backup and re-partition the disk using a version that does provide this added protection. The STONED is not the only virus that is liable to corrupt a FAT in this manner. An easy way to check is with DEBUG: load the logical boot sector of the fixed disk ( L 100 2 0 1 ) and the number of "hidden sectors" is contained in a double word at offset 11Ch (just the first byte is enough unless someone has more than 255 "hidden sectors" & that would surprise me). For an MFM drive, the value should be 11h or 17 "hidden sectors", I think an RLL drive will report 1Ah (26) and a large disk might report 3Fh (63), but if 0 or 1, I would expect that the FAT might be at risk. One of the difficulties of restoring a fixed disk infected with the MusicBug is that this "hidden sector" value is lost and must be restored (DOS SYS won't) before the disk will boot properly. Padgett ------------------------------ Date: Sat, 06 Apr 91 09:11:00 -0500 >From: LEAVITDG@snyplava.bitnet Subject: Mac virus question (relayed) (Mac) Date sent: 6-APR-1991 09:08:52 a friend of mine has asked a question regarding a mac virus. I do not use the mac and know very little about it. I will relay an answer if anyone has one. (my friend is on amateur packet radio, and does not have access to bitnet) --------original msg----------------------- >Date: 05 Apr 91 17:37:52 EST (Fri) >From: ka2bqe@ka2bqe.#nwvt.vt.usa.na (Brian Riley) >To: n2ixl@kd2aj.#nny.ny.usa.na >Subject: mac virus > >Daryll, had troubles with a Mac VIRUS over at Smuggs. Could you see if what >nfo you can find on BitNet on the mac Virus known as "nVIR B" . I have >removed it from 3 machines so far - it came to us apparently tucked into >a copy of STUFFIT whihc is kind of PKZIP for Mac's. I am not sure how >far it has spread on the mountain yet but want to get a handle on its >potential for trouble .. ie.e is itw orth panicking the place and cleaning >house or is it sufficiently harmelss that I can quietly take two weeks >going from machine to machine and clean it out. > tnx for any help you can get me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Darrell G. Leavitt SUNY Empire State College (ESC) ESC VAX: DLEAVITT 403 Sibley Hall SUNYNET: SESCVA::DLEAVITT Plattsburgh, New York, 12901 INTERNET: LEAVITDG@SPLAVA.CC.PLATTSBURGH.EDU PHONE : (518) 564-2837 AMATEUR BitNet : LEAVITDG@SNYPLAVA PACKET: N2IXL @ KD2AJ.NY.USA.NA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ Date: Sat, 06 Apr 91 07:42:41 >From: pcsbbs!fff@uunet.uu.net Subject: Am I subject to viruses? I know that this is the kind of question that only a novice would ask. Well, I am a *rank* novice in Usenet, UUCP, and telecommunications in general. Please bear with me. The question is: If I connect to a site where I always initiate the call, only exchange email and receive netnews, am I subject to receiving a virus. My modem is never left on and the port is not enabled for a login. If the answer to the above is yes, how can I protect my system. Any help would be greatly appreciated. Frank Fiamingo ------------------------------ Date: 07 Apr 91 13:45:46 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: F-PROT 1.13 vs. 1.14 Bug? (PC) rtravsky@CORRAL.UWyo.Edu (Richard W Travsky) writes: >I have an older version of the Jerusalem virus (2 years or so) I use >for testing. F-Prot version 1.13 detects and removes it, version >1.14a detects it but doesn't remove it, saying it's an unknown >variant. You are right, it is a bug in version 1.14 - It will not remove some of the Jerusalem variants, athough it detects and stops them all. This has been fixed in 1.15, which will pe distributed in just a few days. - -frisk ------------------------------ Date: Mon, 08 Apr 91 15:22:00 +0300 >From: Y. Radai Subject: Re: MDC questions In answer to some of Jim Kirkpatrick's questions: >-SNEFRU was discussed on this list, but I was dismayed to find it > had been broken, and that Merkle's response was to increase the > number of passes. Yes, 2-pass Snefru was broken, but I think only in the sense that it is computationally feasible to find *some* pairs x1, x2 (x1 != x2) such that Snefru(x1) = Snefru(x2). I'm not sure in what context this type of breaking is significant. It does not imply that for a *given* x it is feasible to find an x' != x such that Snefru(x') = Snefru(x) (unless one collects an enormous number of such pairs (x1,x2), which hardly seems practical). (Btw, 3-pass Snefru is also weaker than expected, but apparently not by enough to make it breakable in the way that 2-pass Snefru was broken.) > ....... Does the multi-pass version slow down the whole process > (or is it still acceptably quick)? Increasing the number of passes slows down Snefru considerably. Here are some relative times that I once obtained: MD4 7.9 Snefru, 2 passes 17.5 Snefru, 4 passes 27.7 Btw, the source code for Snefru which Merkle supplies does *not* give correct results on a PC (it ignores 0Dh bytes and halts on a 1Ah byte). This is because he neglected to perform his reads in binary mode. > Questions: How does one get MD4? Has anybody broken it yet or > even proposed a method? I have the source code for MD4 and could send it to you. As far as its being broken, I'm pretty sure it hasn't (unless someone is keeping the fact secret). Maybe that's because Rivest didn't offer a reward, as Merkle did :-) . More seriously, the structure of MD4 is quite different. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Mon, 08 Apr 91 14:20:38 +0100 >From: UMCKA04@VAXA.CC.IMPERIAL.AC.UK Subject: How big is the virus problem ?? After reading VIRUS-L for over a year now, I am still getting the impression that the true magnitude of the problem is unknown. This would seem to be especially so in the corporate domain, as I suspect many companies are reluctant to publicise details of their misfortunes fearing the poor publicity that is often associated with such releases (ie. Aldus recalling 5000 Freehand packages ...). Sales of anti-viral software may not be giving a true indication either, as the media 'hype' may be distorting the true scale of the problem. I am not suggesting that viruses are not a problem (I too have been hit :-), but I would be very interested in hearing peoples estimates of the SCALE of the problem, and reading any material that people may have regarding this. I would be happy to summarise and post to this board all the feedback that I get. Thanks very much, Alistair. ------------------------------ Date: 08 Apr 91 15:32:53 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: F-DRIVER.SYS (v 1.14) problems & questions (PC) nelson@bolyard.wpd.sgi.com (Nelson Bolyard) writes: >With F-DRIVER.SYS installed, there is a 24 second delay when I run a >TSR called PSFX. NO error message is displayed, and no warning sounds >are emitted from the speaker during this inexplicable 24 second delay. This is odd - F-DRIVER normally only adds a fraction of a second to the loading time of each program. I would very much appreciate a copy of the PSFX program, so I can determine what the problem is. >In truth, I don't know exactly what protection F-DRIVER.SYS supposedly >gives me, what types of problems it supposedly prevents, nor what I >should expect to experience (i.e. what F-DRIVER will do) if and when I >actually encounter a virus. The main purpose of F-DRIVER is to prevent the execution of any program virus on the computer. If you attempt to run an infected file, it will not be executed, and a message will appear. Example: This program is infected by the Magnitogorsk virus Access denied If this happens, just disinfect the affected file, or replace it with a non-infected copy. I try to keep F-DRIVER.SYS fully up do date, and it is able to stop around 400 virus variants. However, unlike F-FCHK, it will not produce an accurate variant identifiation. F-DRIVER will also attempt to analyze the system on boot-up, in order to determine if the machine is infected with a boot virus. If this is the case, it will display a warning message and hang the computer, forcing the user to reboot from a (hopefully non-infected) system floppy. I am adding an option in version 1.15 to disable the second feature, as it occasionally caused problems on computers with network Boot ROMs. - -frisk ------------------------------ Date: Mon, 08 Apr 91 01:44:00 -0700 >From: mrs@netcom.com (Morgan Schweers) Subject: Re: Unix viruses and damaging programs (UNIX) Greetings, A few words on "Unix" viruses... As far as I can tell they are not very likely. First off, the 'kernel' is *NOT* comparable to COMMAND.COM... The kernel is more comparable to IBMBIO.COM and IBMDOS.COM. The '?sh' programs are more comparable to COMMAND.COM. If you are to assume that 'root' has been breached, then you are in trouble already. If a person breaches 'root', they are much less likely to install a virus as install a trapdoor (patching login.c) or such. The reasons are manifold... A few reasons would be that 1) the executable file format is (as far as I know, anyone care to correct me?) not as available. 2) REAL security (as in, file-level access) is implemented in Unix. This means that non-prived person can't modify (usually) prived program . 3) Most viruses exist from the binary level, so far. This is difficult to 'spread' since many machines can be running Unix, but not be binary compatible. That generally explains why a virus won't spread too far. Now let me take the other side... I've seen (yes, SEEN) a 'worm' under Unix that can be very unfortunate. The example in particular that I saw involved the PATH statement of most people's .login's, and the fact that many people put '.' first in their PATH. Thus, say you 'cd' to a directory, and do an 'ls', and there is an 'ls' program in their directory... Well, you get the idea. It was substantially more complicated than that, but that's the basic idea. *THIS* (and silly other security precautions, like proper passwording (or shadowing, or any of the other miscellaneous topics)) is far more important to deal with than worrying about viruses under Unix. Under MS-DOS, it's not possible to close all the security holes without throwing out the OS and starting anew. Under Unix, the features are there and it's just a matter of implementing them. The same is true of most multi-user OS's. If it's made to provide seperation between users, then it's magnitudes harder to write a successful virus. One final note... I believe it has been done by one Fred Cohen, but I never learned the details of his experiment. However, the likelyhood of it spreading *OFFSITE* is virtually nil, which means your likelyhood of getting it is equivelant. I'm *NOT* a Unix guru, however. I'd *VERY MUCH* like people to correct me on matters of fact. -- Morgan Schweers P.S. It has been pointed out to me that it is possible to spread a BSI over a BBS if it's done on purpose. I apologize. Anything is possible if it's done on purpose. What I meant to say is getting a BSI off a BBS is far less likely than getting a file infector, and that's a pretty small chance anyway. +------------------ I don't speak for my company, since my company doesn't do Unix work. I do, and I love it, but I don't get paid for it, so there. -- mrs@netcom.com - ------------------+ ------------------------------ Date: Mon, 08 Apr 91 15:01:29 -0500 >From: EMERSON@TURING.SDC.TASC.COM Subject: Need help with Beijing Virus (PC) Help! I have a 286 12MHz IBM clone in my office that has been infected with the Beijing Virus. It has disabled my 3 1/2" floppy disk drive for me and is infecting any diskette I happen to boot with that is not write-protected. Our virus guru found that on the 128th boot of my PC, the message "Bloody! June 4th 1989" will show up and then every six times after that. This virus lives in the boot sector of my hard disk. Needless to say, I'd like to disinfect my hard disk without having to re-format it. I'd like to have a "tool" available to use for the next time this happens. Is there anyone who can tell me of a piece of software (and where to find it), or some method of getting rid of this? I have something that may work, but I need a SIGN.TXT file to run it with. Could I get a copy of this? Any help is greatly appreciated!!!!! Please send replies to: emerson@turing.sdc.tasc.com or Amanda Emerson, phone # (617)942-2000 Thanks! ------------------------------ Date: Wed, 03 Apr 91 21:00:54 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: My final comments on the six-byte method (PC) I know that many readers of comp.virus feel this discussion about the "six-byte method" in just a waste of time, and I apologize - but I still want to clarify a few issues. I don't mean this to be interpreted as a personal attack on Padgett Peterson, and I respect his work in the virus area in general, but I just happen to disagree with how he sometimes presents the "six-byte" check. Padgett Peterson wrote: While the "stealth" seen so far will defeat a program integrity check, it will NOT defeat a system integrity check (the six bytes). I replied: The six-byte check is no sustitute for a full system integrity check. Padgett Peterson then wrote: I did not think I ever said that it was. In fact in my New York paper specific mention was made that it did not detect the 512 (Number of the Beast). It will also not detect the Alabama, Icelandic, EDV, or any virus that does not go resident. What was said was that it will detect all currently "common" viruses. I was just replying to your earlier posting - and while I agree that the currently existing "stealth" viruses should not be able to evade a full system integrity check, we have at least one "stealth" virus which is able to evade the "six-byte" check. And regarding the claim that it will detect all currently "common" resident viruses, I must disagree - the Vienna virus and its 30+ variants are quite common, even though they are not as common as Jerusalem or "Stoned". Hovever, basically we agree. Checking the memory allocation (the six-byte check) before and after running a program will in most cases tell you if that program was infected with a virus. My point is just that "in most cases" is not good enough. Padgett Peterson wrote: An effective defense MUST start at the BIOS level, something that has nothing to do with the "six bytes". Such a program's major difficulty will be to handle every oddball O/S, partitioning scheme, and non-compliant application around. I more-or-less agree - with the latest viruses managing to bypass all interrupt monitors, and accessing the ROM BIOS functions directly, it is clear that 100% defence needs to be at least partially implemented in the BIOS itself. >I cannot go into details, but I do have a working program which is >able to do this - more details next month. Is this why the "insulting" of the "six bytes" ? I admit to being surprised that someone with your well-deserved reputation and many contributions would feel it necessary to harp on admitted flaws in something that is not a commercial product but merely a technique some people find useful. No, certainly not - I respect your work in the virus area, but I disagree with you presentation of the techique, like: "it will NOT defeat a system integrity check (the six bytes)" and "What was said was that it will detect all currently "common" viruses." As long as it is just presented as a simple check to detect if some program has allocated memory in a "standard" way, I have no objections to the "six-byte" check - primitive, but sometimes useful. - -frisk ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 56] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253