home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 718.VIRUSL6.090 < prev    next >
Text File  |  1993-06-02  |  23KB  |  499 lines

  1. VIRUS-L Digest   Thursday,  3 Jun 1993    Volume 6 : Issue 90
  2.  
  3. Today's Topics:
  4.  
  5. Re: IDES '93 Conference Proceedings
  6. Looking for SCO UNIX virus software (UNIX)
  7. Corrections (CPAV) (PC)
  8. Re: CPAV updates? (PC)
  9. What to do about Quox virus? (PC)
  10. Misidentification by F-Prot 2.08a (PC)
  11. Re: On the merits of VSUM (PC)
  12. Re: Bug With Virstop 2.08a & DOS6 Memmaker? (PC)
  13. Re: The Anti-Viral Software of MS-DOS 6 (PC)
  14. Re: Gotta Monkey on My Back!!! (PC)
  15. New scanner -- Looking for code (PC)
  16. Anyone have something like this? (PC)
  17. Redirection Difficulty (PC)
  18.  
  19. VIRUS-L is a moderated, digested mail forum for discussing computer
  20. virus issues; comp.virus is a gatewayed and non-digested USENET
  21. counterpart.  Discussions are not limited to any one hardware/software
  22. platform - diversity is welcomed.  Contributions should be relevant,
  23. concise, polite, etc.  (The complete set of posting guidelines is
  24. available by FTP on cert.org or upon request.)  Please sign submissions
  25. with your real name; anonymous postings will not be accepted.
  26. Information on accessing anti-virus, documentation, and back-issue
  27. archives is distributed periodically on the list.  A FAQ (Frequently
  28. Asked Questions) document and all of the back-issues are available by
  29. anonymous FTP on CERT.org (192.88.209.5).
  30.  
  31. Administrative mail (e.g., comments, suggestions, beer recipes)
  32. should be sent to me at: krvw@AGARNE.IMS.DISA.MIL.
  33.  
  34. All submissions should be sent to: VIRUS-L@Lehigh.edu.
  35.  
  36.    Ken van Wyk
  37.  
  38. ----------------------------------------------------------------------
  39.  
  40. Date:    Tue, 01 Jun 93 15:04:44 -0400
  41. >From:    faigin@aero.org (Daniel P. Faigin)
  42. Subject: Re: IDES '93 Conference Proceedings
  43.  
  44. On 27 May 93 18:06:35 GMT, jmr@philabs.philips.com (Joanne Mannarino) said:
  45. > I wrote a letter of complaint to the organization and also sent copies to
  46. > IEEE and ACM which were supposedly sponsors.
  47.  
  48. Well, you've now heard from at least one of them. Based on the reports from
  49. conference attendees and the response from the conference organizers to the
  50. reported problems, ACM/SIGSAC has withdrawn its "In Cooperation With"
  51. sponsorship from the Computer Security and Virus Conference.
  52.  
  53. Daniel Faigin
  54. Chair, ACM/SIGSAC
  55. - --
  56. [W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
  57. [Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
  58.             "And as they say, the rest is compost"
  59.  
  60. ------------------------------
  61.  
  62. Date:    Tue, 01 Jun 93 09:50:23 -0400
  63. >From:    tijc02!djm408@uunet.UU.NET (David Marks)
  64. Subject: Looking for SCO UNIX virus software (UNIX)
  65.  
  66. I am looking for any virus checking software for SCO UNIX, SCO ODT. If you
  67. know of any that runs under that please email me. If I get responses, I will
  68. summarize to the net.
  69.  
  70. Thanks in advance.
  71.  
  72. - -----------------------------------------------------------------------------
  73. David J. Marks                       |     UUCP:      ...!uunet!tijc02!djm408
  74. Siemens Industrial Automation, Inc.  | Internet:   djm408%tijc02@uunet.uu.net
  75. P.O. Drawer 1255                     |    Phone:                 615-461-2074
  76. Johnson City, TN 37605-1255          |
  77. - -----------------------------------------------------------------------------
  78.  
  79. ------------------------------
  80.  
  81. Date:    Tue, 01 Jun 93 10:26:14 -0400
  82. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  83. Subject: Corrections (CPAV) (PC)
  84.  
  85. >In the referenced article, bontchev@rzsun2.informatik.uni-hamburg.de
  86. >(Vesselin Bontchev) writes:
  87.  
  88. >>According to Padgett, the updates can be used to upgrade also the
  89. >>MS-DOS version of MSAV - the scanner that comes with MS-DOS 6.0.
  90.  
  91. Not quite, the signature update for the DOS portion appears identical
  92. (according to FC). The .DLLs (Windows portion) are the same exact size but 
  93. are different - probably just logos/messages but haven't checked further.
  94.  
  95. >From:    bontchev@news.informatik.uni-hamburg.de (Vesselin Bontchev)
  96.  
  97. I wrote:
  98.  
  99. >> As far as the easy disable in memory as documented widely, a tiny TSR
  100. >> (uses no free RAM) could disable the disabler just as easily.
  101.  
  102. >Nope. The disabler -is- needed - as Yisrael pointed out, MSAV needs to
  103. >turn VSAFE off before it begins to scan the disk. If you don't allow
  104. >disabling of VSAFE, then you won't be able to run MSAV with VSAFE in
  105. >memory. A quick fix is to make the TSR ask the user whether s/he
  106. >really wants VSAFE to be disabled, but this is, after all, a kludge.
  107.  
  108. Exactly so though do not know why this should be necessary, all MSAV should
  109. be doing is reading the disk (or will VSAFE decide that MSAV is a virus 8*).
  110. I have quite a few resident programs that do not bother any A-V products
  111. (though I have thought that some should...)
  112.  
  113. >> Finally, given that the signatures are distributed separately, what is to
  114. >> stop an enterprising person from distributing their own signature update
  115. >> for use with MSAV having a much higher detection rate (for a suitable fee 
  116. >> of course) ?
  117.  
  118. >I am not competent in legal matters, but I think that one must obtain
  119. >a permission from Central Point Software and/or from Microsoft, before
  120. >publishing such an update... 
  121.  
  122. Why ? Though I am equally incompetant legally it would seem that CP might 
  123. copyright their signatures (and this is questionable, they would have to 
  124. prove originality of the strings), what you have is a program that accepts
  125. input. There are no legal restrictions to that input any more than Microsoft
  126. can limit sales of Wallpaper .BMPs or Lotus can limit 1-2-3 templates. What 
  127. we are dealing with is a *format* not a program and insofar as I have been 
  128. able to ascertain the courts have taken a consistantly dim view on attempts 
  129. to restrict these. 
  130.  
  131. >Besides, the format of the updates is not published. 
  132.  
  133. SBO doesn't work for long.
  134.  
  135.                 Warmly,
  136.                     Padgett
  137.  
  138. Have the a/c compressor mounted in the Judge and about 1/3 of the stucco
  139. off. Might get to do some programming RSN.
  140.  
  141. ------------------------------
  142.  
  143. Date:    Mon, 31 May 93 19:07:39 -0600
  144. >From:    marcs@alive.ersys.edmonton.ab.ca (Marc Slemko)
  145. Subject: Re: CPAV updates? (PC)
  146.  
  147. bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  148.  
  149. > According to Padgett, the updates can be used to upgrade also the
  150. > MS-DOS version of MSAV - the scanner that comes with MS-DOS 6.0.
  151.  
  152. The DOS updates can indeed be used with the DOS version of MSAV.  One
  153. simply has to rename the virsigs.cps file to virsigs.ms.  Other than the
  154. included instruction file (copy file to program directory...) the files
  155. are identical in the MSAV and CPAV DOS updates.  Now... the Windows
  156. version... the DLLs and sig files seem completely different.  Maybe
  157. someone who uses DOS 6 should try renaming and plugging the CPAV Win
  158. update files into MSAV Win...
  159.  
  160. - -- 
  161. ===========================================================================
  162.         Marc Slemko        | marcs@alive.ersys.edmonton.ab.ca
  163. Edmonton, Alberta, Canada  |
  164. ===========================================================================
  165.  
  166. ------------------------------
  167.  
  168. Date:    Tue, 01 Jun 93 19:25:23 +0000
  169. >From:    Eriq Oliver Neale <neale@unt.edu>
  170. Subject: What to do about Quox virus? (PC)
  171.  
  172. I just now ran across a diskette infected with the "Quox" virus
  173. (according to F-Prot), yet F-Prot cannot remove it, nor does it
  174. have any information about it. I looked in the backlog of messages
  175. on VIRUS-L and could find no recent mention of it. 
  176.  
  177. I'm curious what its particular effects are, bugs, etc. Any sources
  178. of information to be had?
  179.  
  180. Please respond via e-mail, even though I'll be watching the group
  181. closely for responses....
  182.  
  183. - -Q
  184.  
  185.  Eriq O. Neale                              BITNET : LIPS@UNTVAX
  186.  Lab/Network Manager                      Internet : neale@acs.unt.edu
  187.  Academic Computing Services                   FAX : (817) 565-4060
  188.  University of North Texas                 Ma Bell : (817) 565-2324
  189. "If I got paid for what I say, I'd either be very rich or very quiet!"
  190.  
  191. ------------------------------
  192.  
  193. Date:    Tue, 01 Jun 93 22:56:35 -0400
  194. >From:    "System Manager, and VAX Gopher" <farnold@wotan.duch.udel.edu>
  195. Subject: Misidentification by F-Prot 2.08a (PC)
  196.  
  197. Greetings.
  198.  
  199. Our lab just survived our first viral infection.  Symptoms were that any 
  200. executable program residing on the hard-drive would refuse to execute, and
  201. the machine would lock up, following booting.  F-Prot 2.08a identified the 
  202. virus as a _Screaming Fist_ variant, while McAfee's Scan program said that
  203. it was a combination of a boot sector virus, [Genp], with the _Stickey_
  204. [ML2] virus infecting the .com and .exe files.
  205.  
  206. One other characteristic of the virus was that it wasn't terribly bright, 
  207. in that one of the .com files that it infected was a DCL .COM file downloaded
  208. from my VAX. (for the vaxophobic, it's an ascii text file, similar to a .bat).
  209.  
  210. I was able to disinfect the [Genp] with complete success using Clean, and 
  211. [ML2] with partial success.  Files that were for protected mode applications 
  212. tended to be unrecoverable.  F-prot was unable to do either.
  213.  
  214. Being as we've relied on periodic scanning with F-Prot here at the
  215. university as the primary means of virus detection, how often does
  216. this happen (misidentification, or identifying two viruses as a
  217. third)?  Secondly, does anybody have any further information on the
  218. viruses that the program detected?  We have a lot of data move through
  219. our computers, and would like to avoid losing any more to this type
  220. of incident.
  221.  
  222. Thank you for your time.
  223.  
  224.                         -fred
  225.  
  226. ------------------------------
  227.  
  228. Date:    Wed, 02 Jun 93 00:05:11 -0400
  229. >From:    Al Garcia <CMGARCIAAL@CRF.CUIS.EDU>
  230. Subject: Re: On the merits of VSUM (PC)
  231.  
  232. You recently gave some very constructive criticism of Patricia Hoffman's VSUM.
  233. In contrast, McAfee's VIRLIST.TXT provides succinct descriptions of the general
  234. behavior you can expect from any particular virus on it.  One of these types of
  235. behavior is installing in memory, but that's as much detail as it gives on the
  236. matter (again, it's succinct).  As you know, there are many different ways a
  237. virus can install itelf in memory, which is reflected in VSUM.  Here's her 
  238. legend - this is from a rather old version, but I wouldn't be surprised if she
  239. still uses the same classification system:
  240.  
  241.         R = Resident (in memory)
  242.           (below 640k - segment A000)
  243.               a - in unused portion of allocated memory
  244.                   (does not change free memory, such as virus resident
  245.                   in CLI stack space or unused system memory)
  246.                   Example:   Lehigh
  247.               f - in free (user) memory below TOM
  248.                   (does not prevent overwriting)
  249.                   Example:   Icelandic
  250.               h - in high memory but below TOM
  251.                   (Resides in high system memory, right below TOM.
  252.                   Memory is allocated so it won't be accidently
  253.                   overwritten.)
  254.                   Example:   Flash
  255.               s - in low (system/TSR) memory
  256.                   (reduces free memory, typically uses a normal
  257.                   Int 21/Int 28 TSR)
  258.                   Example:   Jerusalem
  259.               t - above TOM but below 640k (moves Int 12 return)
  260.                   (Reduces total memory size and free memory)
  261.                   Example:   Pakistani Brain
  262.           (above 640k)
  263.               b - in BIOS/Video/Shadow RAM area (segment A000 - FFFF)
  264.               e - in extended/expanded memory (above 1 Meg)
  265.  
  266. Could you please provide some comments on the accuracy of VSUM in this one 
  267. specific area of analysis?  The reason I think this is helpful is that it 
  268. gives you an idea of what viruses can install in memory without being detected
  269. by programs such as TBDRIVER/FILE, FLUSHOT, SECURE, etc.  For example, the
  270. first two each have a problem detecting suspicious memory allocation and use,
  271. which might allow viruses such as, according to her example, Flash, to slip
  272. past them.  SECURE, on the other hand, doesn't seem to bother alerting the
  273. user when a program makes a TSR request (maybe it's supposed to, but it didn't
  274. in the time that I tinkered with it), which might allow simple viruses, such
  275. as, again by her classification, Jerusalem, to install without any questions.
  276. But obviously, her analysis is of no help at all if it's wrong.  I don't know.
  277. I don't have the viruses to verify any of this.  I only ran a few tests on the
  278. security programs to see if they'd be triggered under the conditions I would 
  279. want them to be, above scenarios included.  Thanks.
  280.  
  281. - -Phil Garcia
  282.  
  283. ------------------------------
  284.  
  285. Date:    Tue, 01 Jun 93 21:49:46 +0000
  286. >From:    jdc@selway.umt.edu (John-David Childs)
  287. Subject: Re: Bug With Virstop 2.08a & DOS6 Memmaker? (PC)
  288.  
  289. medici@dorm.rutgers.edu (Mark Medici) writes:
  290. >sphughes@sfsuvax1.sfsu.edu (Shaun P. Hughes) writes:
  291. >
  292. >I have had experiences similar to Rich's.  If I allow DOS6's MemMaker
  293. >to try and determine the best way to load VIRSTOP from F-PROT 2.08a,
  294. >the system locks hard requiring cold-boot.  However, if I select the
  295. >custom MemMaker option, tell MemMaker that I want to specify which
  296. >files to try and load high, and exclude VIRSTOP, there is no problem.
  297. >
  298. >Note that VIRSTOP is actually loaded into memory, it's just that I
  299. >don't let MemMaker try to fit it high.  After MemMaker is done, I have
  300. >no trouble loading VIRSTOP into UMB (providing enough space is left
  301. >over for it).
  302. >
  303. >So the problem seems only to be that MemMaker's method of determining
  304. >VIRSTOP's size is not working -- not that VIRSTOP is incompatible with
  305. >DOS6's UMB/EMM386.EXE.
  306.  
  307. VIRSTOP normally takes up 15K.  VIRSTOP /DISK uses 2K.  Could it be that
  308. VIRSTOP /DISK *initially* needs 15K and then shrinks down to 2K, but MEMMAKER
  309. puts it into the wrong region of upper memory based upon the 2K assumption?
  310. I know of many TSR's that "shrink" once their initialization code is complete.
  311.  
  312. According to the DOS 6 manual, MEMMAKER does not try to figure out the optimal
  313. ORDER of program loading in config.sys/autoexec.bat (I think QEMM does). 
  314. The ordering of programs can be crucial for the very reason mentioned
  315. above (program shrinking).  For instance, if VIRSTOP /DISK is loaded from
  316. autoexec.bat there may not be enough upper memory to complete the task
  317. (you may have 8K of upper memory but you need 15K for the
  318. initialization even though the program only takes up 2K in the end!).  If
  319. VIRSTOP is loaded as one of the first programs from CONFIG.SYS (after
  320. DOS=HIGH,UMB of course) then you'll have plenty of room for VIRSTOP and
  321. (possibly) 12-13K of programs you may not have been able to run otherwise
  322. (15-2=13).  On our DOS6 machine (DEC 386-25,2 meg RAM, 80meg SCSI) MEMMAKER
  323. couldn't  squeeze out any further upper-memory than my "hand-optimization"
  324. (I have 2K left) and VIRSTOP was left as-is (no crash after running memmaker).
  325.  
  326. I would guess that since no-one has complained about QEMM crashing VIRSTOP,
  327. the fault lies with MEMMAKER (surprise surprise surprise - Gomer Pyle). But
  328. whether MEMMAKER can or can't determine VIRSTOP's size or whether the problem
  329. is because MEMMAKER doesn't re-order the loading of programs is a
  330. different question.  I haven't played with QEMM sufficiently enough to know.
  331.  
  332. - -- 
  333.                           John-David Childs
  334.                           Consultant, University of Montana CIS
  335.                           UM Student Health Service HEALTHLINE Gopher Admin
  336.                           jdc@selway.umt.edu, con_jdc@lewis.umt.edu
  337.  
  338. ------------------------------
  339.  
  340. Date:    Wed, 02 Jun 93 07:28:27 -0400
  341. >From:    Y. Radai <RADAI@vms.huji.ac.il>
  342. Subject: Re: The Anti-Viral Software of MS-DOS 6 (PC)
  343.  
  344.   Concerning the messages which F-PROT outputs about finding search
  345. patterns in memory, I had written:
  346. >> I therefore think that the problem lies with F-PROT rather than
  347. >> with MSAV or VSafe in this particular case.
  348.  
  349. Vesselin replies:
  350. > I beg to disagree. Although I have not observed it myself, I have
  351. > received several reports about interaction with SCAN 104 and ghost
  352. > positives. It seems indeed to depend on where exactly is VSAFE loaded
  353. > in memory. And the cause of the problem is, of course, VSAFE and
  354. > nothing else - because it doesn't bother to encrypt its scan strings.
  355.  
  356. The experimental facts which I have found are this:  Without VSafe
  357. loaded in memory either currently or since booting, I run first MSAV,
  358. then F-PROT.  F-PROT outputs the message "The Telecom virus search
  359. pattern has been found in memory."  Now how can VSAFE be the problem
  360. when *it isn't even loaded in memory*???
  361.  
  362.   What is clear is that in this case F-PROT is complaining about what
  363. *MSAV* has left in memory, not about VSAFE.  It is also clear that
  364. F-PROT is giving a false positive.  The only question is: Which scan-
  365. ner is at fault: MSAV or F-PROT?  If instead of running F-PROT (after
  366. MSAV) I run SCAN, FINDVIRU, or UTSCAN, no message is output.  Since
  367. the other three scanners disagree with F-PROT, the most likely answer
  368. is that it is F-PROT which is at fault in this case.
  369.   Admittedly, the situation changes when VSAFE is loaded in extended
  370. memory (in this case F-PROT complains that the Stoned pattern has been
  371. found).  This time it may sound as if VSAFE is guilty.  But here
  372. again, the other three scanners say nothing.  So I tend to think that
  373. it is F-PROT which is at fault in the present case too.
  374.  
  375.                                      Y. Radai
  376.                                      Hebrew Univ. of Jerusalem, Israel
  377.                                      RADAI@HUJIVMS.BITNET
  378.                                      RADAI@VMS.HUJI.AC.IL
  379.  
  380. ------------------------------
  381.  
  382. Date:    Wed, 02 Jun 93 16:32:33 +0000
  383. >From:    thompson@hg.uleth.ca (Mark Thompson)
  384. Subject: Re: Gotta Monkey on My Back!!! (PC)
  385.  
  386. cxf12@po.CWRU.Edu (Christopher Fenton) writes:
  387. >
  388. >    Has anyone dealt with the "Monkey" virus before???? It 
  389. >has taken up residence in the boot sector of several of my machine
  390. >and I'm trying to establish an appropriate cure, but I can't find
  391. >any referances to it in the literature.
  392. >
  393. >    Any help would be greatly apreciated.  Pertinent e-mail
  394. >is always welcome.
  395.  
  396. Tim Martin from the university of Alberta has written a program to
  397. deal specifically with monkey.  It can be found via anonymous FTP at
  398.  
  399. oak.oakland.edu in the subdirectory
  400. pub/msdos/virus by the name
  401. killmonk.zip
  402.  
  403. I have used it on several machines, and it works just fine.
  404.  
  405. Ciao fer now,
  406.  
  407. Mark.
  408. Mark Thompson          |                          |
  409. Faculty of Management      |    640K ought to be enough for anybody!   |
  410. University of Lethbridge  |            Bill Gates, 1981      |
  411. Lethbridge, Alberta      |                          |
  412. Canada              |                          |
  413. - ----------------------------------------------------------------------
  414.  
  415. ------------------------------
  416.  
  417. Date:    Thu, 03 Jun 93 05:08:12 +0000
  418. >From:    tlangan@cwis.unomaha.edu (Todd C. Langan)
  419. Subject: New scanner -- Looking for code (PC)
  420.  
  421. I am currently in the prossess of writing a virus scan specifically
  422. for the especially built network we are using here at work.  I have
  423. found that my work is much easier if I have the actual uncompiled
  424. virus code to work with.  If _ANYONE_ has _ANY_ virus code it would be
  425. much appreciated if you would send it to me at my email address
  426. (tlangan@cwis.unomaha.edu) or if anyone would happen to know of any
  427. ftp sites where I could view the code.
  428.  
  429. Please help me if you can.
  430. Thanks in advance!
  431. Todd Langan
  432.  
  433. - -- 
  434.           ______       _____
  435. - ---------/     /      /      /     /
  436. - --------/_____/      /____  /_____/    I ask, "Let us contemplate our
  437.  
  438. ------------------------------
  439.  
  440. Date:    Sun, 23 May 93 15:57:00 +0200
  441. >From:    Waldemar.Cichon@f6031.n491.z9.virnet.bad.se (Waldemar Cichon)
  442. Subject: Anyone have something like this? (PC)
  443.  
  444. Hi Malte,
  445.  
  446. you wrote to Hans as follows:
  447.  
  448.  >> Is it possible that you can get bad sectors because of a virus ?
  449.  ME> Logically yes (e.g. old DISK-KILLER marks three blocks as bad in the FAT),
  450.  ME> physically NO.
  451.  
  452. I think, a virus can also physically destroy tracs: he has only reformat some 
  453. tracs with its own sector numbering. OK, it's only possible on old MFM/RLL or 
  454. ESDI-HD-Drives, and I don't know viruses doing this, but like you can see ... 
  455. it's possible.
  456.  
  457. CU,
  458.  
  459. \    /       /
  460.  \/\/aldemar \ichon
  461.  
  462. - --- GoldED 2.41
  463.  * Origin: Mail Storage Hillerse - Die Spielwiese (9:491/6031)
  464.  
  465. ------------------------------
  466.  
  467. Date:    Tue, 01 Jun 93 10:29:05 -0400
  468. >From:    Donald G Peters <Peters@DOCKMASTER.NCSC.MIL>
  469. Subject: Redirection Difficulty (PC)
  470.  
  471. I'm trying to investigate how programs trap I/O and redirect it. The
  472. specific problem that I have is how does a program tell DOS to change
  473. its interpretation of standard input or output (or the other three
  474. standard handles for that matter). None of my books an DOS function
  475. (documented or undocumented) describe how to do this.
  476.  
  477. To wit, let's say you want to issue the DOS EXEC system call, and the
  478. program you want to EXEC reads and writes to standard I/O. But suppose
  479. you want to have DOS read or write to a file instead of the console.
  480. Now if you were issuing a command to COMMAND.COM, redirection is easy,
  481. but if you are trying to run a program using the DOS EXEC function,
  482. there seems to be no documented way.
  483.  
  484. Now please don't suggest EXEC('COMMAND.COM','/C pgm parameters >file') 
  485. because no malicious software could get away with that. I don't need
  486. to defend against such a weak attack; I want to defend against smart
  487. attacks. How do they do it? (It is done by 4DOS at least.) All I want
  488. to know is what do you do to have I/O redirected at the system call
  489. level.
  490.  
  491. There are plenty of DOS internal experts here and I'm sure someone knows
  492. the answer here.
  493.  
  494. ------------------------------
  495.  
  496. End of VIRUS-L Digest [Volume 6 Issue 90]
  497. *****************************************
  498.