home *** CD-ROM | disk | FTP | other *** search
/ Compu-Fix / Compu-Fix.iso / pubnews / vir04018.txt < prev    next >
Text File  |  1993-03-01  |  28KB  |  672 lines

  1.  
  2.  
  3.            VIRUS-L Digest   Friday,  1 Feb 1991    Volume 4 : Issue 18
  4.  ******************************************************************************
  5.  
  6.  
  7. Today's Topics:
  8.  
  9. Re: Text in MLTI virus (PC)
  10. Boot Sector/Partition Table Protection (PC)
  11. Hardware damage?
  12. Virex 3.0 init problems? (Mac)
  13. Table of Contents for Virus-L Digest
  14. Virus Proctection in Real Time
  15. Re: Text in MLTI virus (PC)
  16. STONED in files (PC)
  17. RE: Anti-virus policies
  18. Re: Word Perfect and change checkers (PC?)
  19. New viruses (PC)
  20. re: Antiviral product contact list (PC);
  21. Re: Infected vendor software (Mac)
  22. Weird Thing With F-Prot (PC)
  23. Re: Problem with virus checker (PC)
  24. Re: Stoned virus in partition table (PC)
  25.  
  26. VIRUS-L is a moderated, digested mail forum for discussing computer
  27. virus issues; comp.virus is a non-digested Usenet counterpart.
  28. Discussions are not limited to any one hardware/software platform -
  29. diversity is welcomed.  Contributions should be relevant, concise,
  30. polite, etc.  Please sign submissions with your real name.  Send
  31. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  32. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  33. anti-virus, documentation, and back-issue archives is distributed
  34. periodically on the list.  Administrative mail (comments, suggestions,
  35. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  36.  
  37.    Ken van Wyk
  38.  
  39. ---------------------------------------------------------------------------
  40.  
  41. Date:    Wed, 30 Jan 91 17:28:00 +0200
  42. From:    Y. Radai <RADAI@HUJIVMS.BITNET>
  43. Subject: Re: Text in MLTI virus (PC)
  44.  
  45.   Fridrik Skulason asked about the meaning of the following text in
  46. the MLTI virus:
  47. >        This programm was written in the city of Prostokwashino
  48. >        (C) 1990   RED DIAVOLYATA
  49.  
  50. The following info was supplied to me by a co-worker who recently
  51. emigrated from the USSR:
  52.   "RED DIAVOLYATA" is a partial translation of "Krasnie Dyavolyata".
  53. It and "Prostokvashino" are the names of well-known Soviet films.
  54. "Dyavolyata" was apparently too hard for the virus-writer to
  55. translate.  It means something like "little devils", and "Krasnie
  56. Dyavolyata" refers to the youth who fought against the White Army
  57. during the Russian Revolution.  The village "Prostokvashino" is a
  58. fictitious one, which explains why Brian McMahon didn't find it in the
  59. books he consulted.
  60.                                      Y. Radai
  61.                                      RADAI@HUJIVMS.BITNET
  62.  
  63. ------------------------------
  64.  
  65. Date:    30 January, 1991
  66. From:    Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
  67. Subject: Boot Sector/Partition Table Protection (PC)
  68.  
  69. >>From:    gt1546c@prism.gatech.edu (Gatliff, William A.)
  70.  
  71. >>To help combat this, what would be the possibility of 'delibrately'
  72. >>infecting ones boot-sector with a piece of code that would display
  73. >>some kind of 'ok' message if it hadn't been tampered with?
  74.  
  75. Exactly what I was talking about in issue 17 except the "partition
  76. table" sector (absolute sector one) should be used, not the boot
  77. sector. More, such code can be used to prevent any tampering with
  78. itself, the real partition table, or the active boot sector. At one
  79. extreme I have tried on a system with C: & D: drives was to put all
  80. executables on the C: drive and prohibit ANY writes or formats to that
  81. drive (except with a special maintenance program). The D: drive just
  82. has its low area protected and contains mutable programs and data.
  83.  
  84. A university or corporate environment might allow writing only to
  85. floppies or bernoullis, protecting the hard disk. While such software
  86. techniques alone cannot prevent an infected boot from occurring from a
  87. floppy - only hardware can do this - they do allow such intrusion to
  88. be detected prior to the load of the OS and can block any such
  89. infection thereafter.
  90.  
  91. I hope that this will stimulate some activity on the part of the
  92. vendors to provide such protection - it is not difficult to write, but
  93. for me, I would no longer consider any product complete unless some
  94. such form of low level protection was included.
  95.  
  96.                                         Padgett
  97.  
  98. ps: This is my hobby - you should see my job.
  99.  
  100. ------------------------------
  101.  
  102. Date:    Tue, 29 Jan 91 17:10:38 +0000
  103. From:    hagins@gamecock.rtp.dg.com (Jody Hagins)
  104. Subject: Hardware damage?
  105.  
  106. Please forgive my ignorance on this subject...
  107.  
  108. Is it possible for a virus, etc to cripple physical hardware
  109. components?  I ask as I have recently experienced an abrupt halt of my
  110. system, frying my power supply.  This occurred after aquiring a piece
  111. of software from a supposedly very reliable source.  Just wondering if
  112. this is related, or a coincidence.
  113.  
  114. Thanks for any help!
  115.  
  116. Jody Hagins
  117. hagins@gamecock.rtp.dg.com
  118. Data General Corp.
  119. 62 Alexander Dr.
  120. RTP, N.C.  27709
  121. (919) 248-6035
  122.  
  123. Nothing I ever say reflects the opinions of DGC.
  124.  
  125. ------------------------------
  126.  
  127. Date:    Wed, 30 Jan 91 13:10:47 -0600
  128. From:    "Stan Kerr" <stankerr@uiuc.edu>
  129. Subject: Virex 3.0 init problems? (Mac)
  130.  
  131. I just received Virex 3.0 a few days ago, and as soon as I installed
  132. it, Gatekeeper (1.1) started going crazy, complaining about things I
  133. had specified to allow in its configuration menu. As an example, I got
  134. NUMEROUS complaints that DA Handler was violating 'Res(other)'
  135. privileges against various applications. As soon as I turned off the
  136. Virex init, the complaints stopped.
  137.  
  138. - --------------------------------------------------------
  139. Stan Kerr                    Internet: stankerr@uiuc.edu
  140. University of Illinois       BITNET:   stankerr@uiucvmd
  141. Computing Services Office    Phone:    (217) 333-5217
  142. 1304 W. Springfield
  143. Urbana IL 61801
  144.  
  145. ------------------------------
  146.  
  147. Date:    Tue, 29 Jan 91 15:44:41 -0500
  148. From:    Colin Lay <CMLHD%UOTTAWA@acadvm1.uottawa.ca>
  149. Subject: Table of Contents for Virus-L Digest
  150.  
  151. Being a dedicated listener, and occasional contributor, to VIRUS-L
  152. Digest, I sometimes want to find out what was said, when, and by whom.
  153. There is no index to the Digest topics I am aware of, and therefore I
  154. decided to start the process, at least for myself, by creating a Table
  155. of Contents on a month by month basis.
  156.  
  157. I routinely download and ZIP the Digest and store the results on
  158. floppies (720K), in 1 month groups.  The big problem is where to find
  159. what I am looking for, a month or so later.  My partial solution is to
  160. use the following WordPerfect 5.1 macros to strip out all but the
  161. topic list and individual submission Date, From and Subject entries.
  162. So far in the month of January 1990, issues 1 to 16 are reduced to a
  163. Table of Contents file of 35,161 bytes, while the ZIPped digests are
  164. 148,044 bytes long, and the originals take 335377 bytes.
  165.  
  166. Following the macros in this submission I am including a sample of the
  167. output from Vol.4 Issue 1.  If there is sufficient interest, I can
  168. submit the Table of Contents on a regular basis to the Digest or some
  169. other appropriate repository.
  170.  
  171. [Ed. You might want to also take a look at Anthony Appleyard's index
  172. system.]
  173.  
  174. =============================================================
  175. Macro: Action
  176.      File             VIRUSL.WPM
  177.      Description      cleanup Virus-L Digest for Tbl of Con.
  178.      --------------------------------------------------------
  179.       {DISPLAY OFF}{Block}{Search}{Enter}
  180.       virus{Home}-l {Search}{Home}{Left}{Backspace}y{Enter}
  181.       {Search}{Search}{Home}{Left}{Block}{Search}{Enter}
  182.       Date: {Search}{Home}{Left}{Backspace}y
  183.       {CHAIN}vira~
  184.      --------------------------------------------------------
  185.  
  186. Macro: Action
  187.      File             VIRA.WPM
  188.      Description      Clean indiv.submiss. to Date,From,Subj
  189.      --------------------------------------------------------
  190.       {DISPLAY OFF}
  191.       {ON NOT FOUND}{GO}end~~
  192.       {Search}{Enter}
  193.       Subject: {Search}{Home}{Left}{Down}{Enter}
  194.       {Block}{Search}{Enter}
  195.       Date: {Search}{Home}{Left}{Backspace}y
  196.       {CHAIN}vira~
  197.       {RETURN}
  198. 1      {LABEL}end~
  199.       {CHAIN}virb~
  200.       {RETURN}
  201.      --------------------------------------------------------
  202.  
  203. Macro: Action
  204.      File             VIRB.WPM
  205.      Description      Cleanup last submission to eof
  206.      --------------------------------------------------------
  207.       {DISPLAY OFF}{Home}{Home}{Down}
  208.       {Up}{Up}{Up}{Up}{Up}{Backspace}y{Down}
  209.       {Down}{Down}{Block}{Home}{Home}{Down}{Backspace}y{HPg}
  210.      --------------------------------------------------------
  211.  
  212. ==============================================================
  213.  
  214. VIRUS-L Digest   Wednesday,  2 Jan 1991    Volume 4 : Issue 1
  215.  
  216. Today's Topics:
  217.  
  218. EXE file compression with LZEXE and PKLITE (PC)
  219. Macvirus index? (Mac)
  220. Disk Utilities (PC)
  221. Re: Virus Protection (PC)
  222. more about the conference in Hamburg
  223. ZeroHunt Virus (PC)
  224. Re: Viruses for the holidays & admin note
  225. please stop the requests
  226. Re: (1) GAO Report on Computer Security
  227. Zmodem infected with Violator (PC)
  228. UK Computer Crime Unit
  229. MIBSRV downtime
  230. WP viri and bugs (PC)
  231. Unix and Mainframe Viruses
  232. New virus (PC)
  233.  
  234. Date:    20 Dec 90 14:22:50 +0000
  235. From:    Mark Scase <coa44@seq1.keele.ac.uk>
  236. Subject: EXE file compression with LZEXE and PKLITE (PC)
  237.  
  238. Date:    Thu, 20 Dec 90 11:58:36 -0800
  239. From:    rrk@planets.risc.com (Richard Killion)
  240. Subject: Macvirus index? (Mac)
  241.  
  242. Date:    Thu, 20 Dec 90 15:14:00 -0400
  243. From:    Bill Thater <THATERW@SNYSYRV1.BITNET>
  244. Subject: Disk Utilities (PC)
  245.  
  246. Date:    Thu, 20 Dec 90 22:06:33 -0800
  247. From:    sulistio@sutro.SFSU.EDU (Sulistio Muljadi)
  248. Subject: Re: Virus Protection (PC)
  249.  
  250. etc.
  251. etc.
  252. etc.
  253.  
  254. Colin M. Lay,Assoc. Prof.
  255. Fac. of Administration, Univ. of Ottawa
  256. Tel. (613)564-7015  FAX (613) 564-6518
  257. "Any opinions expressed are mine, not necessarily those of my employer."
  258. Acknowledge-To: <CMLHD@UOTTAWA>
  259.  
  260. ------------------------------
  261.  
  262. Date:    Tue, 29 Jan 91 10:50:00 -0800
  263. From:    "David M. Ung x57408 <CSMIDMU%MVS.OAC.UCLA.EDU@BITNET.CC.CMU.EDU
  264. Subject: Virus Proctection in Real Time
  265.  
  266. Does anyone know about existing software packages that watch for suspicious
  267. viral activities in real time?
  268. Ken, if you have any of these info, could you please send it to me. Thank you.
  269. My address is CMSIDMU@UCLAMVS (this is a BITNET address).
  270.  
  271. ------------------------------
  272.  
  273. Date:    Wed, 30 Jan 91 16:32:36 +0000
  274. From:    morgan@ms.uky.edu (Wes Morgan)
  275. Subject: Re: Text in MLTI virus (PC)
  276.  
  277. >>The MLTI virus contains this text - clearly a reference to the "Eddie"
  278. >>virus, but what does "RED DIAVOLYATA" mean ?  (I want to emphasize
  279. >>that "Dark Avenger" is the name of the author of the "Eddie" virus -
  280. >>not the name of the virus itself.)
  281. >>
  282. >>       Eddie die somewhere in time!
  283. >>       This programm was written in the city of Prostokwashino
  284. >>       (C) 1990   RED DIAVOLYATA
  285. >>       Hello! MLTI!
  286.  
  287. Perhaps our virus author is a heavy-metal fan.  "Eddie" is the mascot
  288. of the group Iron Maiden.  Eddie happens to be a {corpse, undead, zom-
  289. bie}. (I'm not sure which word to use.  That group's discography in-
  290. cludes an album titled "Somewhere In Time".
  291.  
  292. Hmmmm.....a techno-metalhead conspiracy, perhaps?  Subliminal messages
  293. in rock albums inciting teenagers to digital terrorism?  Hmmmmmmm.....
  294.  
  295.     | Wes Morgan, not speaking for | {any major site}!ukma!ukecc!morgan |
  296.     | the University of Kentucky's |        morgan@engr.uky.edu         |
  297.     | Engineering Computing Center |   morgan%engr.uky.edu@UKCC.BITNET  |
  298.      Lint is the compiler's only means of dampening the programmer's ego.
  299.  
  300. ------------------------------
  301.  
  302. Date:    30 January, 1990
  303. From:    Padgett Peterson
  304. Subject: STONED in files (PC)
  305.  
  306.         For those wanting to check for STONED in executables as
  307. mentioned earlier using the McAfee /ext switch, I would suggest trying
  308. the string "a1 4c 00 *(2) a3 ? ? a1 4e 00 a3" <name>
  309.  
  310.         While this may generate some "false positives", I would like to
  311. know about ANY files that try to do this since it may indicate a low level
  312. (not through DOS) access of the INT 13 vectors.
  313.  
  314.         Note: use your own <name> since duplication of one of Mr. McAfee's
  315. names may result in SCAN not checking for the virus otherwise.
  316.  
  317.                                                         Padgett
  318.  
  319. ------------------------------
  320.  
  321. Date:    Thu, 31 Jan 91 10:57:00 +0100
  322. From:    "Nick FitzGerald" <CCTR132@csc.canterbury.ac.nz>
  323. Subject: RE: Anti-virus policies
  324.  
  325. In V4 #17 (Mon, 28 Jan 91) rtravsky@CORRAL.UWyo.Edu (Richard W Travsky) wrote:
  326.  
  327. >[deletions]
  328. > 1. Viral Software
  329. >    a. Viral scanning/cleaning software will not be used unless the
  330. >       accompanying documentation has been read by the support person
  331. >       doing the scan/cleanup.
  332. >    b. Viral scanning/cleaning software should be kept reasonably up to date.
  333. >[As stated,  we've had fairly low virus activity,  so being up to date with
  334. >the latest is not real important - yet.]
  335. >    c. More than software product should be used for cross checking purposes.
  336. >    d. After removal of a virus,  the machine/disk should be re-scanned to
  337. >       verify removal.
  338.  
  339. I would disagree on point b. - you should keep as up to date as there is.
  340. Whilst the virii you are most likely to experience are "old" and widely
  341. distributed, the newest scanner might one day save you from a very recent
  342. hard disk trasher.  Unfortunately, it is difficult to convince most users
  343. (and "the powers that be") to go to the little extra trouble of updating
  344. their external virus file (or the software itself) as often as possible
  345. (unless they have been caught already).
  346.  
  347. > 2. Maintenance
  348. >[good practices deleted]
  349. >    c. All diagnostic disks will have write protect tabs.
  350.  
  351. NO!!  All such disks should be UNNOTCHED.  Get one of your tech's to
  352. bypass the write-protect switch on drive B: on ONE machine that is in
  353. a very secure place.  Make copies of diagnostics disks, installation
  354. disks (more below) etc onto disks that have not been notched.  It may
  355. take a bit of effort on your part to find a supply, but do so and use
  356. them.  (We found a ready supply in our safe - multiple copies of
  357. obsolete software packages like PC (IBM) DOS, PC-SAS.)  For 3.5" disks
  358. pry the slide thingy out.  (That's what I don't like about 3.5" disks
  359. compared to notchless 5.25" disks - a user with malicious intent can
  360. easily disable write-protection and then enable it without leaving any
  361. obvious signs of it).
  362.  
  363. >   d. If software is being restored to someone's machine (like a backup,
  364. >       format,  and then a restore) the disks should be checked for infection.
  365. >
  366. > 3. Installs
  367. >[We install software - like PC SAS - on users' machines.
  368. >    a. When possible,  install disks will have write protect tabs.
  369. >    b. When write protect tabs can not be used,  the install disks will be
  370. >       checked for infection upon return.
  371. >[Some software,  like dBase 4 we found,  writes to the install floppy during
  372. >installation.]
  373. >    c. User's machine should be checked for infection.
  374. >[This would take care of b .]
  375.  
  376. Similar comments as above re write-protect tabs.  Installation
  377. procedures that write to the installation disks are the pits.  The
  378. sooner that vendors take the virus threat seriously, and start
  379. distributing their software on *unnotched* disks the better - McAfee
  380. Associates, are you listening?  Some software licences we have allow
  381. us to install on many machines - we copy the original disks to
  382. notchless ones and distribute these to the users who want to install
  383. the programs.  (We only do installation ourselves if specially asked -
  384. we would spend all our time doing them otherwise.)  This may seem
  385. paranoid, but (before I started here) there was a case of the notched
  386. but write-protected disks our working copy was on coming back
  387. infected.  The user had taken the tabs off the disks - because of past
  388. experience with install programs that required write access to the
  389. distribution disks - and dutifully stuck them back on when the
  390. installation was complete.  This was not an intentionally malicious
  391. act.
  392.  
  393. >[further good practices deleted]
  394.  
  395. My recommendations above may seem a little strong for some, but I
  396. would say you're kidding yourself if you think you don't have to go to
  397. these lengths.  Possible exception - *everyone* at your site who will
  398. *ever* have access to your disks and/or machines *always* does
  399. *everything* that *perfect* users *should* do.  Get the point?
  400.  
  401. Can't remember where, but I read the following somewhere:
  402. "Once is happenstance, twice is coincidence, three times is enemy action".
  403.  
  404. With virii, "Once is enemy action", and you have to be very careful if you
  405. want to prevent that one event.
  406.  
  407. - ---------------------------------------------------------------------------
  408.  Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
  409.  Internet: n.fitzgerald@csc.canterbury.ac.nz        Phone: (64)(3) 642-337
  410.  
  411. ------------------------------
  412.  
  413. Date:    Thu, 31 Jan 91 03:53:55 +0000
  414. From:    hampster@wyatt.ksu.ksu.edu (Kip J Mussatt)
  415. Subject: Re: Word Perfect and change checkers (PC?)
  416.  
  417. p1@arkham.wimsey.bc.ca (Rob Slade) writes:
  418. >csw76@seq1.keele.ac.uk (J.C. Kohler) writes:
  419. >
  420. >> I'm using a Dutch version of WP 5.1, does anybody has an ideay why
  421. >> F-XLOCK can't lock them, it displays an error message, which contains
  422. >> something about a illegal header.
  423. >
  424. >All versions of Word Perfect (at least since 4.2) have had a self
  425. >testing module on them.  Neither F-XLOCK nor SCAN /AV nor any other
  426. >slef checker that adds code to the program can be used on it, since
  427. >the added code invalidates the internal self test.
  428.  
  429. If I am understanding you correctly, WP 4.2 and later versions should
  430. be virus proof?  If this is your assumption then why did we have an
  431. epidemic of the Jeru II virus that infected almost every wp 4.2, 5.0,
  432. and 5.1 at work?  Again, if I am misunderstanding what you are saying
  433. about WP product, then please clarify.  If not, then could you please
  434. shed some light on my question. Thanx
  435.  
  436.                                                 -KJM
  437.  
  438. ------------------------------
  439.  
  440. Date:    Thu, 31 Jan 91 09:29:14 +0000
  441. From:    frisk@rhi.hi.is (Fridrik Skulason)
  442. Subject: New viruses (PC)
  443.  
  444. Well, folks - we now have around 400 PC viruses - currently we get on
  445. the average one new virus per day, and the rate is increasing...maybe
  446. we will have 1000 before the end of the year.
  447.  
  448. Anyhow - for users of F-PROT 1.14 - please add the following encrypted
  449. signatures to the SIGN.TXT, to provide detection of the viruses I have
  450. received since Jan 15th.
  451.  
  452. Hybryd      iglMWj8jKMNAUHcZbj2AgYSdg9nmFsp7Ueys-pc3-ha7Iv
  453. Akuku       3Ux5pMu5858HMj5MgXdA19n8x4ybN5YtMmkm6PpykupSZ6
  454. SVC3.1      3Hxnv5u5uM749Lydm-SnY4PoYnOwIt7V5fUuMFxBWfZa9j
  455. Paris       iH15v5umAmruKeV504HK8eHKjrG8wEEjT5m2M5DsdwO+UO
  456. Doom2       zU1MCmKMA5m8UVPmT5Xpp3cMgB7jUE0MTmURMVc5zv5nOk
  457. Wolfman     ZUo5pjKmujwA5fwOvjMMxl08fifY55pip5JWdwxhDU1eA7
  458. MIX2        zw1NW58mAjwH4AuFV51rm6AtQlj5j62fXXjXFujf8gQelB
  459. 403         zHTkvju5AmvVgbS8Jl75nmwlrKxNc5N5gbED3mk5GKlYYn
  460. ACAD-2576   3g6jpmKMAMa62XAcz5hkFSwRqqUNd0m5HNimvOSWGrAHYb
  461. Ontario     ZHJnWM-MimyuCuAwkj-28UnjxYjLwlMEWm1vRgKqE47UYK
  462. Leprosy     iHNjpjKmumoXO8rHxotuxiWmtHW5mK4bD51CMK4Em5tnCG
  463. Perfume-731 Zwbjvju585fhqt5jjm7YpyNufwmMWj1jhOFtM53cOrmNYW
  464. Spyer       ZgJnC58Mu5O8JVTjTmEmih4YV+vPmo74O810TMkjYd3tFW
  465. Ussr-1594   iUCTpmSMzmUkiMt26N5MURjKz7jaVpT8thP0bjfZcqbLHQ
  466. Sentinel    zHJkpM8mum4YIPgBEPjMNMfPgBRsB5NmauFwe6At5j+8ol
  467. Monxla-B    zHbmvjujKMSKWaQTjjWdfBe4Nb5uQg35XiMNWtMvSdIsbE
  468. Xmas Viol   3HRmvjuMAjnN4saOj5m8BhgDStp5MMFPUD6i9UBHDhTVHV
  469.  
  470. ------------------------------
  471.  
  472. Date:    31 Jan 91 09:32:51 -0500
  473. From:    "Otto.Stolz" <RZOTTO@DKNKURZ1.BITNET>
  474. Subject: re: Antiviral product contact list (PC);
  475.  
  476. You wrote:
  477. > The following is a list of antiviral product vendors, mostly for the
  478. > PC line.  [...]
  479. > I would appreciate feedback on any errors or ommissions
  480.  
  481. I did not see one of my favourite products on your list:
  482.    Vendor:  S&S International Ltd.
  483.             Berkley Court, Mill Street
  484.             Berkhamsted, Herts. HP4 2HB
  485.             England
  486.    Phone:   +44 442 877 877
  487.    Fax:     +44 442 877 882
  488.             (Note that address & phone have been changed around New Year
  489.             1991, so anybody having the old address in Chesham Bucks.,
  490.             please update your files!)
  491.    BBS:     +44 494 724 946 (used to be -- still valid??)
  492.    E-Mail:  Dr. Alan Solomon <DRSOLLY@IBMPCUG.CO.UK>
  493.    Product: Dr. Solomon's Anti-Virus Toolkit
  494.  
  495. A German variant of this product is also available:
  496.    Vendor:  perComp Verlag GmbH
  497.             Holzm&LU17.hlenstra&LS61.e 84
  498.             2000 Hamburg 70
  499.             Germany
  500.    Phone:   +49 40 693 2033
  501.    Fax:     +49 40 695 9991
  502.    E-Mail:  G&LU17.nter Mu&LS61.topf <percomp@infohh.rmi.de>
  503.    Product: Dr. Solomons Anti-Viren-Werkzeuge
  504. where "&LU17." is u-Umlaut (looking like a small letter u with diaeresis)
  505.   and "&LS61." is German sharp-s (resembling a greek small beta)
  506. I know, Ken's system will trash genuine Umlauts and sharp-s, so I had to
  507. resort to this device ...  :-(
  508.  
  509. The toolkit is regularly updated & comes with a detailed documentation.
  510. It comprises tools for preventing, finding and removing viruses.
  511. The virus-scanner provided with this toolkit is the fastest I've ever
  512. seen; it's search-patterns are derived from the vendor's own research.
  513.  
  514. Please do not regard the above as advertising: I'm not affiliated or
  515. otherwise economically connected to S&S, nor to perComp; I'm just a
  516. satisfied user.
  517.  
  518. Btw, as it has been asked in VIRUS-L befor for information of this kind:
  519. We also use F-PROT, and I'm pleased with it. I try to convince as many
  520. users as possible to install F-DRIVER and F-OSCHK on their own computers
  521. (so far I've not been successful enough), and I use Dr. Solomon's
  522. FINDVIRU to cope with heavy virus incidents. I also use ancillary tools
  523. from both packages.
  524.  
  525. A general remark:
  526.  
  527. For virus-specific tools, particularly virus-scanners, your final product
  528. list should state
  529. 1. how often the tools will be updated;
  530. 2. where the virus-specific information is derived from.
  531.  
  532. ad 1: These days, we are experiencing an ever increasing flood of new
  533.       virus strains and variants. To cope with these new viruses, a
  534.       virus-specific tool has to be updated regurlarly -- actually more
  535.       often than any other product in the EDP market. I'd guess that we
  536.       will have to arrive at monthly updating in the near future.
  537.  
  538. ad 2: Many vendors take their search string from public sources. Now, two
  539.       virus-specific tools from two different vendors are essentialy the
  540.       very same thing when they exploit search patterns from the same
  541.       external source. Only a vendor who does his own research into
  542.       viruses and derives his own search patterns can offer a genuinely
  543.       particular product. And the more different scanners a user
  544.       applies, the more unknown variants of known viruses he is likely
  545.       to spot.
  546.  
  547. Best regards
  548.              Otto Stolz
  549.  
  550. ------------------------------
  551.  
  552. Date:    Thu, 31 Jan 91 10:30:43 -0500
  553. From:    Joe McMahon <XRJDM@SCFVM.GSFC.NASA.GOV>
  554. Subject: Re: Infected vendor software (Mac)
  555.  
  556. THE GAR <GLWARNER@SAMFORD.BITNET> writes:
  557. >BUT . . . SIMWARE's "SimMac 3.1 Application Disk" (Master Program),
  558. >which I received on or about Jan 11 was infected!  SAM reports that it
  559. >was last altered on 12/21/90 at 12:55 PM.  This INFURIATES me, as I
  560. >had up until today always trusted the programs that come straight from
  561. >the manufacturer sealed in the "Read Carefully BEFORE Opening" license
  562. >envelope!
  563.  
  564. We have, many times, emphasized that manufacturers are human, too.
  565. Always scan *everything* you get, no matter what the source!
  566.  
  567.  --- Joe M.
  568.  
  569. ------------------------------
  570.  
  571. Date:    Thu, 31 Jan 91 10:05:43 -0700
  572. From:    rtravsky@CORRAL.UWyo.Edu (Richard W Travsky)
  573. Subject: Weird Thing With F-Prot (PC)
  574.  
  575. This Wednesday I visited our Law school to check on problem with the
  576. pong virus in their computer lab (three machines, not a big lab).
  577. Each machine had a 5.25" drive and a 20 meg hard disk.  I scanned the
  578. machines, booting off a tabbed write-protected floppy in the A: drive.
  579. I ran McAfee's Scan (version 4.5V6-B), said everything was ok.  Out of
  580. curiousity, I also ran F-FCHK and F-BOOT from the F-PROT package
  581. (version 1.13).  A funny thing happened: when F-FCHK came across the
  582. file INSTALL.EXE from the PCPANEL package (something to do with
  583. redirecting printer output) I got an error message saying it couldn't
  584. write to the A: drive (the familiar "abort, retry, fail"). I ran it
  585. again, same result.  I ran it on another machine, same result when it
  586. came across that file.
  587.  
  588. This is a bit weird.  Didn't happen using Scan.  Why should scanning a
  589. file provoke a write attempt?  I realize these are not the latest
  590. versions of the packages, but I feel that to be irrelevant.  Anyone
  591. have any ideas?
  592.  
  593. +-----------------+     Richard Travsky
  594. |                 |     Division of Information Technology
  595. |                 |     University of Wyoming
  596. |                 |     Bitnet:   RTRAVSKY @ UWYO
  597. |                 |     Internet: RTRAVSKY @ CORRAL.UWYO.EDU
  598. |           U W   |     (307) 766 - 3663 / 3668
  599. |            *    |     "Wyoming is the capital of Denver." - a tourist
  600. +-----------------+     "One of those square states." - another tourist
  601. Home state of Dick Cheney,  Secretary of Defense of these here UNITED STATES!
  602.  
  603. ------------------------------
  604.  
  605. Date:    31 Jan 91 17:31:37 +0000
  606. From:    jesse@altos86.Altos.COM ( Jesse Chisholm)
  607. Subject: Re: Problem with virus checker (PC)
  608.  
  609. PERETTI%auvm.auvm.edu@VM1.gatech.edu (Brian J. Peretti) writes:
  610. >A friend of mine is using the McAfee virus scan program on his computer.  When
  611. >he attempts to run the program, however, the program does not run.  As soon as
  612. >the line with the phone number comes up, some funny characters come onto the
  613. >screen and then the c: prompt reappears.  Whenever he puts a clean disk into
  614. > the computer, the disk, when scanned on another machine, the stoned virus is
  615. >on the disk.  Does anyone have an answer to this problem?
  616. >
  617. >Thanks,
  618. >Brian J. Peretti
  619.  
  620. Sounds to me like two things have happened.
  621.  
  622. (1) his machined has the STONED virus in its partition table
  623.  
  624. (2) the copy of SCAN that he has is damaged.  He should call the
  625. McAfee BBS and down load the current version as soon as
  626. possible.
  627.  
  628. Since the STONED virus is there, he could go ahead and run the
  629. CLEAN program to remove it.  Then see if SCAN could detect any
  630. more.
  631.  
  632. ========================================================================
  633. Jesse Chisholm          | "Belief without understanding is superstition;
  634. jesse@Altos86.Altos.COM |  Understanding without belief is theology;
  635. Tel 1-408-432-6200x4810 |  It takes both for a living faith."
  636. Fax 1-408-434-0273      |                --  Dr. Wolfgang Gross
  637.  
  638. ------------------------------
  639.  
  640. Date:    31 Jan 91 17:36:51 +0000
  641. From:    jesse@altos86.Altos.COM ( Jesse Chisholm)
  642. Subject: Re: Stoned virus in partition table (PC)
  643.  
  644. The STONED (and other partition table) virus is tricky to get
  645. rid of.  I recommend getting the CLEAN program from McAfee
  646. Associates.
  647.  
  648.                 McAfee Associates
  649.                 4423 Cheeney Street
  650.                 Santa Clara, CA 95054
  651.                 408 988 3832 (voice)
  652.                 408 988 4004 (BBS)
  653.  
  654. The current versions of SCAN and CLEAN may be downloaded.  With
  655. these the STONED virus can be removed without the hassle of
  656. removing/losing data on the hard disk.
  657.  
  658. ========================================================================
  659. Jesse Chisholm          | "Belief without understanding is superstition;
  660. jesse@Altos86.Altos.COM |  Understanding without belief is theology;
  661. Tel 1-408-432-6200x4810 |  It takes both for a living faith."
  662. Fax 1-408-434-0273      |                --  Dr. Wolfgang Gross
  663.  
  664. ------------------------------
  665.  
  666. End of VIRUS-L Digest [Volume 4 Issue 18]
  667. *****************************************
  668.  
  669.  
  670.  
  671.  
  672.