Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA09854; Mon, 1 Jun 92 23:27:16 +0200 Message-Id: <9206012127.AA09854@abacus.HGS.SE> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9848; Mon, 01 Jun 92 17:11:09 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 3351; Mon, 01 Jun 92 17:10:50 EDT Date: Mon, 1 Jun 1992 17:07:17 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List Comments: Warning -- original Sender: tag was krvw@CERT.ORG From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #112 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Monday, 1 Jun 1992 Volume 5 : Issue 112 Today's Topics: Hurricane season is upon us... Re: Integrity Master AV product (PC) Starship (PC) re: help me .. is this a virus? (PC) re; Virus or hard disk problems ? (PC) Joshi hit! (PC) Re: clock ram resident virus (PC) re: Question about Dark Avenger (PC) Troi Two (PC) How effective can TSR scanners be vs new viruses? (PC) VD virus (PC) Re: Question about Dark Avenger (PC) OS2 Viruses (OS/2) how to evolve General: Anti-Virus packages Virus informational databases re: re:Clarifications-1 ISPNews and why 100% is the only good enoug solution Polymorphic question NETSCAN version 91-B released (PC) new McAfee programs (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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Mon, 01 Jun 92 09:56:19 -0400 From: Kenneth R. van Wyk Subject: Hurricane season is upon us... Today is officially the first day of hurricane season down in the Gulf of Mexico (located to the south of the eastern portion of the United States). It seems only befitting then, that the delivery of VIRUS-L (and hence comp.virus) would start its own storm this past weekend. I put together two digests (#110 and #111) on Saturday and sent them out within just a couple of minutes of each other. 110 was delivered just once, and 111 was delivered several times - to everyone on the list. In addition to everyone receiving 5-6 copies of the digest, I received all of the normal administrative bounced mail (which averages about 20 bounces per digest, I'd estimate) in quintuplicate. Then, around Sunday afternoon, the "disk quota exceeded" bounces started coming in... I _think_ that I have found the offending address and removed it from the list. At least it wasn't as bad as the last storm of 2000+ bounced messages. :-\ Apologies to all those who had to read through the multiple digests, especially those of you on commercial services that charge for connect time. Thanks to all who pointed out this problem to me and sent me debugging info! It was all useful in trying to figure out the cause of the problem, and I appreciate your help. I'm sorry that I can't reply to all of the messages. Cheers, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.ORG (work) ken@THANG.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ Date: 30 May 92 16:49:20 -0400 From: Wolfgang Stiller <72571.3352@CompuServe.COM> Subject: Re: Integrity Master AV product (PC) > bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes in > response to TYETISER@ssw02.ab.umd.edu (Tarkan Yetiser) : > > latest release, maybe they rectified this deficiency. If you want to > > maximize compatibility at the cost of less security, Integrity Master > > is a better choice at a fraction of the cost. Similar flaws, but > > better implemented, not as sharp-looking. Just my personal opinion. > IM is good indeed, but it doesn't have "similar flaws" with UT. It is > less secure. I would like very much to see it aware of the same kind > of attacks that UT is. Then it will be a really serious competitor of > UT, especially considering the major drawback of the latter - its high > price. The issues you've mentioned above plus the other issues which we've discussed privately are now all addressed in working versions of Integrity Master and will be available to the public within the next 60 days. I'm running into some compatibility and ease of use concerns which I hope to have ironed out shortly. For those newly lisening in on this conversation, I'd like to point out that we're discussing two techniques not yet utilized by existing viruses. Regards, Wolfgang Wolfgang Stiller Stiller Research 2625 Ridgeway St. Tallahassee, FL 32310 U.S.A. ------------------------------ Date: Sun, 31 May 92 12:57:29 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Starship (PC) >From: MIG@politon.msk.su (Igor G. Muttik) >Subject: Article about "Starship" virus available (PC) > - when infecting MBR virus changes only three > bytes in partition table Just as a point of interest, SafeMBR (part of FixMBR & one of the FixUtils) checks these three bytes on load and did so considerably before STARSHIP was known. Once you understand what a PC can and cannot do, integrity management is possible and requirements are predictable (particularly from the BIOS level). Warmly, Padgett ------------------------------ Date: Sun, 31 May 92 23:26:00 +0100 From: Anthony Naggs Subject: re: help me .. is this a virus? (PC) Wendell Gee, (jjz34245@uxa.cso.uiuc.edu), says: > I boot up the machine and it appears to run fine through the boot up > until I type in a command and hit return. It doesnt matter what the > command is. Every time it does this: > > B: > A: > A:cd\ > A:win > > and then it runs windows. While windows is booting up, a long bell > that never used to be there is sounding. Windows is pretty useless > after that. The buttons do not work right, and nothing Sounds like someone has tampered with your AUTOEXEC.BAT, probably using ANSI codes to reprogram your [return] key. First I should reassure you, there is less than 1% chance that this is caused by a virus. From your description I assume that you are starting your PC from a floppy disk, my advice is to follow these steps: 1 If there is another working PC that you can use then start that up, otherwise find an alternate boot disk for your PC preferably the DOS disk that came with the machine. 2 DISKCOPY your problem disk, to give a disk that you can freely alter in the following tests. 3 Use a wordprocessor or text editor to look at the CONFIG.SYS file on your startup disk, (eg EDLIN A:CONFIG.SYS). Look for a line like "DEVICE=ANSI.SYS", this installs the ANSI.SYS program that allows your keyboard to be remapped. Type REM and a space in front of the line, save the changed file (in text or ASCII mode if you are using a word processor). 4 Look for any lines with "[" (open square bracket) characters in, particularly if they start with ECHO and also say "win" or "nw" in. This line is almost certainly causing your problem, place a "REM " in front of the line. 5 Put "REM " in front of any lines beginning "ECHO OFF" or "@ECHO OFF" & "CLS" or "@CLS". This will allow you to see each line of AUTOEXEC.BAT as it is executed. Save your new file. 6 Restart your PC with the altered disk, note that you may get an error "Unrecognized command in CONFIG.SYS" depending in your DOS version. This is because older versions of DOS do not recognise REM's in the CONFIG.SYS file, however it will have done the primary job of preventing ANSI.SYS from being installed. Look for any command in AUTOEXEC.BAT that prints '<-' (left arrow characters) and '[', these indicate an ANSI screen control sequence. Their most common use is in changing screen colours & allowing some programs to move the screen cursor - but they can also be used when trying to change your keyboard operation. Use ctrl-S, or [Srcoll Lock] to pause and restart AUTOEXEC.BAT, so that you can see what is happening. 7 Try typing a command, if it works then the problem is indeed due to reprogramming your keyboard - you should be able to use the information from steps 4 & 6 to decide which lines are causing the problem. You will also need to discover who altered your disk! 8 If you still have a problem then mail me more details. Hope this helps you out, Anthony Naggs PS If Jimmy Kuo (cjkuo%ccmail.norton.com@norton.norton.com) is reading this, I have tried mailing a reply to you (20 times!) but for every variation on your address my message bounces back. Please write again. Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) - -- What a lovely day to walk up behind your boss and shout "DON'T PANIC!" -- ------------------------------ Date: Mon, 01 Jun 92 00:18:00 +0100 From: Anthony Naggs Subject: re; Virus or hard disk problems ? (PC) Andy Ravenna, (unx.sas.com!sasaer@mcnc.org) tells us: > Last night my whole system seemed to go on the fritz... I booted off > of a clean floppy and started to investigate things. > > First I ran "Qaplus" which came with my Gateway, and the DMA testing > on the Main Components menu seemed to freeze up. Does this mean the > DMA chip has gone bad ? Sounds likely, though if it is hot there your system maybe suffering from heat stress - try retesting in the morning cool. Otherwise you can take the system back to your dealer for a checkup, or take a peek under the cover yourself. Check all socketed chips are firmly installed (on PCs & ATs the DMA chip has 40 pins and has the part number 8237A), check the ribbon cable going to your hard drive, and if the PSU is accessible check for any obvious damage to electrolytic capacitors (small Al cans) - blackening indicates they have burnt, white goo indicates that the electrolyte has failed. > Secondly, I ran Norton Disk Doctor II and when Norton got to the last > 55% of my 80 meg hard drive, it started marking every sector as "BAD". This could be consistant with a DMA fault, sort that out before retesting your drive - I would suggest using ONTRACK's disk diagnostics rather than NDD to provide reliable hard drive testing. > Is it possible to have a "partial" disk crash ? Disk drives usually fail completely, or suffer from head crashes where vibration causes one head (or more) to touch the disk surface. At 3000 rpm even a short touch can cover most of a track, damaging that area of the disk. Often flakes from the disk impact, or occasionally damage to the head, will lead to further damage of the disk. > HELP ! Does this sound like a virus problem or a hardware problem ? >From the information given it seems far more likely to be hardware. Hope this is of some assistance, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: 29 May 92 20:56:31 +0000 From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) Subject: Joshi hit! (PC) For those keeping statistics ... Acer America Corporation got hit by JOSHI this week. As near as I can tell, it only spread to two machines (out of hundreds) before being caught. Fortunately, the second machine was protected by Padgett's SafeMBR program and so we caught it quickly. (Thanks, Padgett.) Sadly, event this is unlikely to influence the Powers That Be to have a real anti-virus plan here. Jesse Chisholm | Disclaimer: My opinions are rarely understood, let | tel: 1-408-432-6200 | alone held, by this company. jesse@gumby.altos.com | fax: 1-408-434-0273 |----------------------------- ======== This company has officially disavowed all knowledge of my opinions. - -- | "I write of things that I have neither seen myself, nor heard from another, | things which are not, never were and never could be. My readers should | by no means believe them." -- Lucian of Samosata ------------------------------ Date: 29 May 92 20:44:34 +0000 From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) Subject: Re: clock ram resident virus (PC) amjad@ecst.csuchico.edu (A.J.) writes: : hello, : does anybody know of any clock resident viruses for either : Amiga, Mac or PC computers ??? if so what viruses are they ... I think : my amiga is infectedwith one ... please send more information on these : type of viruses and procedures on removing them ... thankx ps. please : give names and complete discriptions of the viruses you know of and : how to remove them. (amiga,mac or pc) that infect the clock cmos ?? : - -aj. None. There is no code in the clock CMOS to be infected. There is data of varying amounts on different systems in the clock CMOS. Some programs garbage the clock CMOS data. For instance, don't try to load an OS/2 mouse driver in an MS-DOS system. Last time I tried that (accidently) the CMOS thought I had set a password. I couldn't boot until I had disconnected the CMOS battery and drained it. Jesse Chisholm | Disclaimer: My opinions are rarely understood, let | tel: 1-408-432-6200 | alone held, by this company. jesse@gumby.altos.com | fax: 1-408-434-0273 |----------------------------- ======== This company has officially disavowed all knowledge of my opinions. - -- | "I write of things that I have neither seen myself, nor heard from another, | things which are not, never were and never could be. My readers should | by no means believe them." -- Lucian of Samosata ------------------------------ Date: Mon, 01 Jun 92 01:04:00 +0100 From: Anthony Naggs Subject: re: Question about Dark Avenger (PC) Previously I said: > R. Bondi (BONDIR@vaxb.gbus.virginia.edu) said: > [stuff deleted] > > ... What I > > don't understand is this: surely the executable, self-extracting part > > of the program must be invariable - it can't be encrypted, because > > obviously it couldn't execute while encrypted. So why aren't such > > viruses easy to detect simply by scanning for the self-decrypting > > executable portion? > > [stuff deleted] > > Viruses using the MtE are of a class known as polymorphic, where > the self-decrypting portion DOES change. The magnitude of change varies, > but MtE is extreme as it randomly generates new encryption/decryption > variations. ... R. Bondi recently replied: > This is what I don't understand. How can it vary? It does the same job > every time it runs: it decrypts. It may use a different decryption key > each time, but then it should just run through the same steps with a > different encryption key. But if it does the same job every time, how can > its code possible vary? I can imagine a human writing many completely > different source codes that all accomplish exactly the same task, but not > a program that can produce many completely different programs that all do > the same thing. Polymorphic viruses include a thesaurus, allowing different combinations of operations to be produced. Instead of copying the existing decryption routine the virus uses internal tables to select the functions used. Often the decryption is self inverting, allowing the new routine to serve the complementary purpose encrypting the new generation. > The response from the UK to my original question here seemed to imply > that "filler" is added between the segments of code that do the work, i.e. > segments of dummy code that vary every time. But then the actual code still > stays the same, and can be scanned for. Similarly the virus can insert "err..s" & "um..s" in the generated code from a data table. I hope you are now convinced that the actual code can vary, however scanning can still be done - but not with simple search strings. A more complicated (sophisticated when I do it!) approach is required that knows what possible decryptors can be generated by the virus and ignores the "err..s" & "um..s" As I said before: > ... Both the MtE and the decryption routines generated have > a large amount obfuscation included, it is thus difficult to calculate > how many variations MtE can produce or to accurately determine what they > might all look like. The problem with this b****r is the difficulty in determining what all the possible decryptors will look like. Hence Vesselin Bontchev reports: + The three scanners were run on those virus samples. ...[stuff deleted]... + + All the three scanners failed the test, each in a different way. + + FindVirus showed the worst results. It did not detect 744 virus + samples (7.86 %). F-Prot did not detect 13 examples (0.14 %). SCAN did + not detect 4 examples (0.04 %). SCAN shows the best detection rate in + the case of MtE, but we also got a report for one false positive. If the code stayed the same, or was easily predictable, then 100% detection would already be acheived with these products. > In short: how are polymorphic viruses possible? I just don't understand!! If you still want to know more I would be happy to discuss this in private email, but I don't wish to give too much tuition in writing polymorphic viruses in this public forum. Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Mon, 01 Jun 92 01:21:23 +0000 From: u910826@bruny.cc.utas.edu.au ( nomoloS siuoL) Subject: Troi Two (PC) A brief note note expanding on what was said by Brian Marriott about the Troi Two virus. It only infects EXE files, and when it hangs, it is accidental. (ie it is not supposed to hang or crash the computer, at least I can't find anything in the code which appears to be for anything other than spreading). Louis u901826@bruny.cc.utas.edu.au ------------------------------ Date: Sun, 31 May 92 11:56:06 -0700 From: pain.uucp!curtiss@markv.com, pain!curtiss@hermix.markv.com (Curtis Shenton) Subject: How effective can TSR scanners be vs new viruses? (PC) I've seen several TSR programs lately that claim that they will detect and viruses on your system even if they are new viruses. Now I understand that many viruses use the same methods but how reliable is this claim? Most new viruses that aren't just reworks of an old virus won't be caught will they? - -- pain!curtiss@markv.com, usc.edu!celia!techsys!pain!curtiss ------------------------------ Date: 27 May 92 07:15:00 +0000 From: michael.blackwell@f820.n680.z3.fido.zeta.org.au (Michael Blackwell) Subject: VD virus (PC) Has anyone heard of a virus called VD, scan string [FD] ? Scan90 picked it up the other day. Scan89, virex (april ver), and Norten Anti Virus report nothing. Niether does the docs for scan, or the april Vsum. Any info would be greatly appreciated. Thanks, Michael - --- * Origin: Coffee Au Go-Go. We don't know what it means either. (3:680/820) ------------------------------ Date: 01 Jun 92 16:14:09 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Question about Dark Avenger (PC) BONDIR@vaxb.gbus.virginia.edu writes: > >It's true that this part cannot be encrypted, but it is not true that > >it must be invariable. In fact, it varies very heavily - it is very > >different with each new infected file. > This is what I don't understand. How can it vary? It does the same job You need a detailed guide how to create polymorphic viruses?... :-)) OK, that was a joke. Here is the main idea. Suppose that in order to decrypt the virus, the decrytion routine must do the following: mov si,offset_of_encryted_part mov cx,length_of_encrypted_part mov bx,decryption_key again: xor word ptr [si],bx loop again Looks pretty obvious, doesn't it? Well, first a virus could generate the first three instructions in a random order - this will not change the algorithm. If the decryption procedure is less trivial than the one I described, other parts of it could be swapped too. This is essentially what the V2Px viruses do. Another idea is to use random registers - DI instead of SI; AX instead of BX, and so on. This is what the Phoenix viruses do. A third idea is to use alternate opcodes for one and the same instruction. For instance, both the 0C1h and 0C3h opcodes mean XOR ,. This is what the Starship virus does. At last, the Mutating Engine generates whole expressions: for instance, if you want to put 5 in SI, you could use MOV SI,5 but also MOV AX,10; MOV BL,2; IDIV BL; MOV SI,AX... > every time it runs: it decrypts. It may use a different decryption key > each time, but then it should just run through the same steps with a > different encryption key. It is indeed very difficult to change the algorithm. But one and the same decryption algorithm can be expressed in a number of ways and this is exactly what the polymorphic viruses do. > But if it does the same job every time, how can > its code possible vary? The algorithm doesn't vary; its implementation does; see above. > I can imagine a human writing many completely > different source codes that all accomplish exactly the same task, but not > a program that can produce many completely different programs that all do > the same thing. A signifficant part of what you think that only a human can do can be achieved by a computer too... This is mainly due to the fact that the 8088 instruction set is quite orthogonal. > The response from the UK to my original question here seemed to imply > that "filler" is added between the segments of code that do the work, i.e. Ah, yes, this is yet another idea. If used alone, it does not help a lot, since the scanners can use wildcard strings. But many polymorphic viruses are using it together with other ideas. > segments of dummy code that vary every time. But then the actual code still > stays the same, and can be scanned for. Every virus can be scanned for, even the most polymorphic ones. The trick is that they cannot be scanned for using a simple (or even wildcarded) scan string - a special algorithmic approach must be devised for each one of them. This is a quite time- and effor-consuming procedure... > In short: how are polymorphic viruses possible? I just don't understand!! I hope that you have got the main idea. It is necessarily simplified - in reality the polymorphic algorithms are more sophisticated. But the exact details cannot be discussed publicly for obvious reasons. Regards, Vesselin Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sun, 31 May 92 09:36:00 -0400 From: fc Subject: OS2 Viruses (OS/2) OS2 viruses: ASP is soon going to release the ASP Protection Toolkit, which is a version of the Integrity Toolkit for OS2. OS2 hase some very nice advantages over DOS protection, in that the operating system actually protects itself from arbitrary modification by user processes!!! The access control package from IT will work far better under OS2, and the protection from modifying executables will no longer be bypassed by direct IO to the disk. In short, OS2 makes sound techniques far more effective and removes all of the painful restrictions of DOS (e.g. fitting the resident protection intto under 3K, etc.) Unfortunately for the scanner people, OS2 will not run DOS type scanners on OS2 files with long filenames, but on the good side, very few poor people (i.e. virus writers tend not to be rich) can afford a system that will run OS2 (neither can I, but I'm borrowing one). It takes 8M of RAM, and about 120M of hard disk to even bring up a good OS/2 development system (some people tell me 16M makes it work a lot better, but for real performance, get 1M for every 512K of programs you run, and it will only page 33% of the time). So in our testing, the following viruses run under OS2: Partition table infectors work, but if they use memory, they get mangled by OS2 pretty fast. Boot block infectors and DIR viruses only work on FAT file systems. File infectors work Resident viruses that don't trace into INT13 usually work (a lot of them barely work under DOS at all). Viruses that require more than 8086 CPUs don't work. Stealth viruses aren't very stealthy, since OS2 is not bypassed, only DOS IO is forged. As to futures: OS2 makes it harder (nearly impossible) to write really strong viruses against integrity checking techniques EXCEPT as device drivers. The net effect is that access control in OS2 provides very strong defense (assuming it implements a POset). Low level viruses have to be OS2 customized to survive the OS2 memory mangement process. Evolutionary file infectors will continue to be a problem except for those with integrity shells. higher level viruses, such as spreadsheet viruses will operate unchanged. A batch file virus written in 1985, still runs under OS2, as does a "C" virus written in 1983 and a Basic virus written in 1984. Conclusions - OS2 helps, but we're not out of the woods yet. FC ------------------------------ Date: Sun, 31 May 92 09:18:00 -0400 From: fc Subject: how to evolve In the addendum to my short course book, several types of evolution are shown. It turns out pretty ueasy to make detection of evolved programs NP-complete (or even exponential in same cases). Here's a simple example: a, b, ...., x, y, z Original program ja,r,js,f,jg,a,jb,...,j,jk Evolved program, where j* is a jump to the location of instruction *. How about another? j=j+14 k=j+120-(58*2);j=k; Another? a; b; c; d; is replaced by: a; call bb; c; call dd; dd: d return bb: b return Mix and match for mutations of mutations - call recursively for many more variations on the theme. For more details, read short course book (2nd release), or an upcoming paper in C+S (assuming they accept it) on program evolution. FC ------------------------------ Date: Mon, 01 Jun 92 05:26:01 +0000 From: ins894r@aurora.cc.monash.edu.au (Aaron Wigley) Subject: General: Anti-Virus packages I have established a small selection of anti-virus software for multiple operating systems (pc, mac, etc.) in an anonymous ftp site to cater for students on campus that do not have full internet/usenet access. What I would like to know is the most suitable packages for any platform to make available to the students. The software will need to be either public domain or shareware. If you can think of any other applications that will be of benifit, please do not hesitate to advise me. BTW: The ftp site is yoyo.cc.monash.edu.au Aaron Wigley Email: ftp@yoyo.cc.monash.edu.au wigs@yoyo.cc.monash.edu.au ------------------------------ Date: Sun, 31 May 92 12:31:32 -0700 From: Julian Leong Subject: Virus informational databases During the last 6-8 months that I've been reading the VIRUS-L group I've noticed that no one has given a favorable review to any of the virus databases -- particularly Patricia Hoffman's VSUM. Has any effort been made to make any of the databases better? To me such a database would be an invaluable tool for the average computer user that believes a virus has his computer under siege. I vaguely remember the different tid-bits of advice that get posted which instructs one to use product W to purge your machine of virus X but under no circumstances should one use product Z's disinfection program -- (Vesselin mentioned that SCAN is good for finding viruses but he recommended F-PROT as a disinfectant in some cases.) Furthermore, I don't believe the FAQ covers such minute details which could be easily implemented in a virus database. I've never used VSUM or any other database (sorry -- other names elude me at this point) because I've been fortunate enough to have never encountered a virus. I am aware that the FAQ mentions several sources of information but they also exercise a hefty toll on one's pocketbook. I realize that many may be hard-pressed for spare to devote to such a project, but doesn't it seem worthwhile? Julian Leong UC Berkeley ------------------------------ Date: 30 May 92 20:37:04 -0400 From: "Tarkan Yetiser" Subject: re: re:Clarifications-1 Hello, From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes > Subject: Re: Clarifications... (PC) > begins to become non-interesting to the general public, I strongly > suggest to my opponent to switch to private e-mail.) Agreed. But please do not consider me an opponent. I only intended to exchange ideas to clarify a few things. If I seemed to be too attached to VDS emotionally, chalk that up for a common human failing :-)) >>> By "special" I meant that I was not able to find even -one- computer >>> here in our VTC, on which the package would run without problems... I >> Whoah! What do you guys use up there? Next machine? Or all hard drives >> are compressed? We had little trouble at this part of the planet :-)) > We are using all kinds of machines. PS/halfs, '386s, a few clones... > (This is the MS-DOS department, the Amiga, Atari ST, Mac, and Unix > people have the appropriate machines.) The DOSes are PC, MS, DR, > Toshiba. Versions vary from 2.11 to 6.0. Some disks are Stackered, > others are SuperStored (not all). Most machines (not all) are > networked with Novell NetWare... Your program (out of the box) > couldn't be used on any of the machines (as is), but I could combine > the existing hardware/software in order to have a computer on which it I see. I will drop this issue, then. But I must say that if VTC stands for Virus Test Center (??), and you guys do not have a "standard" DOS 3.0+ based plain PC to do virus testing, it is a bit surprising. >> though we recommend it. The other day, one of our associates (advocate of >> Win30) showed me the books on the shelves of a local book store's computers >> section. Almost 1/3 was Windows stuff! It's catching on fast. I still > No, it just means that the wannabe Windows users must learn a lot... :-)) Well, that must be it; considering they did not notice the performance degradation Windows causes :-)) How do you make a 12-MHz-AT out of a 33-Mhz screamer 486 box? >>> It's good that it refuses to run when non-installed; I don't object to >>> that. However, it -does- try to run in the case I described and fails >> Hmm. It should've displayed a message and then aborted, not hung up. > Why aborted? The docs say that the scanner part -does- run uninstalled > (and it should be so, of course, or how else are you going to scan > before installation?). Not necessarily. Scanning is implicit during installation, not external. Have you really had a chance to run VDS at all :-)) > is not a device driver... Well, how about the idea to put the > information that is saved during the installation in an external data > file (encrypted and with a file name selectable by the user during the > installation process)? Then you mention in the documentation that this > data file must not be moved across the machines and explain exactly > why. Gives much more assurance to the user that s/he knows what's > happening, instead of just scaring him/her... Yes, we added more explanation. BTW, keeping info in an external file will not really solve the problem either. People will copy it over as well. It seems that the need for user-awareness is unavoidable. No wonder Padgett is replacing peoples' MBRs :-)) Makes me nervous, though. >> If only the partition table is modified but not the >> code, it will warn that it was not properly installed on that system. > Nice! The program that is available here which I mentioned above, does > not have this feature... (It also does not work under DR-DOS 6.0. > Unfortunately, this is not my program and I don't have access to the > sources, so I cannot fix it.) In VDS 2.10, we modified the integrity checker component to see if the device driver placed a captured MBR-creep. Then it renames the file as well as scanning it and making an entry in the log. The log feature is expanded since many people very much appreciate to have a trace of such things. Now there may be up to 10 MBR or BR viruses captured and stored in a file by the device driver. They used to get overwritten. >> course, this will miss an indirect BSI that only modifies the active >> partitions entry. > It will also miss a StarShip-like MBR infector (will just say that it > needs re-installation), but this is non-essential, since as you say Now, we do a byte-by-byte (more exactly word-by-word :-)) comparison of the partition table and display a warning message. Catches Starship-method infections easily. Of course, user-awareness will be necessary, since we avoid automatic recovery in such a case. >> VDS.EXE is a little smarter. It actually tries to determine if the >> partition sector matches the disk layout as indicated in the backup copy >> of the MBR. If not, it does NOT attempt to recover, to avoid such damage, >> and only posts a warning message. > Very nice, as I said... Now why not explaining it in the docs? Sounds > much better if I know what the program is doing and under which > conditions exactly it might cause damage, instead of "if moved to > another computer it might cause damage in some cases"... I know. If one uses documentation space to make a marketing point, important stuff like this gets left out :-)) >> I disagree. The documentation tries to promote a sensible approach to >> anti-viral security. It does not overemphasize the problem, not does it >> underestimate it. > Read what I said again. I reproche it the claims to "bypass any > stealth virus" and be "the strongest anti-virus product". I could post > here what's wrong in the whole documentation, but it will be a too > long message, if I include the appropriate quotes. I'll see to it that words such as "all" and "any" will be replaced with "most possible" or "many we have seen". Would be more realistic. >> Your example of people switching to VAXes because they had a bad >> experience with a PC virus was not realistic. > But an example of a PC infected only once in the beginning of the > 2-year period by a well-known virus isn't... Okay. Someone suggested adding another question about if they started using an anti-viral program after the incident, and if the answer is YES, then give back some points. Makes sense. > First, I made a silly typing mistake, as I often do. My paragraph that > you quoted should read "It does not have to describe....". Second, II > insist that it is fair to mention in the docs that not all possible > stealth viruses can be stopped by the technique that you are using and > that it is still safer to use the program after ensuring that there's > no virus in the memory (i.e., after booting from a clean floppy). This we should handle via private e-mail, since we need to discuss some techniques that might give some people ideas that may be dangerous. It is always safer that way, but not that necessary since the infection will not spread as it may with some other implementations. >> the time. Cohen has a funny suggestion in his Bootstrapping paper about >> snapshot of memory state saved on a write-protected floppy. Theoretical >> it may be feasible, but in practice it won't work well. If it is not us > It is not only theoretically feasable. It is also implemented in his > ASP Integrity Toolkit. True, it can be bypassed by a direct attack, > but he clearly states this in the beginning of the paper that you are > mentioning, right? Okay. Let me first provide the reference in case others may want to take a look at it: title: A Note On High-Integrity PC Bootstrapping author: Fredrick B. Cohen pub. : Computers & Security, 10 (1991) 535-539 Yes, it makes the stipulation that it is (second technique) is effective as long as it is a non-directed attack. My criticism was that it assumes that drivers are unchanged between snapshots. This is not flexible enough. He also suggests saving the snapshot on a floppy and then using it. Not a usable implementation if you ask me. >> what good is it? Kind of like discretionary access control :-) > Exactly! And how many of us will object to have in MS-DOS the kind of > discretionary access control that Unix provides? True, it won't stop > the viruses entirely, as Cohen has proved, but it would be a much > better to have than the current situation, don't you think so? Yes. Maybe someday, PC OS developers will design their kernel with virus-awareness. Until then, the PCs will remain very vulnerable. OS/2 will not help much, since it is not designed with virus-awareness in mind. The file system is still fair game. Just what viruses need :-)) Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: Sat, 30 May 92 09:57:00 -0400 From: fc Subject: ISPNews and why 100% is the only good enoug solution If you read ISPNews this month, the article with my name on it is not even close to the article I submitted - so if you are following my writings, throw that one out. Now to the real subject: If you only get 99% of the instances of a mutating virus, what will happen to your system? Try this scenario I have 500 EXE files, MtE gets 500, scanner catches+cleans 495. Next morning, I have 5 old MtE viruses and 495 new ones, scanner catches 490... After a few weeks, every file is infected, and scanner detects no infections!!! I can just hear it now - "The infection was pretty bad - At first all of the files were infected, but after a few weeks of cleaning the systems every day, we completely eliminated the virus. Gee, what's that ping pong ball on the screen?" FC ------------------------------ Date: Mon, 01 Jun 92 12:39:49 -0400 From: Brian Seborg Subject: Polymorphic question BONDIR@vaxb.gbus.virginia.edu writes: >From: BONDIR@vaxb.gbus.virginia.edu Subject: Re: Question about Dark Avenger (PC) >> don't understand is this: surely the executable, self-extracting part >> of the program must be invariable - it can't be encrypted, because >> obviously it couldn't execute while encrypted. So why aren't such >It's true that this part cannot be encrypted, but it is not true that >it must be invariable. In fact, it varies very heavily - it is very >different with each new infected file. >This is what I don't understand. How can it vary? In your posting you go on to explain how the encryption algorithm can vary by adding random do nothing instructions, so I am somewhat confused as to why you think it can't vary since you seem to have answered your own question. Anyway, let me attempt a response to what must by now be a candidate for the FAQ. As many people are aware, encryption has been used by viruses for some time. Encryption has been used to hide text strings which might otherwise give away the nature of the code, and it has also been used to cause each infection of the virus to appear different such that a scan string would be difficult to extract which would catch all varients of a particular virus. The trick is that for the virus to decrypt, it must have at least a portion of the virus code (the portion which will decrypt the rest of the virus) in a form which is interpretable by the CPU (it must be in plaintext). There- fore, scanners would often key on the plaintext portion of these viruses for their scan strings. This works most of the time, except when the decryption algorithm is too short for a decent scan string, but there are ways around this as can be seen by the fact that today's scanners catch all known viruses some of which have this problem. The next trick virus writers decided to pull was to vary this decryption algorithm so that to scan for it one would have to scan for 1000 or more variations (take 3 necessary instructions, add 10 junk instructions, mix well). Mark Washburn demonstrated this technique in his viruses to prove a point. Viruses which do this are known as polymorphic since they actually change in some random (though predictable) way each time. The new polymorphic engine simply refines this capability such that the number of combinations is very large. You are right that you can scan for this code, but look at the practicality of it. Is it practical to scan for all 1000 or more variations of a virus? Probably not. It makes the scanners slower, and may, in the long run be a death knell for scanners as they are used today. Integrity checkers, and shells hold more promise for the future, although not perfect either. You can see that by filtering certain instructions, McAfee, etc. have been able to detect viruses which incorporate the polymorphic engine, but look at the cost in performance. Compare Scan V86 and Scan V91 for example. There is no doubt that scanners will always be a necessary component of any virus fighters arsenal, but if the Bulgarians create a few more flavors on the polymorphic engine, we are going to be forced to use other methods to protect ourselves. Hopefully, this answers the question. If not, feel free to e-mail me personally. :-) Sincerely, Brian Seborg ------------------------------ Date: Mon, 01 Jun 92 11:20:06 -0700 From: mcafee@netcom.com (McAfee Associates) Subject: NETSCAN version 91-B released (PC) I have uploaded to SIMTEL20 PD1: I have uploaded to GARBO pc/incoming I have uploaded to CERT.ORG incoming I have uploaded to RISC pub/00uploads NETSC91B.ZIP NETSCAN 91-B network server virus scanner NETSCAN VERSION 91-B RELEASED Version 91-B of NETSCAN has been released. This release replaces This release replaces Version 91 which gave a false alarm of the V3 [F3] virus on the CHK123.EXE file from Lotus. VALIDATE VALUES FOR VERSION 91-B: NETSCAN 91B (NETSCAN.EXE) S:75,118 D:05-28-92 M1: CC02 M2: 17FD Aryeh Goretsky McAfee Associates Technical Support ------------------------------ Date: Fri, 29 May 92 20:47:00 -0400 From: HAYES@urvax.urich.edu Subject: new McAfee programs (PC) Hi. Just received and made available the following updates for McAfee's files: CLEAN91.ZIP;1 NETSCN91.ZIP;1 SCANV91.ZIP;1 VSHLD91.ZIP;1 - --- Site: urvax.urich.edu, [141.166.1.6] (VAX/VMS using Multinet) Directory: [anonymous.msdos.antivirus] FTP to urvax.urich.edu with username anonymous and your email address as password. You are in the [anonymous] directory when you connect. cd msdos.antivirus, and remember to use binary mode for the zip files. - --- Best, 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 5 Issue 112] ******************************************