home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / v / vl6-026.zip / VL6-026.TXT < prev   
Internet Message Format  |  1993-02-17  |  54KB

  1. Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
  2.     id AA00419; Tue, 16 Feb 1993 18:22:17 +0100
  3. Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA05065
  4.   (5.67a/IDA-1.5 for <mikael@abacus.hgs.se>); Tue, 16 Feb 1993 11:35:33 -0500
  5. Date: Tue, 16 Feb 1993 11:35:33 -0500
  6. Message-Id: <9302161550.AA23100@first.org>
  7. Comment: Virus Discussion List
  8. Originator: virus-l@lehigh.edu
  9. Errors-To: krvw@first.org
  10. Reply-To: <virus-l@lehigh.edu>
  11. Sender: virus-l@lehigh.edu
  12. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  13. From: "Kenneth R. van Wyk" <krvw@first.org>
  14. To: Multiple recipients of list <virus-l@lehigh.edu>
  15. Subject: VIRUS-L Digest V6 #26
  16. Status: RO
  17.  
  18. VIRUS-L Digest   Tuesday, 16 Feb 1993    Volume 6 : Issue 26
  19.  
  20. Today's Topics:
  21.  
  22. First digest from new address
  23. Re: Sale of Viri
  24. Re: Undecidability (was: On the definition of viruses)
  25. Re: virus-definitions
  26. Re: Virus education
  27. Re: What is a virus ?
  28. Re: general entertainment
  29. Gender switching virus
  30. my idea for detecting file infectors
  31. Re: Norton buggy??? (or I have a PROBLEM!) (PC)
  32. Michelangelo (oh noooooo) (PC)
  33. Re: PKZIP 2'S AV is cracked (PC)
  34. Re: STONED, Scanv99/Clean 99 Questions/Concerns (PC)
  35. Re: Twelve Tricks (PC)
  36. Re: Virstop 2.07 in Icelandic (PC)
  37. Re: Vshield vs Virstop (PC)
  38. STONED in Memory (PC)
  39. Re: Help! Help, with FORM virus (PC)
  40. Jeruslem variant (PC)
  41. Tokyo Virus in NETCB or a false positive? (PC)
  42.  
  43. VIRUS-L is a moderated, digested mail forum for discussing computer
  44. virus issues; comp.virus is a non-digested Usenet counterpart.
  45. Discussions are not limited to any one hardware/software platform -
  46. diversity is welcomed.  Contributions should be relevant, concise,
  47. polite, etc.  (The complete set of posting guidelines is available by
  48. FTP on cert.org or upon request.) Please sign submissions with your
  49. real name.  Send contributions to VIRUS-L@LEHIGH.EDU.  Information on
  50. accessing anti-virus, documentation, and back-issue archives is
  51. distributed periodically on the list.  A FAQ (Frequently Asked
  52. Questions) document and all of the back-issues are available by
  53. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  54. (comments, suggestions, and so forth) should be sent to me at:
  55. <krvw@FIRST.ORG>.
  56.  
  57.    Ken van Wyk, krvw@first.org
  58.  
  59. ----------------------------------------------------------------------
  60.  
  61. Date:    Tue, 16 Feb 93 10:38:57 -0500
  62. >From:    "Kenneth R. van Wyk" <krvw@first.org>
  63. Subject: First digest from new address
  64.  
  65. This is the first digest that I'm sending from krvw@first.org.
  66. Hopefully, all will go well.  If things do break, however, please bear
  67. with me.
  68.  
  69. With fingers crossed,
  70.  
  71. Ken
  72.  
  73. Kenneth R. van Wyk
  74. Moderator VIRUS-L/comp.virus
  75. krvw@FIRST.ORG      (Moderator account)
  76. ken@THANG.PGH.PA.US (home - until I've relocated to DC)
  77.  
  78. ------------------------------
  79.  
  80. Date:    12 Feb 93 14:37:07 +0000
  81. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  82. Subject: Re: Sale of Viri
  83.  
  84. rikardur@rhi.hi.is (Rikhardur Egilsson) writes:
  85.  
  86. > There seems to be continous 'fright-propaganda' about viruses and the 
  87. > idea is to let people think "viruswriter = criminal"
  88.  
  89. Most people think that virus writing is so damaging to the society,
  90. that it should be criminal.
  91.  
  92. > I don't remember what group it was but someone posted a request resently
  93. > for virus-code.
  94.  
  95. It was cross-posted to several non-moderated newsgroups, one of them was
  96. comp.security.misc.
  97.  
  98. > In short 'hell broke loose' almost anyone reading the posting seemed to
  99. > belive he was going to use that code for evil purposes.
  100.  
  101. The way the message was constructed showed a low level of competence
  102. of the person who posted it. Providing viral code to people who are
  103. not competent enough to handle it properly is harmful.
  104.  
  105. > It seemes impossible for those interested, to get the code/data for viruses.
  106.  
  107. No, because as you are admitting yourself:
  108.  
  109. > As widespread as Viruses have come it does not take a long time to create
  110. > the source for, let's say, 1704 bytes virus and comment it to the point
  111. > that there is no trace of the source-code-generator.
  112.  
  113. Thus, if somebody is really interested, there is no problem for them
  114. to obtain a few widespread viruses. Gosh, they just have to take a
  115. scanner and to look on the computers around. According to some
  116. statistics, about one in every 400 computers gets infected at least
  117. once in a year. Some environments (e.g., academia) are more
  118. prolificient for viruses to spread than others (e.g., banks, military,
  119. etc.).
  120.  
  121. > Of course that does not surprice me, as I know what most people think of
  122. > viruses and that there would always be someone to misuse that. 
  123.  
  124. ..Or not to be able to handle them properly. There are so many cases
  125. of virus code being misused and so many people that are not competent
  126. to handle virus code properly, that when somebody posts a virus
  127. request it is very probable that s/he belongs to one of these
  128. categories. Besides, if one is competent enough, s/he could find some
  129. viruses "from the field", instead of posting silly requests to the
  130. newsgroups.
  131.  
  132. > On the other hand it shouldn't be that strange that someone offered to sell
  133. > the code/data to whoomever is interested.
  134.  
  135. Yes, it is not strange at all. There are always unethical people who
  136. are determined to use any weaknesses in the law to make money,
  137. regardless what will this cost to the society.
  138.  
  139. > In short : do viruses realy have to be that 'taboo'
  140. > Informing people about them and how they work and even distribute simple
  141. > samples could be just as effective as the fright-propaganda.
  142.  
  143. Informing people about them and how they work is OK. I am trying to do
  144. this all the time here and some people even accuse me to be "too
  145. open". However, "distributing simple samples" is a no-no. Believe me,
  146. I know it from my own bitter experience. Long time ago, when a virus
  147. first appeared in Bulgaria (it was the Vienna virus), I distributed a
  148. diskette with the virus, explanation of how it works and what it does,
  149. and an anti-virus program for it. Just like you, I meant well - to
  150. educate people that viruses are not "black magic", that they are
  151. simple programs and here is what they look like, what they do, and how
  152. to fight them. The result was sad - instead of reading my
  153. explanations, people used to just "try" all programs on the diskette,
  154. including the infected one...
  155.  
  156. Remember, most users are incompetent to handle virus code properly.
  157. And, because a virus is able to spread by itself, an incompetent
  158. person who -knows- that s/he has virus code could (involuntarily)
  159. infect other innocent and incompetent people, who even do not know
  160. that they are infected. No, distributing viruses, except under very
  161. strict conditions, and to a very restricted set of knowledgeable
  162. anti-virus experts is a VERY WRONG THING and must NEVER be done, for
  163. whatever purpose. Never.
  164.  
  165. Please, believe my own experience - this will save you a bitter
  166. disappointment...
  167.  
  168. > Then Stealth-viruses came along and that tecnology excited me.
  169. > But as I learned more about them and how they work the 'miracle' tag
  170. > dropped off.
  171.  
  172. But it was enough that you were explained how they work, right? It
  173. wasn't necessary to give you a live virus?
  174.  
  175. > anything new.  I got issue 1 of CVDQ and there virus there shows me that
  176. > poople have to spent anourmous time to make a virus that is going to
  177. > have a faint-change of surviving in the modern-world. 
  178.  
  179. Uh, sorry, what is CVDQ?
  180.  
  181. > I guess that most of those who do write viruses and release them wouldn't 
  182. > if they knew better.  They probably think that they're adding new variants
  183. > to a pool of a couple of viruses and that a lottsa people are going to 
  184. > see and inspect/admire there code.
  185.  
  186. It depends. There are all kinds of people. Some of them are blissfully
  187. ignorant, as you suspect. Others are doing it "for kicks", to prove to
  188. their adolescent minds that they are "something" by opposing
  189. themselves to the established values of the society. Others are just
  190. vandals, who like the thought that they will destroy somebody's data.
  191. Others feel "happy" when they read in the newspaper about "their"
  192. virus, or when they learn that a popular scanner is able to handle
  193. "their" virus.
  194.  
  195. For more information about how one such twisted mind reasons, you
  196. could read the interview with Dark Avenger by Sara Gordon in "Virus
  197. News International", January and February (and probably March) issues.
  198. He literally says "When I saw that McAfee's SCAN was able to detect my
  199. virus, I was almost happy"...
  200.  
  201. Regards,
  202. Vesselin
  203. - -- 
  204. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  205. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  206. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  207. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  208.  
  209. ------------------------------
  210.  
  211. Date:    12 Feb 93 15:30:56 +0000
  212. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  213. Subject: Re: Undecidability (was: On the definition of viruses)
  214.  
  215. RADAI@vms.huji.ac.il (Y. Radai) writes:
  216.  
  217. > Perhaps we mean different things by "undecidable".  Maybe you mean
  218. > undecidable by *any* means, appearance *or* behavior.  I claim that if
  219. > one chooses definition (c), and if <condition> is something which is
  220. > sometimes satisfied and sometimes not (e.g., if it is "x < y" where x
  221. > and y are numbers supplied at runtime by the user), then the question
  222. > whether the program is a virus is obviously undecidable *BY APPEARANCE
  223. > ALONE*, even on a *finite* machine.
  224.  
  225. It seems to me that your claim is wrong. On a *finite* machine the
  226. size of x and y is *finite*, therefore the total number of
  227. combinations of values for x and y is also *finite*. Thus, you can
  228. (theoretically) list them all and say that for those of them the
  229. program is a virus, while for others it is not. Therefore, the
  230. problem, as stated by you -is- solvable (theoretically) on a *finite*
  231. machine.
  232.  
  233. > As I mentioned above, the "x < y" case with definition (c) is undecid-
  234. > able by *appearance alone*, even on a finite machine.
  235.  
  236. Nope, on a finite machine it is solvable.
  237.  
  238. Regards,
  239. Vesselin
  240. - -- 
  241. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  242. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  243. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  244. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  245.  
  246. ------------------------------
  247.  
  248. Date:    12 Feb 93 15:42:03 +0000
  249. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  250. Subject: Re: virus-definitions
  251.  
  252. KARGRA@GBA930.ZAMG.AC.AT writes:
  253.  
  254. > I was and am still missing the point wether a piece of software is necessary
  255. > for a user to do what he wants or not. If we add this question to the last
  256. > definition of Vesselin, then Diskcopy will not show up as virus, as it is
  257. > necessary to use this program to copy a floppy.
  258.  
  259. Won't help, because:
  260.  
  261. 1) There are a couple of viruses that ask the user for permission
  262. before infecting the next object.
  263.  
  264. 2) It is possible to make a bootable diskette with DOS, Diskcopy, and
  265. the proper AUTOEXEC.BAT file that will try to copy the diskette to all
  266. accessible drives, without asking for permission, just when you boot
  267. from it. What will be the virus in this case - Diskcopy, DOS,
  268. AUTOEXEC.BAT, or the whole diskette?
  269.  
  270. Regards,
  271. Vesselin
  272. - -- 
  273. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  274. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  275. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  276. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  277.  
  278. ------------------------------
  279.  
  280. Date:    Fri, 12 Feb 93 19:04:46 +0000
  281. >From:    mechalas@expert.cc.purdue.edu (John Mechalas)
  282. Subject: Re: Virus education
  283.  
  284. CHIP@BDSO.Prime.COM (Chip Seymour) writes:
  285. >BTW, all the talk over the definition of a virus is ok, but how do I
  286. >apply that to the protection of my work here? The viruses themselves
  287. >don't care - they just do what they're told.
  288.  
  289. Yes, but it's the anti-virus software that needs to have a working
  290. definition.  Scanners are an ever-weakening defense, and it is
  291. necessary to develop other means of protecting the computer from
  292. infection.  Heuristic methods rely on a a series of algorithms which
  293. are designed to analyze instructions for virus-like behavior.  Without
  294. a proper virus definition, there is a danger of false positives and
  295. (worse yet) false negatives.
  296.    I could write a program, for example, that interrupts all I/O
  297. access to the hard drive.  This simple, and stupid, program indirectly
  298. uses the definition of "a virus is any program that writes to my hard
  299. drive" or something similar.  Obviously, this would be a silly idea,
  300. born out from a silly definition.  Without a precise definition, it is
  301. difficult to analyze code and accurately determine whether or not a
  302. virus actually exists.
  303.  
  304. - -- 
  305. John Mechalas                    \ If you think my opinions are Purdue's, then
  306. mechalas@expert.cc.purdue.edu     \     you vastly overestimate my importance.
  307. Purdue University Computing Center \         Stamp out and abolish redundancy.
  308. General Consulting                  \                    #include disclaimer.h
  309.  
  310. ------------------------------
  311.  
  312. Date:    Fri, 12 Feb 93 23:26:52 +0000
  313. >From:    tegra!vail@uunet.UU.NET (Johnathan Vail)
  314. Subject: Re: What is a virus ?
  315.  
  316. I came into this late and really don't want to get involved too deep
  317. since I probably will miss the original point.  But this is a good
  318. time to repost my glossary.  To keep any relevence to this thread I
  319. copied the definitions of virus and worm at the beginning.
  320.  
  321.  
  322. virus - a piece of code that is executed as part of another program
  323.     and can replicate itself in other programs.  The analogy to real
  324.     viruses is pertinent ("a core of nucleic acid, having the ability to
  325.     reproduce only inside a living cell").  Most viruses on PCs really are
  326.     viruses.
  327.  
  328.  
  329. worm - An autonomous program (or set of programs) that can replicate
  330.     itself, usually over a network.  A worm is a complete program by
  331.     itself unlike a virus which is either part of another program or
  332.     requires another program's thread of execution to operate.  Robert
  333.     Morris's program, the Internet Worm, is an example of a worm although
  334.     it has been mistakenly identified in the popular media as a virus.
  335.  
  336.  
  337. jv
  338.  _____
  339. |     | Johnathan Vail     vail@tegra.com     (508) 663-7435
  340. |Tegra| jv@n1dxg.ampr.org    N1DXG@448.625-(WorldNet)
  341.  -----  MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)
  342.  
  343. ________________________________________________________________________
  344.  
  345.  
  346.           Glossary of Computer Insecurity
  347.  
  348.          Compiled by Johnathan Vail (vail@tegra.com)
  349.  
  350.  
  351. This list started out as a collection of a few computer virus related
  352. terms that I wrote for discussion in comp.virus.  Several people have
  353. contributed comments and suggestions to my original list.  Tom
  354. Zmudzinski contributed an excellent list of computer security terms
  355. that now form the bulk of this list.  At this time, I will serve as
  356. the focus and maintainer of this list.  Please submit any comments and
  357. additions to me.  My address is vail@tegra.com.
  358.  
  359.  
  360.  
  361.  
  362. HISTORY:
  363.  
  364.     12 Feb 1993 JV    - Update compiled changes.
  365.     20 Dec 1991 JV    - Tweaked some words.
  366.      6 Aug 1991 JV    - First release.
  367.  
  368.  
  369. ________________________________________________________________________
  370.  
  371.  
  372. async interrupt (attack) - to exploit system vulnerabilities arising
  373.     from deficiencies in the interrupt management facilities of an
  374.     operating system.
  375.  
  376.  
  377. back door - This is an undocumented feature added to a product which
  378.     can allow those who know about it to gain access to features that are
  379.     otherwise protected.  The original Tempest video game was supposed to
  380.     have a key sequence that would allow the author of the firmware to get
  381.     free games in an arcade.  Some military systems are rumored to have
  382.     back doors in their software that prevents their being used against
  383.     the countries that built them.
  384.  
  385.  
  386. blivet (attack) - A denial-of-service attack performed by hogging
  387.    limited resources that have no access controls (for example, shared
  388.    spool space on a multi-user system). [Classically defined as "ten pounds
  389.     of horsesh*t in a five pound bag".]
  390.  
  391.  
  392. browsing - Gaining unauthorized read-only access to files.
  393.  
  394.  
  395. C2 Catch-22  - Refers to the paradox that all federal computers are
  396.     required to be certified to the C2 level of Trust (or better) by 1992
  397.     (especially if they are to be permitted access to a network), yet
  398.     because no C2 certification has ever been performed with the network
  399.     software active, NSA will revoke the certification of any system as
  400.     soon as it is connected to a network.  [Also "C2-by-'92 Catch-22".]
  401.  
  402.  
  403. cascading - To gain additional privileges on a host (or within a
  404.     process) by using those privileges legitimately (if perhaps unwisely)
  405.     granted to casual users.
  406.  
  407.  
  408. crayola books - A disparaging reference to the "rainbow books",
  409.     commonly used when referring to the upcoming rewrite of NSA's
  410.     technical computer security guidelines.
  411.  
  412.  
  413. crypt (attack) - Stealing the system password file and looking for
  414.     known encrypted passwords.
  415.  
  416.  
  417. data diddling - To alter another's data (especially, to do so subtly
  418.     so it will not be detected); a major breach of the hacker ethic.
  419.  
  420.  
  421. denial-of-service attack - Any method which an intruder might use to injure
  422.    authorized users of a system by making its facilities unavailable.  Often
  423.    easier to accomplish than hijacking a privileged account.
  424.  
  425.  
  426. dictionary (attack) - Trying a dictionary of commonly used or vendor
  427.     installed passwords.
  428.  
  429.  
  430. Easter Egg - This is a usually benign feature added to a product by
  431.     the programmer without official knowledge or consent.  One example of
  432.     the is the 'xyzzy' command in Data General's AOS operating system.
  433.     Another is the "RESIST THE DRAFT" message in an unused sector of Apple
  434.     Logo.
  435.  
  436.  
  437. ethical hacker - Someone who espouses the view that he/she may
  438.     "ethically" penetrate any computer or network so long as no data is
  439.     altered.  [Colloquially among computer security professionals: a dead
  440.     hacker (or one who has ceased hacking).]
  441.  
  442.  
  443. leapfrog (attack) - Using userid and password information obtained
  444.     illicitly from one host (e.g., downloading a file of account IDs and
  445.     passwords, tapping TELNET, etc.) to compromise another host.  Also, to
  446.     TELNET through one or more hosts in order to confuse a trace (standard
  447.     cracker procedure).
  448.  
  449.  
  450. masquerading - To assume the identity of another user to gain
  451.     unauthorized access to a host or network.
  452.  
  453.  
  454. mockingbird - Software that intercepts communications (especially
  455.     logon processes) between users and hosts and provides system-like
  456.     responses to the users while obtaining information (especially account
  457.     IDs and passwords).
  458.  
  459.  
  460. pest - A set of instructions that self-replicates uncontrollably,
  461.     eventually rendering a network or system unusable via a
  462.     blivet attack. [sometimes called "wabbits"]
  463.  
  464.  
  465. phage - An autonomous program that inserts malicious code into
  466.     other autonomous programs (e.g., a computer worm or probe
  467.     that carries a virus or trojan horse program).
  468.  
  469.  
  470. polymorphic virus - 1. A virus using variable encryption with a
  471.     variable decryption routine to avoid detection by its
  472.     "signature".  V2P6, Whale, Maltese, Amoeba, Russian Mutant
  473.     and PC-Flu 2 are examples. 2. Any virus that changes it's
  474.     behaviour such as infect different types of host or change
  475.     their mode of operation.  A virus that infects both .COM and
  476.     .EXE programs as well as boot sectors can be considered
  477.     polymorphic.
  478.  
  479.  
  480. probe - A non-self-replicating, autonomous program (or set of
  481.     programs) that has the ability to execute indirectly
  482.     through a network or multi-partition computer system 
  483.     (e.g., various hacker utilities).
  484.  
  485.  
  486. rainbow books - NSA's technical computer security guidelines.  
  487.     So named because each of the books is published with a
  488.     different color cover.  [See "crayola books".]
  489.  
  490.  
  491. scavenging - To exploit unerased residual data.  The controversy with
  492.     the Prodigy [users finding pieces of the their data in the
  493.     STAGE.DAT file] service is an alleged example of this.
  494.  
  495.  
  496. spoofing - An attack which relies on the inability of users or computer
  497.    systems to verify the identity or location of a communication partner.
  498.    A `mockingbird' spoofs the computer's login sequence to fool a user;
  499.    some cracking software repeatedly spoofs human login actions to fool the
  500.    computer.
  501.  
  502.  
  503. stealth virus - A type of virus that attempts to hide its existence.
  504.     A common way of doing this on IBM PCs is for the virus to hook
  505.     itself into the BIOS or DOS and trap sector reads and writes that
  506.     might reveal its existence.
  507.  
  508.  
  509. trapdoor - A method of bypassing a sequence of instructions, often
  510.     some part of the security code (e.g. the computer logon).
  511.  
  512.  
  513. time bomb - This is code or a program that checks the systems clock in
  514.     order to trigger its active symptoms.  The popular legend of the time
  515.     bomb is the programmer that installs one in his employer's computers
  516.     to go off in case he is laid off or fired.
  517.  
  518.  
  519. trojan (horse) - This is some (usually nasty) code that is added to,
  520.     or in place of, a harmless program.  This could include many viruses
  521.     but is usually reserved to describe code that does not replicate
  522.     itself.
  523.  
  524.  
  525. unknown system-state (attack) - To exploit the conditions that occur
  526.     after a partial or total system crash (e.g., some files remain open
  527.     without an end-of-file condition allowing an intruder to obtain
  528.     unauthorized access to other files by reading beyond the real EOF when
  529.     service is resumed).
  530.  
  531.  
  532. virus - a piece of code that is executed as part of another program
  533.     and can replicate itself in other programs.  The analogy to real
  534.     viruses is pertinent ("a core of nucleic acid, having the ability to
  535.     reproduce only inside a living cell").  Most viruses on PCs really are
  536.     viruses.
  537.  
  538.  
  539. worm - An autonomous program (or set of programs) that can replicate
  540.     itself, usually over a network.  A worm is a complete program by
  541.     itself unlike a virus which is either part of another program or
  542.     requires another program's thread of execution to operate.  Robert
  543.     Morris's program, the Internet Worm, is an example of a worm although
  544.     it has been mistakenly identified in the popular media as a virus.
  545.  
  546. ________________________________________________________________________
  547.  
  548.  
  549. ------------------------------
  550.  
  551. Date:    Fri, 12 Feb 93 20:07:24 -0500
  552. >From:    Ian Leitch <I.LEITCH@lshtm.ac.uk>
  553. Subject: Re: general entertainment
  554.  
  555. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  556. > kelty_h@aci_1.aci.ns.ca (KELTY HAMILTON) writes:
  557.  
  558. > >  Just mentioning a good virus article in the February "Discover"
  559. > > magazine.  Thought you virus fanatics would be interested in its coverage
  560. > > of virus origins.
  561.  
  562. > This so-called article is in fact one chapter of the book "Approaching
  563. > Zero" by Bryan Clough and Paul Mungo. They are calling it "forthcoming
  564. > book" which sounds rather surprising to me - it was published in the
  565. > UK about one year ago and I have read it since a long time...
  566.  
  567. > The book is not just about viruses, it is about computer crime in
  568. > general. It's a very entertaining reading and I recommend it.
  569. > Unfortunately, it is also full of technical and factual mistakes. In
  570. > fact, every story described there, for which I know how it actually
  571. > happened, there is something misrepresented in the book. In several
  572. > cases I know that the declination of the truth is deliberate, because
  573. > it was me who has told the authors some of the facts and they are
  574. > represented differently in the book...
  575.  
  576. > The article is "Discover" does not make an exception - lots of
  577. > technical and factual details are wrong. Maybe the funniest of them is
  578. > the conjecture that "Diana P." in Dark Avenger's viruses has something
  579. > to do with Lady Diana, Princess of Wells. However, the general
  580. > analysis of the situation in Bulgaria that leaded to the creation of
  581. > so many viruses there is rather exact.
  582.  
  583. Some months ago I posted a notice to the list about this book saying
  584. how interesting and informative I found it to be. I was most concerned
  585. to read Vesselin considers it to be "full of technical and factual
  586. mistakes". Consequently, I contacted the authors, and Bryan Clough has
  587. sent me the following reply:
  588.  
  589. - -------
  590. The 'Discover' article (February 1993) was taken from the U.S.
  591. edition of "Approaching Zero", which is being published by Random
  592. House in March. A UK paperback is now available overseas (but not
  593. in UK until March). There is also a Spanish edition called 'Los
  594. Pirateas del Chip - La Mafia Information Al Desnudo'. Japanese
  595. and Bulgarian editions are also in preparation.
  596.  
  597.   There has been no 'deliberate distortion' of any facts within
  598. the book, except as declared in the Acknowledgements.
  599.   Vesselin was an important and informative source, but nothing
  600. was taken at face value, without being cross-checked.
  601.   A matter of speculation (such as the identity of 'Diana P') can
  602. hardly be considered 'a factual error'. It may be wrong, but we
  603. have yet to learn who 'Diana P' is. And, even then, who knows?
  604. One guess is as good as another.
  605.   Some of the 'facts' may be disputed but contributors' memories
  606. tend to be selective and self-serving, and it is always difficult
  607. to ascertain 'the truth'. For example, on one occasion Captain
  608. Crunch swore that he had only used his legendary plastic whistle
  609. 'once'. On another occasion, he claimed to have used it 'hundreds
  610. of times'.
  611.   It would be interesting for Vesselin to identify the
  612. distortions, so that these can be compared with the research
  613. material and recorded interviews. Perhaps, he could also identify
  614. 'Diana P'?
  615. - --------
  616.  ----------------------------------------------------------------------------
  617. |   Ian Leitch                                 JANET: i.leitch@uk.ac.lshtm   |
  618. |   Information Technology Unit                          Tel: 071 927 2260   |
  619. |   London School of Hygiene and Tropical Medicine       FAX: 071 436 5389   |
  620. |   Keppel St., London WC1E 7HT                          Telex: 8 95 34 74   |
  621.  ----------------------------------------------------------------------------
  622.  
  623. ------------------------------
  624.  
  625. Date:    13 Feb 93 19:52:37 +0000
  626. >From:    colinj@monet.ccs.itd.umich.edu (Colin Eric Johnson)
  627. Subject: Gender switching virus
  628.  
  629.     I have just heard (through the grapevine here) of a virus that
  630. will scan through text documents and replace any gender specific nouns
  631. and pronouns with their gender-opposites (he -> she).
  632.  
  633.     Is this in fact a virus? And does it exist?
  634.  
  635. [Moderator's note: I'd suggest not jumping to any conclusions in the
  636. absense of technical information to support them.]
  637.  
  638. - -- 
  639. - ---------------
  640. Colin E. Johnson    colinj@ccs.itd.umich.edu
  641. Lab Monitor (Rover)    Univ. of Mich. ITD/ITS/CCS
  642. When Knowledge Is Outlawed Then Only Outlaws Will Have Knowledge
  643.  
  644. ------------------------------
  645.  
  646. Date:    09 Feb 93 20:31:00 +0000
  647. >From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  648. Subject: my idea for detecting file infectors
  649.  
  650. I have an idea to detect new and unknown viruses.
  651.  
  652. Let me tell you up front, my idea is only for detecting file infectors, 
  653. and should be used in conjunction with other virus detection software. 
  654. It's only another tool for the virus detection toolkit. This will not give 
  655. the users the name of the virus or tell how to remove it. Simply a Yes or 
  656. No if the user has a file infector on the loose.
  657.  
  658. This idea is as simple as archive software. two archives, FC or COMP from 
  659. DOS, and one .BAT. file. or merge the .BAT file below into your 
  660. AUTOEXEC.BAT
  661.  
  662. While you are reasonably sure that your computer is virus free archive a 
  663. few small files that you use on a constant basis. I would recommend at 
  664. least one .COM file, and 1 .EXE file, and they should be at least 10K in 
  665. size.
  666.  
  667. Some viruses only attach to .COM files, and there are viruses that only 
  668. attaches to .EXE files. Lastly some viruses will not attach to very small 
  669. files.
  670.  
  671. 1575, and Frodo will attach to  two byte .COM files. But 8 Tunes will not 
  672. attach to any file smaller than 9216 bytes.
  673.  
  674. use archive software and create an archive, and add these files.
  675.  
  676. I recommend PKzip or LHA, but not ARJ because the files size fluctuates.
  677.  
  678. BAIT.BAT
  679.  
  680. @ECHO OFF
  681. C:
  682. CD\RECOVERY
  683. DEL VIRUS.LZH
  684. LHA A -A VIRUS \COMMAND.COM \DOS\CHKDSK.* 
  685. FC BAIT.LZH VIRUS.LZH
  686. CD\
  687.  
  688. by deleting the previous test, you can be sure that you will get valid 
  689. results every time.
  690.  
  691. LHA A -A adds files to the archive regardless of the attribute, and using 
  692. wild cards on the .EXE files will pick up companion infectors like AIDS 2, 
  693. Power Pump, and others. If you want to use PKzip as your archive software, 
  694. use the .BAT file below.
  695.  
  696. @ECHO OFF
  697. C:
  698. CD\RECOVERY
  699. DEL VIRUS.ZIP
  700. PKZIP -wHS VIRUS \COMMAND.COM \DOS CHKDSK.*
  701. FC BAIT.ZIP VIRUS.ZIP
  702. CD\
  703.  
  704. FC comes with DOS 4.0 and above. If you don't have FC, COMP will do just 
  705. as well.
  706.  
  707. As long as FC or COMP do not report any differences in the two archives, 
  708. you can be reasonably sure that you don't have a file infector.
  709.  
  710. This should detect any file infector except for stealth infectors.
  711.  
  712. If you want this to detect stealth viruses, copy, this .BAT file, the 
  713. archive software, and FC.COM or COMP.COM to a known clean bootable 
  714. diskette. Once ever week or two; cold boot from this known clean diskette 
  715. (preferably write protected) and run this test.
  716.  
  717. If FC or COMP ever reports a difference in these two archives, send the 
  718. new archive to a virus researcher for study so that scanners like F-Prot, 
  719. VIRx, Scan, and others can be updated to detect this new or unknown virus.
  720.  
  721. In my tests, I archive six files.
  722.  
  723. COMMAND.COM 
  724. FORMAT.COM 
  725. PKZIP.* 
  726. WINLOAD.* 
  727. DRWATSON.EXE 
  728. NOTEPAD.EXE
  729.  
  730. These files are run on a daily basis, WINLOAD is a program that loads 
  731. Windows after a delay of a few seconds.
  732.  
  733. On my 33 MHZ 486 I can complete this test in approximately 5 seconds. 
  734. Since I use both DOS and Windows, I try to detect viruses that infects DOS 
  735. or Windows applications. Someone else may need to use more or less files 
  736. than I do.
  737.  
  738. I run this test at bootup, and after I try new software.
  739.  
  740. This is my idea, and I want to think the following people to trying to 
  741. shoot holes in my theory.
  742.  
  743. Glenn Jordan
  744. Mike Lambert
  745. Wolfgang Stiller
  746.  
  747. I know that i'm not very good at writing, but I hope this has helped 
  748. someone.
  749.  
  750. I am releasing this idea to the public domain, so authors of virus 
  751. detection software can incorporate this idea into their software if they 
  752. care to.
  753.  
  754. Bill
  755.  
  756. - ---
  757.  * WinQwk 2.0 a#383 * JERUSALEM (Skism-1) Fridays (after the 15th)
  758.                                                           
  759. ------------------------------
  760.  
  761. Date:    12 Feb 93 13:48:27 +0000
  762. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  763. Subject: Re: Norton buggy??? (or I have a PROBLEM!) (PC)
  764.  
  765. amead@s.psych.uiuc.edu (Alan Mead) writes:
  766.  
  767. > Susan gets home with the Norton disk.  We use the Norton scanner
  768. > (NAV.EXE) on my C: and it fails to find anything.  BUT, it turns out I
  769. > deleted the file that allegedly carries the virus ("a strain of
  770. > CVIR").
  771.  
  772. This is likely to be a false positive, not a virus. Cvir is a silly
  773. overwriting virus written in C and it is unlikely to spread at all. In
  774. the same time, because it is written in a  high level language, it is
  775. very difficult to pick a good scan string for it - because most of it
  776. is just code found in the C libraries, and if you pick a scan string
  777. from -there-, you're likely to flag any compiled program that contains
  778. the same library function as infected. Obviously, this is what
  779. happened to NAV. It might be fixed in the later versions, however, so
  780. you should advise your wife to check what the latest version is and to
  781. upgrade if necessary.
  782.  
  783. > What do you think?  I find it unlikely that I have a virus and
  784. > (snicker, snicker) I LOVE the fact that these morons are spending their
  785. > Friday night disinfecting clean machines.
  786.  
  787. I think that this is a rather irresponsible behavior from your
  788. part... A false positive could be very costly to a business - as much
  789. as a real virus. You wouldn't want that business to have to close and
  790. your wife to become unemployed, would you?
  791.  
  792. Regards,
  793. Vesselin
  794. - -- 
  795. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  796. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  797. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  798. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  799.  
  800. ------------------------------
  801.  
  802. Date:    Fri, 12 Feb 93 09:53:25 -0500
  803. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  804. Subject: Michelangelo (oh noooooo) (PC)
  805.  
  806. >From:    mar@dcc.ufmg.br (Marcio Migueletto de Andrade)
  807. Subject: Michaelangelo's payload (PC)
  808.  
  809. >It is known that the Michaelangelo virus makes use of INT 1Ah (AH=4)
  810. >to read the system date. It works on a 386, but fails on a XT (nothing
  811. >is returned).  The virus still works but the payload is never
  812. >achieved.  Is it due to an old BIOS ? Is there a *standard* way to
  813. >read the system date at *boot time* on a XT ?  If not, any virus that
  814. >uses the same function cannot work properly in such machines.
  815.  
  816. >(Below the equator line the XT still lives...)
  817.  
  818. Actually this function was introduced on the IBM-AT (Advanced
  819. Technology) in 1984 which was/is 286 based. Subsequently *some* clock
  820. calendar cards also supported the interrupt. In other words it works
  821. on those PCs or XTs with the right card and everything later. The easy
  822. way to find out is to just use DEBUG & try it.
  823.  
  824. Boot: An XT lacks CMOS memory and consequently has no way to remember
  825. what day/time it is. PC/XT Clock/Calender cards use either ROM
  826. extensions or special drivers to load the system clock on boot.
  827.  
  828.                     Warmly,
  829.                         Padgett
  830.  
  831. ------------------------------
  832.  
  833. Date:    12 Feb 93 14:02:17 +0000
  834. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  835. Subject: Re: PKZIP 2'S AV is cracked (PC)
  836.  
  837. mcafee@netcom.com (McAfee Associates) writes:
  838.  
  839. > We will continue to use PKZIP Version 1.10 to compress our files for
  840. > the forseeable future because 1.10 is still used more frequently then
  841. > 2.04C, there is no "exportable" version of PKUNZIP V2.04C available
  842.  
  843. You are misinformed. PKWare has obtained an export license for PKZIP
  844. 2.04whatever, which allows it to be exported to almost the whole
  845. world, except a very short list of countries (e.g., Iraq, etc.). If
  846. you are troubled that people in those countries won't be able to
  847. unpack your software, then you should be aware that there are probably
  848. regulations which forbid the export of your software to these
  849. countries as well.
  850.  
  851. > from PKWare (yet), and lastly, PKZIP Version 2.04C has several bugs
  852. > in it that make it undesirable for use in distributing software 
  853.  
  854. This is a significantly more valid argument not to use it.
  855.  
  856. > (PKWare has released a newer version, 2.04E, but we will wait to 
  857. > see how stable that is before we consider using it.).
  858.  
  859. Sigh... They have now released version 2.04g. Obviously, the product
  860. is still in beta test and we are all beta testers... :-( But I
  861. digress...
  862.  
  863. > this:  You need not present the Internet with a forged .ZIP file
  864. > merely to prove that PKWare's Authenticity Verification for Version
  865. > 2.04C of their program has been cracked.  
  866.  
  867. Wrong, he needed to post that, otherwise people like you just refuse
  868. to believe - see below.
  869.  
  870. > The Authenticity Verification and accompanying serial number generated
  871. > by the PKZIP program are used by us for providing our users with a
  872. > degree of security, they are by no means final or absolute.  However,
  873. > it is very unlikely that both the -AV and serial number will match up
  874. > in a cracked version of PKZIP.  
  875.  
  876. THIS IS WRONG AND MISLEADING! It is TRIVIAL to forge BOTH the text and
  877. the -AV and the serial number in PKZIP 1.10. What will convince you?
  878. Do you want me to send you an archive for which all the above matches?
  879. Do you want me to send you your serial number that you obtained from
  880. PKWare? Do you want me to send you a 50-line program that is able to
  881. find this number in LESS THAN A MINUTE on a XT? The security provided
  882. by the -AV thingo in PKZIP is NON-EXISTENT! And everybody must be
  883. warned about that! That's why people like the original poster need to
  884. post examples that prove that possibility to crack the security,
  885. without showing how it is done. Otherwise people like you will insist
  886. that it is "unlikely" to be done!
  887.  
  888. [Moderator's note: Folks, please keep the discussions civil.]
  889.  
  890. > I believe that it is far better that some means of protection be 
  891. > provided then none at all.
  892.  
  893. That's true, but what you seem to fail to understand is that the means
  894. of protection against tampering in your product are minimal, nearly
  895. non-existent! In particular:
  896.  
  897. 1) It is TRIVIAL to disable the self-check in SCAN or to modify its
  898. checksum after tampering.
  899.  
  900. 2) It is TRIVIAL to change the documentation that lists the VALIDATE
  901. codes.
  902.  
  903. 3) It is TRIVIAL to forge the -AV protection.
  904.  
  905. 4) It is only moderately easy to forge the VALIDATE checksums (i.e.,
  906. to modify SCAN without modifying its VALIDATE checksums), but it is
  907. even not needed, because of 2).
  908.  
  909. As a result, it is TRIVIAL to make a trojanized, forged copy of your
  910. product. The proof is that it is often being done - do you keep track
  911. of how many versions of SCAN have been "skipped", because a trojan
  912. with such number has appeared? Your product is probably the most often
  913. trojanized program in the world...
  914.  
  915. I have explained multiple times to people from McAfee Associates,
  916. including to yourself, what has to be done in order to provide -real-
  917. authentication. You must use a public-key authentication system. If
  918. you provide authentication ONLY (i.e., no encryption, which you don't
  919. need anyway), there are NO export problems. If you are concerned about
  920. the RSA patents - use the DSS algorithm, which is NOT patented and
  921. works for authentication ONLY. But naw, nobody's listening... :-(
  922.  
  923. > Our programs are directly available
  924. > from us via our BBS, forum on CompuServe, and mcafee.com ftp site
  925. > on the Internet, in addition to sites such as the SIMTEL20 archives
  926. > and garbo.uwasa.fi which I directly send the programs to.  If any
  927. > one ever has a question about the integrity of a .ZIP file they've
  928. > received, then they should delete it and download it from one of
  929. > these avenues instead.
  930.  
  931. That's not enough. There hundreds of thousands of users of your
  932. product that (a) don't have Internet access (thus, no Simtel20, no
  933. garbo, not even Virus-L/comp.virus), (b) don't have access to
  934. Compu$erve (because it is too expensive or because there's just no
  935. CompuServe in their countries), and (c) live too far away from
  936. California, so a long-distance call to your BBS or tech support
  937. numbers is not exactly what they would like to do every month. What
  938. kind of protection are you offering to those people?
  939.  
  940. > PS:  Please (!) direct any follow-up comments to me via e-mail, I have
  941. >      no desire for this newsgroup to become a battleground. :-)
  942.  
  943. You are welcome to continue this discussion with me via private
  944. e-mail, but I felt that this reply had to be posted publicly, because
  945.  
  946. > Like many other readers of the comp.virus newsgroup (and its digest
  947. > counterpart, VIRUS-L), I appreciate it when computer security and
  948. > integrity are discussed, especially when they relate to our (McAfee
  949. > Associates, that is) programs.
  950.  
  951. Regards,
  952. Vesselin
  953. - -- 
  954. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  955. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  956. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  957. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  958.  
  959. ------------------------------
  960.  
  961. Date:    12 Feb 93 15:07:37 +0000
  962. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  963. Subject: Re: STONED, Scanv99/Clean 99 Questions/Concerns (PC)
  964.  
  965. CASTILLO@nauvax.ucc.nau.edu writes:
  966.  
  967. > 1) When Untouchable is used, it says that No-Int has been found but
  968. > that it cannot fix it.
  969.  
  970. You mean UTScan, right? Have you installed the integrity checker? If
  971. not, why not? If yes, why not using it to recover the boot sectors?
  972.  
  973. > 2) When McAfee's Scan v99 is used, it finds the Stoned virus, 
  974. > and the Clean can clean it.  HOWEVER, when scanning AGAIN for the
  975. > virus, we find it in memory.  This is after having booted from a 
  976. > write-protected virus free floppy disk.  Further tests apparently
  977. > show that Stoned can load into memory by a simple read on an 
  978. > infected disk.  The documentation I've read via FTP land say that that
  979. > is impossible.  Some people have suggested that Scan is not correct.
  980.  
  981. This is indeed impossible and Scan is indeed not correct, or more
  982. exactly, it is not designed correctly. Read the FAQ, question E11 for
  983. more information. We've put a lot of efforts in this FAQ, it is a good
  984. idea to read it before asking...
  985.  
  986. > Questions: Why doesn't Untouchable work right? 
  987.  
  988. Because it is probably a new variant of No_INT and you are using a
  989. scanner. Remember, scanners can detect/remove only known viruses.
  990. Install the integrity checker of Untouchable and -use- it. It is very
  991. good and, if installed on a virus-free system, can remove practically
  992. any boot sector infector.
  993.  
  994. > CAN the Stoned virus
  995. > load into memory by a simple read from an infected floppy??  Is there
  996. > a strain of stoned that can do this?
  997.  
  998. Yes, it can. All strains of Stoned are doing this - loading in memory
  999. when you read an infected floppy. In fact, it is not the virus that
  1000. does it - it is DOS itself. It reads the boot sector of the diskette
  1001. (where the virus resides), thus loading the virus in memory - in one
  1002. of the DOS buffers.
  1003.  
  1004. However, the fact that the virus is in memory does NOT mean that it is
  1005. active - something that a poorly designed memory checking scheme (like
  1006. the one used by SCAN) will fail to notice. The virus code is there,
  1007. but it never gets control. Just like copying an executable file will
  1008. put this file (or parts of it) somewhere in memory, but will not
  1009. execute it.
  1010.  
  1011. Regards,
  1012. Vesselin
  1013. - -- 
  1014. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1015. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1016. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1017. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1018.  
  1019. ------------------------------
  1020.  
  1021. Date:    12 Feb 93 15:17:42 +0000
  1022. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  1023. Subject: Re: Twelve Tricks (PC)
  1024.  
  1025. REEDA@ibm3090.bham.ac.uk writes:
  1026.  
  1027. > Norton anti-virus detected Twelve-Tricks virus on one of our PCs but
  1028. > f-prot 2.06a reported the PC as clean. Is this virus one that the
  1029. > current f-prot misses or have we found a NAV false +ve?
  1030.  
  1031. NAV is definitively wrong. Twelve Tricks is a trojan, not a virus, and
  1032. it does not spread. It is very unlikely that it is on your computer.
  1033. On the other side, F-Prot 2.06a -does- detect this trojan (and
  1034. properly reports it as trojan).
  1035.  
  1036. There is one remote possibility that there is -something- on your
  1037. computer that just happens to contain the scan string for Twelve
  1038. Tricks that NAV uses. Where is the "virus" find? In a file? In many
  1039. files? In the MBR? Are you using the latest version of NAV? Have you
  1040. contacted your local tech support for NAV?
  1041.  
  1042. Regards,
  1043. Vesselin
  1044. - -- 
  1045. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1046. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1047. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1048. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1049.  
  1050. ------------------------------
  1051.  
  1052. Date:    12 Feb 93 15:38:50 +0000
  1053. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  1054. Subject: Re: Virstop 2.07 in Icelandic (PC)
  1055.  
  1056. jdh@medicine.newcastle.edu.au (John Hendriks) writes:
  1057.  
  1058. > We have just downloaded the latest version of f-prot (2.07). Of course
  1059. > all is well as far a scan is concerned. At least I can understand the
  1060. > reports.  When loading virstop though and testing with f-test the
  1061. > diagnostics are incomprehensible. Is there an English version of
  1062. > virstop?
  1063.  
  1064. You seem to have gotten a version of the package that Frisk
  1065. distributed by mistake. The archive with the English version of
  1066. VirStop can be obtained from him or from our ftp site:
  1067.  
  1068. ftp.informatik.uni-hamburg.de:/pub/virus/progs/fp-207.zip
  1069.  
  1070. Regards,
  1071. Vesselin
  1072. - -- 
  1073. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1074. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1075. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1076. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1077.  
  1078. ------------------------------
  1079.  
  1080. Date:    12 Feb 93 15:50:21 +0000
  1081. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  1082. Subject: Re: Vshield vs Virstop (PC)
  1083.  
  1084. ST29701@vm.cc.latech.edu writes:
  1085.  
  1086. [Long list of unknown viruses that VShield would not be able to detect
  1087. deleted for brevity.]
  1088.  
  1089. > Isn't this also true for VIRSTOP??????????????????
  1090.  
  1091. Of course it is - and it is also true for any known-virus scanner, be
  1092. it a resident or a non-resident one. That's why scanners are a weak
  1093. line of defense against viruses. That's why you must use an integrity
  1094. checker as a second and more powerful line of defense. But we were
  1095. mainly discussing the capabilities of VShield for integrity checking
  1096. and I pointed out many kinds of attacks that it does not protect you
  1097. against. There are integrity checkers that -do- protect you against
  1098. most of these attacks.
  1099.  
  1100. Regards,
  1101. Vesselin
  1102. - -- 
  1103. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1104. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1105. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1106. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1107.  
  1108. ------------------------------
  1109.  
  1110. Date:    Fri, 12 Feb 93 11:54:04 -0500
  1111. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  1112. Subject: STONED in Memory (PC)
  1113.  
  1114. >From:    CASTILLO@nauvax.ucc.nau.edu (Ulysses Castillo)
  1115.  
  1116. >1) Cold booted from a write-protected virus free disk.
  1117. >2) Used SCAN v99 on C:, no virus was found in memory or on C:.
  1118. >3) Inserted an infected floppy in B:.
  1119. >4) Ran scan on b:.  No virus found in memory, stoned virus found
  1120. >in boot sector of B:.
  1121.  
  1122. Ok, here's what has happened - PC not infected. on (4) SCAN checked
  1123. the memory (4a)- was clean - then checked to infected disk (4b). In the second
  1124. action the DBR of the floppy was read into the DOS buffer in low memory.
  1125. *But SCAN had already finished checking memory*.
  1126.  
  1127. >5) Ran scan on B: again.  Virus found in memory and in boot sector
  1128. >of B:. (HOW???)
  1129.  
  1130. On the second run of SCAN the memory is again checked first (5a). This time the
  1131. infected DBR is still in the DOS Buffer from (4b).
  1132.  
  1133. 6) Reboot (cold boot, not control-alt-delete).
  1134. 7) Inserted infected disk in B:.
  1135. 8) Ran CLEAN on B:. Virus NOT in memory, but found in boot sector
  1136. of B:.  Virus removed from B:.
  1137. 9) Ran scan on B:.  Virus found in memory. (Again, HOW???), but NOT
  1138. found on B:.
  1139.  
  1140. Repeat of same process. After reboot, the C: drive DBR is in the buffer -
  1141. SCAN finds nothing but loaded the infected DBR into the buffer *after*
  1142. checking memory (during 8) for second SCAN (9) to find. 
  1143.  
  1144. Now if between (7) and (8) a DIR were performed on the infected floppy, DOS
  1145. would have loaded the buffer and the memory check in (8) would have discovered
  1146. the virus. The same would have occured if done between (3) & (4).
  1147.  
  1148. Now DOS only reads the DBR when it receives a request after detecting
  1149. a changed disk. If between (8) and (9) a second clean floppy had been
  1150. put in the drive and a DIR performed, SCAN (9) would have found memory
  1151. to be virus free (famous last words - well it worked when I tried it).
  1152.  
  1153.                         Warmly,
  1154.  
  1155.                             Padgett
  1156.  
  1157.  
  1158. ------------------------------
  1159.  
  1160. Date:    12 Feb 93 09:35:06 -0800
  1161. >From:    a_rubin@dsg4.dse.beckman.com
  1162. Subject: Re: Help! Help, with FORM virus (PC)
  1163.  
  1164. IANR012@UNLVM.UNL.EDU (Bill Hayes) writes:
  1165.  
  1166. >Recently, a professor here armed his students with a custom program
  1167. >written for him by a student programmer.  He had a secretary make
  1168. >about twenty copies of the program for his students.  Unfortunately,
  1169. >the secretary's machine was infected with FORM, a boot sector virus.
  1170. >Now my student computer labs have been infected with it.
  1171.  
  1172. ..
  1173.  
  1174. >Although I would much rather buy enough licenses to cover my machines,
  1175. >I am now trying to find public domain (and I mean FREE) software.
  1176. >McAffee and Associates quoted me a whopping $17,000 dollars to site
  1177. >license their products.  I might be able to wring out $5.00 to $10.00
  1178. >per machine to license a product.  Is their anything out there, or am
  1179. >I doomed to spend my life chained to a chair cleaning off FORM from
  1180. >student diskettes?
  1181.  
  1182. >From ORDER.DOC (FP-207), F-PROT is shareware, with $1/machine license
  1183. for the first 2500, (decresing for more machines) with a 25%
  1184. educational discount (min $20); plus $20 for an actual copy or $100
  1185. for an annual subscription (bi-monthly updates), if you don't have ftp
  1186. access.
  1187.  
  1188. (There, now I've said it.  You don't have to violate network
  1189. advertising guidlines, Frisk.)
  1190.  
  1191. - --
  1192. Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
  1193. 216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
  1194. My opinions are my own, and do not represent those of my employer.
  1195. My interaction with our news system is unstable; please mail anything important.
  1196.  
  1197. ------------------------------
  1198.  
  1199. Date:    Fri, 12 Feb 93 22:07:56 +0000
  1200. >From:    lx523c@seas.gwu.edu (Le L. Chen)
  1201. Subject: Jeruslem variant (PC)
  1202.  
  1203.  I got the Jersulem standard and variant few weeks ago .  The thing
  1204. confused was that it was infected on Jan 20th, before this day, i got
  1205. some software and scan them with Mcafee scan97, f-prot2.05, nothing
  1206. happened. Everything was OK. But on Jan. 20th, I booted up and saw the
  1207. messege showed: win386 was damged. Since it was about 2 am, too late.
  1208. The second day, another person sho booted up again, the same sign he
  1209. saw. Then used the scan97 and f-prot2.05 checked, found the viruses. I
  1210. can not understand how come the first time checked it was ok, later,
  1211. after the computer was infected, it can detect them.  suppose some
  1212. viruses infect software in certain time, can them be detected not on
  1213. the exact day?  Every softwares i got was scanned first.  But now i
  1214. doubt the scan some.
  1215.  
  1216. Every information is appreciate.
  1217. Thanks a lot. e-mail or post to reply is fine 
  1218. e-mail: lx523c@seas.gwu.edu
  1219.  
  1220. ------------------------------
  1221.  
  1222. Date:    Fri, 12 Feb 93 19:59:20 -0500
  1223. >From:    Ian Leitch <I.LEITCH@lshtm.ac.uk>
  1224. Subject: Tokyo Virus in NETCB or a false positive? (PC)
  1225.  
  1226. I have recently downloaded NETCB v0.3b from the UK HENSA (Higher
  1227. Education National Software Archive) directory
  1228. micros/ibmpc/dos/h/h112. (NETCB is Chat box for Novell networks
  1229. and was written by Koos van den Hout.) On scanning the unpacked
  1230. executable with F-Prot before trying to use it, Secure Scan finds
  1231. no infection. However, any attempt at execution is intercepted
  1232. by VIRSTOP which reports infection with Tokyo virus. As expected,
  1233. Quick Scan returns the same report. The Heuristic Scan reports
  1234. a self-modifying program, which may indicate a self-encrypting
  1235. virus (or just unusual code).
  1236.  
  1237. Identical reports are obtained from both F-Prot v2.06a and v2.07.
  1238. None of the other scanners available to me (including McAfee's
  1239. SCAN100 and Dr Solomon's ToolKit report any problem). I do not
  1240. believe that the infection (if any) occurred at this site as I
  1241. have repeated the download on micros of two independent
  1242. organisations with identical results. Also, the program file size
  1243. is identical with that indicated in the accompanying message file
  1244. (H112.MSG).
  1245.  
  1246. These and other indications lead me to think that I may have hit
  1247. a false positive. If so, how can I run it and retain protection
  1248. from VIRSTOP?
  1249.  
  1250. Ian Leitch
  1251.  ----------------------------------------------------------------------------
  1252. |   Ian Leitch                                 JANET: i.leitch@uk.ac.lshtm   |
  1253. |   Information Technology Unit                          Tel: 071 927 2260   |
  1254. |   London School of Hygiene and Tropical Medicine       FAX: 071 436 5389   |
  1255. |   Keppel St., London WC1E 7HT                          Telex: 8 95 34 74   |
  1256.  ----------------------------------------------------------------------------
  1257.  
  1258. ------------------------------
  1259.  
  1260. End of VIRUS-L Digest [Volume 6 Issue 26]
  1261. *****************************************
  1262.  
  1263.