home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / misc / v05i117.txt < prev    next >
Internet Message Format  |  1992-09-27  |  41KB

  1. From:       Kenneth R. van Wyk (The Moderator) <krvw@CERT.ORG>
  2. Errors-To: krvw@CERT.ORG
  3. To:       VIRUS-L@IBM1.CC.LEHIGH.EDU
  4. Path:      cert.sei.cmu.edu!krvw
  5. Subject:   VIRUS-L Digest V5 #117
  6. Reply-To:  VIRUS-L@IBM1.CC.LEHIGH.EDU
  7. --------
  8. VIRUS-L Digest   Tuesday, 16 Jun 1992    Volume 5 : Issue 117
  9.  
  10. Today's Topics:
  11.  
  12. AIDS information diskette - Dr Popp (re: Dr Finkel's talk) (PC)
  13. Re: F-PROT & DR-DOS 6.0 (PC)
  14. Re: SCAN vs. CLIPPER 5.0 (PC)
  15. Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
  16. Re: Detecting the MtE (PC)
  17. re: SCAN vs. CLIPPER 5.0 (PC)
  18. re: Virus or hard disk problems ? (PC)
  19. Re: SCAN vs. CLIPPER 5.0 (PC)
  20. Re: Zipped Viruses (PC)
  21. Re: Help for a new(unknown) virus (PC)
  22. Re: SCAN vs. CLIPPER 5.0 (PC)
  23. Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
  24. SCAN 91 has drastically changed the virus names used (PC)
  25. Re: ISPNews & Virx (PC)
  26. Help! Does anyone know about any known UNIX viruses? (UNIX)
  27. Teoretical questions
  28. Re: Taxonomy of viruses
  29. Fred Cohen (CVP)
  30. PC pranks and trojans (CVP)
  31. Call For Papers: 6th Annual Virus Conference
  32.  
  33. VIRUS-L is a moderated, digested mail forum for discussing computer
  34. virus issues; comp.virus is a non-digested Usenet counterpart.
  35. Discussions are not limited to any one hardware/software platform -
  36. diversity is welcomed.  Contributions should be relevant, concise,
  37. polite, etc.  (The complete set of posting guidelines is available by
  38. FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
  39. your real name.  Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU
  40. (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks).
  41. Information on accessing anti-virus, documentation, and back-issue
  42. archives is distributed periodically on the list.  A FAQ (Frequently
  43. Asked Questions) document and all of the back-issues are available by
  44. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  45. (comments, suggestions, and so forth) should be sent to me at:
  46. <krvw@CERT.ORG>.
  47.  
  48.    Ken van Wyk
  49.  
  50. ----------------------------------------------------------------------
  51.  
  52. Date:    Wed, 10 Jun 92 17:30:00 +0100
  53. From:    Anthony Naggs <AMN@VMS.BRIGHTON.AC.UK>
  54. Subject: AIDS information diskette - Dr Popp (re: Dr Finkel's talk) (PC)
  55.  
  56. Dear Dr Finkel, I have just FTP'd the talk you advertised on comp.virus.
  57. I have not yet read it all, however the following caught my eye and as
  58. the misconceptions are likely to be widespread I'm posting a CC to comp.virus.
  59.  
  60. Under the "Trojans" section of your talk:
  61. > 12 December 1989: A distribution diskette from a corporation calling itself PC
  62. > Cyborg has been widely distributed to major corporations and PC user groups
  63. > around the world and the diskette contains a highly destructive trojan.  The
  64. > Chase Manhattan Bank and ICL Computers were the first to report problems with
  65. > the software.  All systems that ran the enclosed programs had all data on the
  66. > hard disks destroyed.  Hundreds of systems were affected.
  67. >
  68. > Postscript: 2 December 1991: Joseph L.  Popp Jr., 39, was arrested in Cleve-
  69. > land and charged with blackmail, extradited to England, and charged with mail-
  70. > ing 20,000 such disks from London about 11 December, 1989.  Prosecutors there
  71. > decided to drop the case in November, 1991 for lack of evidence.
  72.  
  73. First I would suggest mentioning that this is the "AIDS information diskette",
  74. as your audience may have heard of this.  More importantly a couple of factual
  75. errors:
  76. 1   To say that "systems ... had all data on the hard disks destroyed" is an
  77.     over simplification.  After installing the s/w the trojan element, which
  78.     encrypted the hard disk content, was only activated after 200 reboots.
  79.     A number of utilities were produced that would perform the de-installation
  80.     and/or decryption of the hard disk, these were widely used and allowed 100%
  81.     recovery for most affected users.
  82. 2   The case was not "dropped ... for lack of evidence".  It was in fact
  83.     discontinued as the court decided that Joseph Popp was unfit to stand
  84.     trial, ie due to his mental state he would not understand the court
  85.     proceedings.  Apparently he insisted on putting hair rollers in his
  86.     beard claiming that they protected him from extraterrestrial radiation!
  87.     I beleive he was deported back to the US, but he could be rearrested
  88.     and the trial resumed if his apparent mental state improves.
  89.  
  90. Oh, and one other minor observation, I consider "FAT table" to be an oxymoron.
  91. (FAT stands for File Allocation Table).
  92.  
  93. Regards, Anthony Naggs
  94.  
  95. ------------------------------
  96.  
  97. Date:    11 Jun 92 10:25:56 +0000
  98. From:    frisk@complex.is (Fridrik Skulason)
  99. Subject: Re: F-PROT & DR-DOS 6.0 (PC)
  100.  
  101. HRZ090@DE0HRZ1A.BITNET (Dr. Martin Erdelen) writes:
  102.  
  103. >Good morning (Central European Summertime) everybody,
  104.  
  105. >here are two questions concerning F-PROT:
  106.  
  107. >1) What does the message "invalid program" mean?
  108.  
  109. If the program is run directly under DOS, it will hang the machine :-)
  110.  
  111. Well, actually, there are several possible explanations:
  112.  
  113.      The program is a .COM file that starts with a JMP out of the
  114.      program code.
  115.  
  116.      The program is an .EXE file, with initial entry point outside the
  117.      code, or with the size according to the header greater than the
  118.      actual size of the file.
  119.         
  120. >2) Several users reported problems when trying to run VIRSTOP (v.
  121. > 2.01) under DR-DOS v. 6.0.
  122.  
  123. I have received reports of this, and am looking into it.  Actually,
  124. VIRSTOP is currently being rewritten entirely, as I am implementing
  125. several new features.
  126.  
  127. >VIRSTOP *can* be installed by simple command in AUTOEXEC.BAT, but then is
  128. >reported to use up over 52 KB of memory. Can't be true, can it?
  129.  
  130. Nope - it should use less than 10K.  Actually I am considering storing
  131. the signatures in a separate file, which should bring the size down to
  132. 3-4K.
  133.  
  134. >I am wondering why I have never seen this mentioned on VIRUS-L - after all,
  135. >DR-DOS isn't that rare. Am I missing something?
  136.  
  137. Well, it does not seem to happen on all machines - I know of people
  138. using DR DOS 6, who are using VIRSTOP without any problems whatsoever.
  139.  
  140. - -frisk
  141.  
  142. ------------------------------
  143.  
  144. Date:    11 Jun 92 10:30:15 +0000
  145. From:    frisk@complex.is (Fridrik Skulason)
  146. Subject: Re: SCAN vs. CLIPPER 5.0 (PC)
  147.  
  148. CEZAR@PLEARN.BITNET (Cezar Cichocki) writes:
  149.  
  150. >Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
  151. >for immunization. Immunized CLIPPER said me : 'Rules not found in file
  152. >CLIPPER.EXE', and didn't work corectly.
  153.  
  154. Nothing strange about this - it is simply a bad idea to modify
  155. executables :-) I used to have something similar in version 1.X of
  156. F-PROT - a program named F-XLOCK, which could be used to add
  157. self-checking code to any program, but dropped that for two reasons -
  158. The one you described - not all programs worked after having been
  159. modified, and also because my approach was ineffective against stealth
  160. viruses.  I am working on a better approach - a generic checksumming
  161. program, which should be ready soon.
  162.  
  163. - -frisk
  164.  
  165. ------------------------------
  166.  
  167. Date:    11 Jun 92 10:33:43 +0000
  168. From:    frisk@complex.is (Fridrik Skulason)
  169. Subject: Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
  170.  
  171. doc@magna.com (Matthew J. D'Errico) writes:
  172.  
  173. >Hi, all...
  174.  
  175. >I thought I'd pass along the essence of a growing thread from
  176. >compuserve in which some false alarms have been caused by Norton
  177. >Anti-Virus' latest update (04) for version 2.0 which was released on
  178. >June 1st...
  179.  
  180. Well, the reason is simple - the Wonder virus is written in Borland C++,
  181. and the signature string some scanners use (not only Symantec) just happens
  182. to be found in lots of programs compiled with this scanner.
  183.  
  184. So, if a scanner reports Wonder, don't be alarmed - get a "second opinion",
  185. run my F-PROT, McAfee's SCAN, Alan SOlomon's FINDVIRU or some other scanner
  186. which does not generate a false report on this virus.
  187.  
  188. - -frisk
  189.  
  190. ------------------------------
  191.  
  192. Date:    11 Jun 92 10:42:42 +0000
  193. From:    frisk@complex.is (Fridrik Skulason)
  194. Subject: Re: Detecting the MtE (PC)
  195.  
  196. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  197.  
  198. >1) They "forgot" to mention the results of F-Prot (13 missed variants)
  199.  
  200. Perfectly understandable from a marketing point of view, as they are
  201. loosing some of their biggest customers to me :-)
  202.  
  203. >Meanwhile the missed variants have been sent to McAfee Associates and
  204. >Fridrik Skulason
  205.  
  206. I went over the 13 samples I missed, and much to my relief I discovered that
  207. this problem was caused by one minor incorrect assumption - the basic
  208. algorithm was ok.  So, version 2.04, which will be released any day now
  209. (it will be distributed before the NCSA conference in Washington next week),
  210. should have a 100% detection ratio.
  211.  
  212. - -frisk
  213.  
  214. ------------------------------
  215.  
  216. Date:    Thu, 11 Jun 92 15:16:00 +0700
  217. From:    Karel=Sprenger@disc.uva.nl
  218. Subject: re: SCAN vs. CLIPPER 5.0 (PC)
  219.  
  220. On Thu, 04 Jun 92 20:32:16 +0700 Cezar Cichocki <CEZAR@PLEARN.BITNET> wrote:
  221.  
  222. > Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
  223. > for immunization. Immunized CLIPPER said me : 'Rules not found in file
  224. > CLIPPER.EXE', and didn't work corectly.
  225.  
  226. The same happens with VirusBuster's PROTECT and WATCHDOG. These also
  227. add a checksum at the end of a program file. There seem to be a number
  228. of programs that don't like additions such as these. I'm sure of
  229. FoxPro 2.0 and Clipper 5.01, but would like to hear about others. Is
  230. there a list of these somewhere around?
  231.  
  232. +--------------------------------------+-------------------------------------+
  233. |   Karel Sprenger                     |   Email: ks@disc.uva.nl             |
  234. |   DISC                               |          a701233k@hasara11 (BITNET) |
  235. |   University of Amsterdam            |   phone: +31-20-525 2302            |
  236. |   Turfdraagsterpad 9                 |   fax  : +31-20-525 2084            |
  237. |   NL-1012 XT  AMSTERDAM              |   home : +31-20-675 0989            |
  238. +--------------------------------------+-------------------------------------+
  239.  
  240. ------------------------------
  241.  
  242. Date:    Thu, 11 Jun 92 15:15:59 +0700
  243. From:    Karel=Sprenger@disc.uva.nl
  244. Subject: re: Virus or hard disk problems ? (PC)
  245.  
  246. Alan Gilbertson's advice (Wed, 03 Jun 92 17:54:46 -0400) to Andy Ravenna
  247.  
  248. > Check your CMOS hard drive setting and compare it with what your drive
  249. > requires.  Hopefully, you can correct this and clear up the trouble.
  250.  
  251. reminded me of a friend who accidentally corrupted his CMOS and didn't
  252. knew what the settings used to be. As this happened during the weekend
  253. and his dealer wasn't open on monday, he couldn't use his PC longer
  254. than he cared to. It taught him to write down the proper settings,
  255. just in case bad luck strikes again. If only he could remember where
  256. he put that note :-) BTW, aren't there virussen that destroy CMOS
  257. settings?
  258.  
  259. +--------------------------------------+-------------------------------------+
  260. |   Karel Sprenger                     |   Email: ks@disc.uva.nl             |
  261. |   DISC                               |          a701233k@hasara11 (BITNET) |
  262. |   University of Amsterdam            |   phone: +31-20-525 2302            |
  263. |   Turfdraagsterpad 9                 |   fax  : +31-20-525 2084            |
  264. |   NL-1012 XT  AMSTERDAM              |   home : +31-20-675 0989            |
  265. +--------------------------------------+-------------------------------------+
  266.  
  267. ------------------------------
  268.  
  269. Date:    11 Jun 92 12:06:00 -0500
  270. From:    hutchinson@wrair-emh1.army.mil
  271. Subject: Re: SCAN vs. CLIPPER 5.0 (PC)
  272.  
  273.  Cichocki <CEZAR@PLEARN.BITNET> writes:
  274. > Hi!
  275. >
  276. > Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
  277. > for immunization. Immunized CLIPPER said me : 'Rules not found in file
  278. > CLIPPER.EXE', and didn't work corectly.
  279. >
  280. > When I reinstalling CLIPPER, all was right. I repeat it few times, and
  281. > my conclusion is : adding generic code to CLIPPER.EXE make it unusable
  282. > ( of course I can add rules manualy, but it is funny idea, is'n it ?)
  283. >
  284. > Cezar Cichocki
  285. > System operator
  286.  
  287. A better conclusion is: adding generic code to *any* program is bad news.
  288. Clipper is just one of many programs that don't take kindly to being
  289. modified.  If you want to use this feature of SCAN, you'd be better off
  290. using the /AF option, which stores the information in a separate file.
  291.  
  292.     -Hutch
  293. - --------------------------------------
  294. Bob Hutchinson
  295. Walter Reed Army Institute of Research
  296. (hutchinson@wrair-emh1.army.mil)
  297.  
  298. ------------------------------
  299.  
  300. Date:    Thu, 11 Jun 92 20:19:10 +0000
  301. From:    007 <sbonds@jarthur.Claremont.EDU>
  302. Subject: Re: Zipped Viruses (PC)
  303.  
  304. mwb@wybbs.mi.org (Michael W. Burden) writes:
  305.  
  306. >Even better yet:  Make sure you get a clean copy of your anti-virus
  307. >tools BEFORE you get infected, put them on a floppy, write protect
  308. >it, and NEVER run these programs from the hard disk.
  309.  
  310. Always the best thing to do before starting any sort of virus scanning.
  311.  
  312. Would it be feasible to write a virus defense package that would ONLY
  313. run after booting from a clean, write-protected floppy?  The
  314. programming aspect is fairly straightforward, but would people accept
  315. a product like this?  Ideally it would include a known clean copy of
  316. DOS with it, but this could cause problems with copyright laws, etc.
  317. A product like this could solve a lot of problems with scanners
  318. missing stealth viruses.
  319.  
  320.   -- 007
  321. - -- 
  322.  000   000  7777 | sbonds@jarthur.claremont.edu
  323. 0   0 0   0   7  |----------------------------------------------------------- 
  324. 0   0 0   0  7   |             Just say NO to Quantum Mechanics
  325.  000   000   7   |  
  326.  
  327. ------------------------------
  328.  
  329. Date:    12 Jun 92 10:26:55 +0000
  330. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  331. Subject: Re: Help for a new(unknown) virus (PC)
  332.  
  333. adv5@saathi.ernet.in (Course account) writes:
  334.  
  335. > 1. File or Boot Sector virus
  336. > 2. Attaches to EXE or COM programs
  337. > 3. Increases filesize by 3K
  338. > 4. Corrupts FAT of hardisks and floppies
  339. > 5. Makes starting cluster of all EXE and COM programs in FAT the same
  340. > 6. Can't be detected by SCAN 4.5B66, or Findvir(ver 4.2), CPAV(ver 1) or NAV
  341. > 7. Mostly likely doesnot remain  in memory
  342. > 8. Activated by running infected files.
  343. > 9. Probable name of the virus is 'Made in India' (Wild Guess).
  344.  
  345. A few remarks:
  346.  
  347. 1) If 2. and 3. are true, then it infects files for sure. What do you
  348. mean by 1.? That it infects boot sectors too? Have you verified this?
  349.  
  350. 2) There is only one virus (in five variants) which acts as described
  351. in 5. - the Dir II virus. But it is rather well known and most
  352. contemporary scanners should detect it. Also, it is completely
  353. different from what your other descriptions suggest.
  354.  
  355. 3) You are using rather strange scanning software - SCAN is about two
  356. years old (which means that it is completely obsolete), Findvirus
  357. (form Dr. Solomon's Toolkit?) version 4.2 probably doesn't exist yet
  358. (the latest version I have seen is 4.19 beta), and the other two
  359. programs are rather bad (and old on the top of that).
  360.  
  361. 4) What is the reason of 9.? Does it contain this string? Does it
  362. display such message?
  363.  
  364. As a conclusion, it seems to be a new virus. I cannot tell more about
  365. it unless I get a copy of it.
  366.  
  367. Regards,
  368. Vesselin
  369. - -- 
  370. Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
  371. Tel.:+49-40-54715-224, Fax: +49-40-54715-226       Fachbereich Informatik - AGN
  372. ** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
  373. e-mail: bontchev@fbihh.informatik.uni-hamburg.de     D-2000 Hamburg 54, Germany
  374.  
  375. ------------------------------
  376.  
  377. Date:    12 Jun 92 10:53:54 +0000
  378. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  379. Subject: Re: SCAN vs. CLIPPER 5.0 (PC)
  380.  
  381. CEZAR@PLEARN.BITNET (Cezar Cichocki) writes:
  382.  
  383. > Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
  384. > for immunization. Immunized CLIPPER said me : 'Rules not found in file
  385. > CLIPPER.EXE', and didn't work correctly.
  386.  
  387. The reason is that when SCAN is run with this option (and with the /AV
  388. option as well), it adds some checksum information to the executable
  389. files. As I have always said IT IS A VERY BAD IDEA TO TOUCH OTHER
  390. PEOPLE'S FILES! The people at McAfee Associates are ignoring this and
  391. see what happens...
  392.  
  393. My advice is: NEVER use SCAN with those two options. They can be
  394. HARMFUL to your programs!
  395.  
  396. > When I reinstalling CLIPPER, all was right. I repeat it few times, and
  397. > my conclusion is : adding generic code to CLIPPER.EXE make it unusable
  398.  
  399. CLIPPER is not the only program that is sensitive to such
  400. modification. Any self-checking program (most anti-virus programs,
  401. that is) will moan if "immunized" this way. And program that contains
  402. debug information (that is, programs compiled with Borland's or
  403. Microsoft's C and Pascal compilers) will "lose" this information (that
  404. is, the debugger will not be able to see it), if it is "immunized"
  405. this way. And if you happen to run a third-party integrity checking
  406. product, it will report that a lot of executable files have been
  407. modified - probably by a virus... DON'T USES THESE OPTIONS OF SCAN!
  408. Don't let it modify your files!
  409.  
  410. Regards,
  411. Vesselin
  412. - -- 
  413. Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
  414. Tel.:+49-40-54715-224, Fax: +49-40-54715-226       Fachbereich Informatik - AGN
  415. ** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
  416. e-mail: bontchev@fbihh.informatik.uni-hamburg.de     D-2000 Hamburg 54, Germany
  417.  
  418. ------------------------------
  419.  
  420. Date:    12 Jun 92 11:39:40 +0000
  421. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  422. Subject: Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
  423.  
  424. doc@magna.com (Matthew J. D'Errico) writes:
  425.  
  426. > Several instances have been reported where this update reported
  427. > infections of the "Wonder-2" strain of the "Wonder" virus in
  428. > commercially distributed software...  These infections include files
  429. > from :
  430.  
  431. >     Borland C++ 3.0 (TOUCH.COM)
  432. >     Mavis Beacon Teaches Typing 2.0
  433. >     Stacker 2.0
  434. >     VCD.COM (from VCD.ZIP - shareware ?)
  435. >     Intermission 3.0 (IMSETUP.COM)
  436. >     SHEZ v7.1 (3 different files : SHEZCFG.COM, SGREG.COM and DUMPMAC.COM)
  437.  
  438. The reason of this is that the Wonder virus is written in a high level
  439. language - Turbo C++, if I remember correctly. If you are not careful
  440. enough when selecting a scan string, you may pick one from the
  441. standard libraries that are linked by the compiler. If you do this,
  442. then you'll "find" the virus in every program that is written in the
  443. same language and contains a call to the same library function.
  444. Obviously this is what happened to NAV.
  445.  
  446. Regards,
  447. Vesselin
  448. - -- 
  449. Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
  450. Tel.:+49-40-54715-224, Fax: +49-40-54715-226       Fachbereich Informatik - AGN
  451. ** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
  452. e-mail: bontchev@fbihh.informatik.uni-hamburg.de     D-2000 Hamburg 54, Germany
  453.  
  454. ------------------------------
  455.  
  456. Date:    12 Jun 92 11:45:11 +0000
  457. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  458. Subject: SCAN 91 has drastically changed the virus names used (PC)
  459.  
  460. Hello, everybody!
  461.  
  462. Warning: in SCAN version 91 McAfee associates have introduced several
  463. changes, which might cause very severe misunderstandings.
  464.  
  465. I have always said that SCAN is unreliable for virus identification -
  466. it is only good for detecting whether an object is infected at all or
  467. not; not for detecting with what it is infected exactly. However, with
  468. version 91 McAfee Associates have really messed the things up.
  469.  
  470. First, they have introduced a lot of two-letter virus names - like VD,
  471. V2, F2, etc. Needless to say, those viruses are not "documented" in
  472. VIRLIST.TXT. But this file has never been a good documentation of what
  473. SCAN detects... The problem is that some of the signatures for these
  474. viruses are probable to cause false positives... :-( As a general
  475. rule: if SCAN tells you that only ONE file on your computer is
  476. infected and reports a weird two- or three-character name, don't
  477. believe it - it's probably not a virus. Better use some other scanner
  478. to re-check the results.
  479.  
  480. Second, they have CHANGED the names of many of the old viruses that
  481. they report. For instance, W13 is reported as V2 [F2], some Vienna
  482. variants are reported as Family [FM], the Dark_Avenger.2000.* and
  483. Dark_Avenger.2100.* variants are reported as RKO [RKO], the Tiny
  484. viruses and the Dir.691 virus are both reported as Pif [Pif] (these
  485. two viruses have nothing in common), and many, many, others.
  486.  
  487. Third, they seem to have "optimized" some strings to be shorter, and
  488. to match as many viruses as possible, regardless how these viruses are
  489. named or whether they have something in common or not. As a result,
  490. there is a huge naming confusion introduced and the probability for
  491. false positives is higher. I suspect that this has been done to
  492. overcome some memory limitations, but I don't think that the solution
  493. used is acceptable.
  494.  
  495. The result is that when a user reports "I think that I have a virus;
  496. SCAN 91 reports it as XYZ", this contains almost no information - it
  497. might be a false positive, or the actual virus might be something
  498. completely different. Therefore, any virus-competent person who reads
  499. the report and is willing to help won't be able to understand what the
  500. user is speaking about. The net result is that the users are less
  501. protected and less likely to get correct information.
  502.  
  503. I strongly suggest to McAfee Associates to improve their virus
  504. identification (and reliable detection). Meanwhile I feel unable to
  505. provide any help to users who report a virus relying on the name that
  506. SCAN 91 has reported. I can only suggest them to use a better
  507. scanner...
  508.  
  509. Regards,
  510. Vesselin
  511. - -- 
  512. Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
  513. Tel.:+49-40-54715-224, Fax: +49-40-54715-226       Fachbereich Informatik - AGN
  514. ** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
  515. e-mail: bontchev@fbihh.informatik.uni-hamburg.de     D-2000 Hamburg 54, Germany
  516.  
  517. ------------------------------
  518.  
  519. Date:    12 Jun 92 10:38:19 +0000
  520. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  521. Subject: Re: ISPNews & Virx (PC)
  522.  
  523. 72461.3212@CompuServe.COM (Ross M. Greenberg) writes:
  524.  
  525. > That's what last-minute-before-the-release fiddling will getcha, alas.
  526. > We recently became aware of this, dangitall, and a new release that
  527. > catches 10,000 out of 10,000 of our test viruses will be released very
  528. > shortly.
  529.  
  530. As soon as it is available, I'll test it.
  531.  
  532. > >The files are not destroyed - they work perfectly and are able to
  533. > >spread the virus. However, since the decryptor is almost non-existent,
  534. > >it is very difficult to detect it... :-)
  535.  
  536. > I dunno, Vessilin: some of the above mentioned 10,000 viruses seem to
  537. > trash the productivity of the target file pretty nicely: after the
  538. > decryptor comes a whole bunch of NOP's, followed immediately by a
  539. > return.  The target program is never run, as an exit back to DOS seems
  540. > to preclude that pretty well.
  541.  
  542. Wait a minute. What do you mean by "some of the above mentioned 10,000
  543. viruses"? Do you have them? I have not sent them to you for sure, did
  544. you get them from Morton? Or are you speaking about a different (not
  545. ours) test set? Because I had a look at some of the non-detected files
  546. and they seem to be perfectly in order...
  547.  
  548. Meanwhile I got a report from Antony Naggs that the Pogue virus (one
  549. of the MtE-based viruses) sometimes produces corrupted variants. This
  550. is due to the fact that the virus is sloppily written, it is not a
  551. fault of the MtE. In our tests we used Fear mutations. Fear is the
  552. same as the Dedicated virus (the virus shipped in source with the MtE
  553. package) - just the text string is patched. I have never seen it to
  554. corrupt itself...
  555.  
  556. Regards,
  557. Vesselin
  558. - -- 
  559. Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
  560. Tel.:+49-40-54715-224, Fax: +49-40-54715-226       Fachbereich Informatik - AGN
  561. ** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
  562. e-mail: bontchev@fbihh.informatik.uni-hamburg.de     D-2000 Hamburg 54, Germany
  563.  
  564. ------------------------------
  565.  
  566. Date:    Wed, 10 Jun 92 20:26:32 +0000
  567. From:    guh@gdstech.grumman.com (john Guh)
  568. Subject: Help! Does anyone know about any known UNIX viruses? (UNIX)
  569.  
  570. A customer of mine is worried about computer virus on tapes which
  571. contained Timeplex`s application software to be loaded on a SUN
  572. SPARCstation.
  573.  
  574. Has anyone ever heard of computer virus on UNIX systems?  Are there
  575. any virus detection program for UNIX?
  576. - -- 
  577. ==================================================================
  578. John Guh                2411 Dulles Corner Park
  579. E-Mail:  guh@gdstech.grumman.com    Suite 500
  580. Phone:    (703) 713-4143    FAX: 713-4103    Herndon VA 22071
  581.  
  582. ------------------------------
  583.  
  584. Date:    Thu, 11 Jun 92 12:17:00 +0200
  585. From:    Homo homini lupus! <BAN@hdc.hha.dk>
  586. Subject: Teoretical questions
  587.  
  588. I hope you can help me with an answer to some question that have
  589. been bothering me:
  590.  
  591. 1) Having read some of F. Cohens work, I've seen many references to
  592. a POset. What is a POset?
  593.  
  594. 2) L. Adleman present a theorem (Theorem 3, p.366; Leonard Adleman: "An
  595. abstract theory of computer viruses", Lecture notes in Computer
  596. Science, vol.403, Springer 1990, pp. 354-374) stating:
  597.     ... if for all i in N, v(i)>=i then v is absolutely isolable.
  598. Can those of you, who have read Adlemans note explain to me, what is
  599. meant by ">=". Does it mean that one can detect every virus which does
  600. not shrink the infected program? And in what dimension is it to be
  601. measured? Cohens compressionvirus example make a program smaller in
  602. space, but as Cohen notes himself, it is a trade off between time and
  603. space, meaning that it will be larger on the runtime dimension. Can one
  604. then say from Adlemans theorem, that one cannot be certain to find such
  605. virus when checking space, but certain when measuring it on the time
  606. scale?
  607.  
  608. 3) Cohen notes a weakness in his defence model S3 (p. 155; Fred Cohen:
  609. "Models of Practical Defences Against Computer Viruses", Computers &
  610. Security, vol.8, no.2, s.149-160, 1989 ) - S3 is based on a checksum
  611. approch, which means that checksum( pi ) = checksum( pj ) for some
  612. programs pi and pj of a length greater than the checksum [my inter-
  613. pretation]. Relating that to the fact that most intregity checkers
  614. today is checksum based, and to the discussion considering MtE and
  615. 100% detection, isn't this a fundamental weakness in the checksumming
  616. concept.
  617.  
  618. 4) When using MtE to exploid the "not 100% detection weakness" of
  619. scan- ners, it would seem worthwhile to give one own mutation a higher
  620. proba- bility. This means, that if five programs survive the scanning
  621. in the first round, and each make say three times more copies of it
  622. self than of other permutation, it will mean approx. 20 will survive
  623. round two.  This is exponential growth rather than as before linear
  624. growth (of course this will not increase the chance of survival in a
  625. checksumbased check).
  626.  
  627. /BJARNE HOEGH NIELSEN (BAN@HDC.HHA.DK)
  628.  
  629. ------------------------------
  630.  
  631. Date:    Tue, 02 Jun 92 12:11:00 +1200
  632. From:    "Mark Aitchison, U of Canty; Physics" <PHYS169@csc.canterbury.ac.nz>
  633. Subject: Re: Taxonomy of viruses
  634.  
  635. >>virus' taxonomy from a scanner.  Because of this, I suspect that
  636. >>numerical taxonomy will give disappointing results in classifying
  637. >>viruses.  It will tend to consider viruses as very different which are
  638. >>simply rearranged or recoded versions of the same exact functional
  639. >>structure.
  640.  
  641. Well, the latest version of my freeware BOOTID program is now
  642. available for anyone interested, and it does seem to do a darned good
  643. job of putting viruses into groups (even if I do say so myself :-).
  644. Oddly enough, it also seems to spot 100% of new boot sector viruses,
  645. although that's not what it is designed to do.
  646.  
  647. The approach it takes is a combination of looking for constant
  648. characteristics between samples of the same and related viruses, plus
  649. looking for the slightest changes between samples - so the last three
  650. bytes tend to give a "family" name for viruses while the first eight
  651. are unique (except that changes in disk size, serial number, etc
  652. shouldn't change it, but generation counts do).
  653.  
  654. But is only works for boot sectors, and really only DOS ones at that
  655. (it recognises a lot of non-DOS diskettes, but isn't really effective
  656. in identifying viruses on them).  The present version still needs some
  657. work when it comes to partition tables - the heuristics section
  658. doesn't really distinguish well enough between good partition tables
  659. and viruses, in my opinion (not that it is supposed to be - the
  660. heuristics are only called in as a last resort if it cannot make a
  661. positive identification).
  662.  
  663. So if anyone would like to run the program over any new virus they
  664. think they have, or over a collection of BSI viruses, or help develop
  665. the code further, let me know...
  666.  
  667. Mark Aitchison, University of Canterbury, New Zealand.
  668.  
  669. Examples of hashcodes for viruses (and some good boot sectors as
  670. well); notice some vary slightly, perhaps due to different generation
  671. counters, manufacture's ID, or whatever...
  672.  
  673. #30B0M0S.D9# Tony_Boot virus! (ID="IBM  3.3")
  674. #30S4MZQ.D9# Tony_Boot virus! (ID="IBM  3.3")
  675. #200HP5Q.FF# Den_Zuko.3.B virus! (ID="I4<12><00><01><00><00><00>")
  676. #20IY6LP.3O0 DOS non-bootable (FDFORMAT)
  677. #30K4MYT.790 IBM PCDOS 3.30
  678. #2614HSU.A80 DOS non-bootable (Jandel) (ID="IBM 3.3")
  679. #30NOOJP.B90 PCDOS 2.0
  680. #201V4QV.BO0 DOS non-bootable (WATCOM )
  681. #206S54V.BO0 DOS non-bootable (PNCI)
  682. #20IS56P.BO0 DOS non-bootable (FDFORMAT)
  683. #20MU5SU.BO0 DOS non-bootable (Norton)
  684. #20N94NT.BO0 DOS non-nootable (ID=" Norton ")
  685. #20QR41R.BO0 Norton Utilities 5.0
  686. #40ZO4BR.BW0 DOS non-bootable (PC Tools)
  687. #20BCMQO.F90 Data General DOS 2.11 (for DG/One, etc)
  688. #305BK5P.F90 DOS 3.30 (ID="ReadRite") (MSDOS 3.30 with different manuf. ID)
  689. #305BKPU.F90 IBM PCDOS 3.30 (used on Verbatim pre-formatted diskettes)
  690. #305BKRS.F90 MSDOS 3.30
  691. #30CEM4T.F90 MSDOS 3.2
  692. #30CEM8P.F90 DOS for Data General DG/One, etc ("DGC 3.20")
  693. #30X5MGU.F90 MSDOS 3.2
  694. #4GM0S2P.F90 DRDOS 6.0
  695. #4GTBSMS.F90 DRDOS 5.0 (06/90 or 08/90)
  696. #4K0WN4S.F90 DRDOS 5.0 (2/91 Business Update)
  697. #4OQSUHU.F90 DRDOS 6.0 (08/91 or 12/91)
  698. #40LIOQU.V90 IBM PCDOS 4.0
  699. #40LIOWO.V90 MSDOS 4.0
  700. #4HUIM5Q.V90 MSDOS 5.0
  701.  
  702. [Moderator's note: I deleted the remaining 250+ lines of hash codes
  703. for the sake of keeping the posting relatively short.  If there is
  704. sufficient interest, I can e-mail out the entire list or place it on
  705. our anonymous FTP archive.  Drop me a note if you want it, and I'll
  706. either reply with the complete text, or announce its availability on
  707. the archive.]
  708.  
  709. ------------------------------
  710.  
  711. Date:    Tue, 09 Jun 92 22:50:56 -0700
  712. From:    rslade@sfu.ca (Robert Slade)
  713. Subject: Fred Cohen (CVP)
  714.  
  715. HISINT3.CVP   920609
  716.                              Fred Cohen
  717.  
  718. No historical overview of viral programs can be complete without
  719. mention of the work of Fred Cohen.
  720.  
  721. Hi Fred.
  722.  
  723. (Just kidding.)
  724.  
  725. In the early 1980s, Fred Cohen did extensive theoretical research, as
  726. well as setting up and performing numerous practical experiments,
  727. regarding viral type programs.  His dissertation was presented in
  728. 1986 as part of the requirements for a doctorate in electrical
  729. engineering from the University of Southern California.  This work is
  730. foundational, and any serious student of viral programs disregards it
  731. at his own risk.
  732.  
  733. (Dr. Cohen's writings are available for purchase from:
  734. ASP Press
  735. PO Box 81270
  736. Pittsburgh, PA    15217
  737. USA)
  738.  
  739. Dr. Cohen's definition of a computer virus as "a program that can
  740. 'infect' other programs by modifying them to include a ... version of
  741. itself" is generally accepted as a standard.  On occasion it presents
  742. problems with the acceptance of, say, boot sector viral programs and
  743. entities such as the Internet/UNIX/Morris worm.  However, his work
  744. did experimentally demonstrate and theoretically prove many vital
  745. issues.
  746.  
  747. I cannot, in one column, describe the sum total of his work.  In my
  748. opinion, the most important aspects are the demonstration of the
  749. universality of risk, and the limitations of protection.  His
  750. practical work proved the technical feasibility of a viral attack in
  751. any computer system environment.  (This feat was achieved within a
  752. closed environment and could not, by its nature, have predicted the
  753. social and psychological factors which have contributed to the
  754. pandemic spread of viral programs "in the wild".)  Equally important,
  755. his theoretical study proved that the "universal" detection of a
  756. virus is undecidable.  Although monitoring and analytical programs
  757. have a place in the antiviral pantheon, this fact means that they,
  758. and, in fact, all other antiviral software, can never give 100%
  759. guaranteed protection.  Without this early work, it is likely that
  760. some toilers in the antiviral vineyards would still be pursuing that
  761. elusive grail.
  762.  
  763. copyright Robert M. Slade, 1992   HISINT3.CVP   920609
  764.  
  765. ==============
  766. Vancouver      ROBERTS@decus.ca         | "Is it plugged in?"
  767. Institute for  Robert_Slade@sfu.ca      | "I can't see."
  768. Research into  rslade@cue.bc.ca         | "Why not?"
  769. User           CyberStore Dpac 85301030 | "The power's off
  770. Security       Canada V7K 2G6           |  here."
  771.  
  772. ------------------------------
  773.  
  774. Date:    Thu, 11 Jun 92 12:38:34 -0700
  775. From:    rslade@sfu.ca (Robert Slade)
  776. Subject: PC pranks and trojans (CVP)
  777.  
  778. HISINT4.CVP   920609
  779.  
  780.                          Pranks and trojans
  781.  
  782. Pranks are very much a part of the computer culture.  So much so,
  783. that one can now buy commercially produced joke packages which allow
  784. you to perform "Stupid Mac (or PC) Tricks".  There are numberless
  785. pranks available as shareware.  Some make the computer appear to
  786. insult the user, some use sound effects or voices, some use special
  787. visual effects.  A fairly common thread running through most pranks
  788. is that the computer is, in some way, non-functional.  Many pretend
  789. to have detected some kind of fault in the computer (and some pretend
  790. to rectify such faults, of course making things worse).  One recent
  791. entry in our own field is PARASCAN, the paranoid scanner.  It tends
  792. to find large numbers of very strange viral programs, none of which,
  793. oddly, have ever appeared in the CARO index.  Aside from temporary
  794. aberrations of heart rate and blood pressure, pranks do no damage.
  795.  
  796. I would not say the same of trojans.  I distinguish between a prank
  797. and a trojan on the basis of intent to damage.  The Trojan Horse was
  798. the gift with betrayal inside; so a trojan horse program is an
  799. apparently valuable package with a hidden, and negative, agenda.
  800.  
  801. Trojans are sometimes also referred to (less so now than in the past)
  802. as "arf arf" programs.  One of the first was distributed as a program
  803. the would enable graphics on early TTL monitors.  (That *should* have
  804. been a giveaway: such an operation was impossible.)  When run, it
  805. presented a message saying "Gotcha.  Arf, arf." while the hard drive
  806. was being erased.
  807.  
  808. Trojan programs are spread almost entirely via public access
  809. electronic bulletin boards.  Obviously, a damaging program which can
  810. be identified is unlikely to be distributed through a medium in which
  811. the donor can be identified.  There are, as well, BBSes which are
  812. definitely hangouts for software pirates, and act as distribution
  813. points for security breaking tips and utilities.  These two factors
  814. have led to a confusion of trojan programs, viral programs and
  815. "system crackers" which has proven extremely resistant to correction. 
  816. It has also led to a view of BBSes as distribution points for viral
  817. programs.  (Recently our local "tabloid" paper's computer columnist,
  818. normally better versed than this, dismissed the availability of
  819. antiviral software to combat Michelangelo by saying that no self
  820. respecting company would ever use a BBS.)  This in spite of the fact
  821. that the most successful viral programs, boot sector infectors,
  822. cannot be transmitted over BBS systems, at least not without
  823. sophisticated intervention (generally at both ends of the transfer.)
  824.  
  825. copyright Robert M. Slade, 1992   HISINT4.CVP   920609
  826.  
  827. ==============
  828. Vancouver      ROBERTS@decus.ca         | "Don't buy a
  829. Institute for  Robert_Slade@sfu.ca      |     computer."
  830. Research into  rslade@cue.bc.ca         | Jeff Richards'
  831. User           CyberStore Dpac 85301030 | First Law of
  832. Security       Canada V7K 2G6           | Data Security
  833.  
  834.  
  835. ------------------------------
  836.  
  837. Date:    Mon, 15 Jun 92 10:37:12 -0700
  838. From:    Richard W. Lefkon <dklefkon@well.sf.ca.us>
  839. Subject: Call For Papers: 6th Annual Virus Conference
  840.  
  841. CALL FOR PAPERS:  6TH INTERNATIONAL
  842.                   COMPUTER VIRUS & SECURITY CONFERENCE
  843.  
  844.                   MARCH 10-12, 1993, NEW YORK RAMADA AND MARRIOTT MARQUIS
  845.   
  846.                   sponsored by DPMA Financial Industries Chapter in cooperation with
  847.                   ACM-SIGSAC, BCS, CMA, COS, Computerworld, EDPAA-PH, ISSA-NY
  848.                       and IEEE-CS
  849.  
  850.  
  851. Approximately 500 attendees will hear 90 speakers and 53 vendors over the 3 days.
  852.  
  853. YOUR AUDIENCE:  Past attendees have represented industry, military, 
  854.                 government, forensic and academic settings -
  855.                 creators and users of related software and hardware.
  856.  
  857.                 They travel from the U.S. and many international locations
  858.                 and have titles such as MIS Director, Security Analyst,
  859.                 Operations Manager, Investigator, Programming Leader
  860.  
  861. TOPICS OF INTEREST INCLUDE (but are not limited to):
  862.  
  863.                 - Prevention, detection, and recovery from viruses and
  864.                           other unauthorized usage
  865.                 - Original research on this and related topics.
  866.                 - survey of products and techniques available.
  867.                 - Particulars of LAN, UNIX, cryptography, military use
  868.                 - Computer crime, law, data liability, related contexts
  869.                 - US/international sharing of research & techniques
  870.                 - Case studies of mainframe, PC &/or network security, e.g.,
  871.                      - Chicago flooding recovery
  872.                      - 1992 fire and other natural disaster recovery
  873.                      - Recent court decisions
  874.                      - Security implementation and user awareness in industry
  875.  
  876. PAPER SUBMISSION:
  877.  
  878.                 Send a draft final paper for receipt by Wednesday, 12/18/92.
  879.                 Address to Judy Brand, Conference Chair, Box 6313 FDR Station,
  880.                 New York, NY 10150, USA.  Please include a small photo and
  881.                 introductory bio not exceeding 50 words.  Successful submitters
  882.                 or co-authors are expected to present in person.  Presenters
  883.                 receive the Conference Proceedings.
  884.  
  885. PAPER FORMAT:   Send one original and three copies.  When making the copies,
  886.                 please cover over the author name(s) and other identifying
  887.                 data.  Each paper goes to three reviewers.
  888.  
  889.                 Type double spaced, with page# below bottom line (may be
  890.                 handwritten):  TITLE (caps); Name; Position, Affiliation;
  891.                 Telephone, City/State/Zip, Electronic Address (optional).
  892.  
  893.                 Begin with a brief abstract not exceeding 200 words.
  894.  
  895. NOTIFICATION:   Written and (where practicable) telephoned confirmation will
  896.                 be initiated by Monday, 1/13/93, to facilitate low cost
  897.                 travel.  Those needing earlier notification should submit
  898.                 papers sooner and attach a note to this effect.
  899.  
  900.                 You may be asked to perform specific revisions to be accepted.
  901.                 Nobody can guarantee you a place without an acceptable paper.
  902.  
  903. AT THE CONFERENCE:  There are five tracks.  Time your presentation to last
  904.                 40 minutes and have clear relation to your paper.  A committee
  905.                 member will preside over your assigned room and adhere to schedule.  
  906.                 Don't hesitate to submit a presentation you've given elsewhere
  907.                 to a more specialized audience.  Most attendees will find it
  908.                 new - and necessary.  On-site schedule is duplicated early
  909.                 on first day.  If you may have a work emergency you can
  910.                 reschedule or substitute your co-author.
  911.  
  912. ------------------------------
  913.  
  914. End of VIRUS-L Digest [Volume 5 Issue 117]
  915. ******************************************
  916.  (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC 
  917. Downloaded From P-80 International Information Systems 304-744-2253
  918.