home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / virusl / vl04_018.txt < prev    next >
Internet Message Format  |  1996-09-04  |  28KB

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