home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 (Alt) / The_Hacker_Chronicles_Volume_II-CD2.iso / virusl6 / virusl6.040 < prev    next >
Encoding:
Internet Message Format  |  1995-01-03  |  38.3 KB

  1. Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
  2.     id AA17739; Fri, 5 Mar 1993 18:34:46 +0100
  3. Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA07552
  4.   (5.67a/IDA-1.5 for <mikael@abacus.hgs.se>); Fri, 5 Mar 1993 12:10:21 -0500
  5. Date: Fri, 5 Mar 1993 12:10:21 -0500
  6. Message-Id: <9303051711.AA04562@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 #40
  16. Status: RO
  17.  
  18. VIRUS-L Digest   Friday,  5 Mar 1993    Volume 6 : Issue 40
  19.  
  20. Today's Topics:
  21.  
  22. Scanners getting bigger and slower
  23. Of guns, viruses, and geography (was re: your opinions...)
  24. Viruses in other populations
  25. Re: Sale of Viri
  26. Central Point Antivirus and Stacker (PC)
  27. EXE/COM switch (PC)
  28. How can you recover a hrad drive from joshi? (PC)
  29. Re: PC Magazine reviews virus software (PC)
  30. PC Magazine on Anti-Virus (PC)
  31. Validate values for Vshield v102 (PC)
  32. Re: Unloading TSRs (was: scanners) (PC)
  33. Re: Why only PC's?
  34. re: Laws and Viruses
  35. re: standardization (PC)
  36. Re: Virus Development Programs (PC)
  37. Re: wordperfect virus? (PC)
  38. Re: Virus Development Programs
  39. Identification needed for a Virus Message (PC)
  40. Re: Effect of Form (PC)
  41. Removal of Michelangelo (PC)
  42. Financial firms open meeting Thursday on Trace Center recovery
  43.  
  44. VIRUS-L is a moderated, digested mail forum for discussing computer
  45. virus issues; comp.virus is a non-digested Usenet counterpart.
  46. Discussions are not limited to any one hardware/software platform -
  47. diversity is welcomed.  Contributions should be relevant, concise,
  48. polite, etc.  (The complete set of posting guidelines is available by
  49. FTP on cert.org or upon request.) Please sign submissions with your
  50. real name.  Send contributions to VIRUS-L@LEHIGH.EDU.  Information on
  51. accessing anti-virus, documentation, and back-issue archives is
  52. distributed periodically on the list.  A FAQ (Frequently Asked
  53. Questions) document and all of the back-issues are available by
  54. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  55. (comments, suggestions, and so forth) should be sent to me at:
  56. <krvw@FIRST.ORG>.
  57.  
  58.    Ken van Wyk, krvw@first.org
  59.  
  60. ----------------------------------------------------------------------
  61.  
  62. Date:    Sun, 28 Feb 93 12:38:00 +0100
  63. From:    Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz)
  64. Subject: Scanners getting bigger and slower
  65.  
  66. Vesselin Bontchev writes:
  67.  
  68.  > Bigger - yes. Slower - not necessarily. First, not everybody's scanner
  69.  > has a different signature for any different virus. There are a lot of
  70.  > scanners around that report "Jerusalem variant" for a couple of
  71.  > hundreds of different viruses, the only common thing being that they
  72.  > are indeed derived from the old Jerusalem virus. In most cases, all
  73.  > those variants are detected with 1-2 signatures. But, as more and more
  74.  > viruses appear, scanners must necessarily get bigger and use more
  75.  > memory.
  76.  
  77. You know, Vesselin, I thought of a different approach to be used, when the day 
  78. comes that there would be too many viruses.
  79.  
  80. Instead of having one big huge turtle speed scanner, you would have, say, 4 
  81. scanners.
  82.  
  83. One for stealths, one for common viruses, one for encryptive and one for rare. 
  84. Thus, you would use them in different frequencies, and each would run faster 
  85. and better.
  86.  
  87. Comments?
  88.  
  89. Inbar Raz
  90. - - --
  91. Inbar Raz                  5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
  92. Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il
  93.  
  94. - ---
  95.  * Origin: Inbar's.  (9:9721/210)
  96.  
  97. ------------------------------
  98.  
  99. Date:    Thu, 04 Mar 93 09:15:06 -0500
  100. From:    ROBERT HINTEN 617-565-3634 <HINTEN.ROBERT@epamail.epa.gov>
  101. Subject: Of guns, viruses, and geography (was re: your opinions...)
  102.  
  103. dudleyh@redgum.ucnv.edu.au (Dudley Horque) writes:
  104.  
  105. >bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  106. >>
  107. >>You see, there are BIG differences between the local laws in the
  108. >>different countries. You shouldn't assume that something is legal or
  109. >>illegal (and should remain so) just because it is so in your
  110. >>particular country. On the other side, computer viruses do not
  111. >>recognize country boundaries...
  112.  
  113. >That's USAns for you.
  114.  
  115. While I'm sure (hope) other USAns will respond, I hasten to point out that
  116. the original poster was Canadian:
  117.  
  118. >Date:    Tue, 23 Feb 93 19:00:00 -0500
  119. >From:    Luis Gamero <luis.gamero@canrem.com>
  120. >Subject: your opinions on virus legality
  121. >
  122. >No.  If you keep it in your OWN posession how could it be illegal?
  123. >You can own a gun and not use it.  That's not illegal.
  124. >- --
  125. >Canada Remote Systems - Toronto, Ontario
  126. >416-629-7000/629-7044
  127.  
  128. dudleyh@redgum.ucnv.edu.au (Dudley Horque):
  129.  
  130. >But everyone else gets the last laugh... many of their kids in secondary
  131. >education cannot even point out where USA is on a map.
  132.  
  133. There are indeed USAns in secondary education that have trouble with
  134. geography (as I'm sure do a proportionate number of Australians), but can't
  135. find USA on a map?  That stretches credibility.  My soon-to-be-five year
  136. old daughter can not only locate her country, state, county, city, and
  137. street on a map, but can also find Australia on a globe, and does quite 
  138. well with most European and Mid-Eastern countries (was going to include 
  139. eastern Europe, but lately *I've* had trouble with that :-)).
  140.  
  141. The above notwithstanding, I fail to see the correlation between
  142. proficiency in geography and the ability to create "dangerous" viruses.
  143.  
  144. >Still, this does cut down on the number of dangerous viruses that the
  145. >USAns can write.
  146.  
  147. Can we infer that certain Bulgarians (i.e., Dark Avenger) can handle a map
  148. blindfolded?
  149.  
  150. ==========================================================================
  151. Monty Hinten                                 hinten.robert@epamail.epa.gov
  152. Information Security Officer                                 (617)565-3634
  153. US EPA, Region I
  154. Boston, MA  *USA*
  155. ==========================================================================
  156.  
  157.  
  158.  
  159. ------------------------------
  160.  
  161. Date:    Thu, 04 Mar 93 11:07:39 -0500
  162. From:    WHMurray@DOCKMASTER.NCSC.MIL
  163. Subject: Viruses in other populations
  164.  
  165. >I have a question.  Why is it that all the virus discussions are about
  166. >PC's and Mac's?  There ARE other computers out there.  What about NeXt,
  167. >C-64, Amiga's.  I never see hardly anything on those types of computers.
  168. >Is it possible those types don't have as many virus problems as PC's?
  169.  
  170. There have been a number of answers to this question.  I would like to
  171. suggest two more.
  172.  
  173. The first is that one of the conditions for the success of a virus is 
  174. population size and density.  Consider the case of a one of a kind
  175. computer.  A virus makes no sense in that context.  It does not make
  176. much more sense in the case of two, or any small number of computers.
  177.  
  178. If you introduce Herpes Simplex ("Chicken Pox") into a sterile population 
  179. of  10K people, about 10 percent will die, most of the remainder will
  180. become immune, and Herpes will die out.  On the other hand, if you
  181. introduce it into a population of 100K, it will prosper.  The reason is
  182. that the target population will replenish itself, from the bottom, at a
  183. rate sufficient to ensure that the virus will always have a new place to
  184. go.  It is in part for this reason that we call chicken pox a
  185. "childhood" disease.  It is not that children are inherently more
  186. vulnerable to the virus than adults, but that all of the adults are
  187. either immune or dead. 
  188.  
  189. So it is with computers.  There is some minimum population size that is 
  190. required for the continued successful spread and persistence of the
  191. virus.  We do not know what that size is.  We know clearly that the PC,
  192. MAC, and Atari Amiga populations are large enough.  We suspect, but do
  193. not know for certain, that most of the other populations are too small.
  194.  
  195. Another reason has to do with the extra-host persistence of the virus.  The
  196. successful viruses spread via diskette.  This is a very slow mechanism,but 
  197. the virus is very safe and persistent on the diskette.  Contrast this to the
  198. internet (RTM, "All Souls") worm.  It spread very rapidly, doubling in
  199. tens of minutes.  In part because of this rapid spread it was noticed,
  200. and identified very rapidly, within hours.  Because it had no extra-host
  201. place to hide, it was eradicated with tens of hours.  
  202.  
  203. We see a similar phenomenon with the spread of viruses in LANs.  They
  204. spread  very rapidly, are noticed early, and copies on servers and even
  205. workstations can be eliminated fairly rapidly.  However, here, during
  206. the infection, many copies were created on diskette.  These are
  207. difficult to identify and eradicate. If we are both diligent and lucky,
  208. we may find about half; the remainder are waiting to infect us again.
  209.  
  210. William Hugh Murray, Executive Consultant, Information System Security
  211. 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840                
  212. 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL
  213.  
  214.  
  215. ------------------------------
  216.  
  217. Date:    Thu, 04 Mar 93 12:34:31 -0500
  218. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  219. Subject: Re: Sale of Viri
  220.  
  221. >From:    Doug <JDG111@PSUVM.PSU.EDU>
  222.  
  223. This was addressed to Vesselin but since it appears to come from a source in 
  224. the USA & reflects a viewpoint I hoped had disappered in this country, I have
  225. some comments.
  226.  
  227. >You are simply mistaken, sir.  Distributing virus code to those who want it
  228. >is NOT a very wrong thing which should never be done.  You are talking about
  229. >censorship.  
  230.  
  231. As far as I know, in the United States there are no laws against the sale
  232. or sharing of viruses between two consenting parties (am sure to be corrected
  233. if wrong), primarily since there is no consistant definition of what a virus
  234. is, and secondly they are not all proven to be bad (I have an opinion but that
  235. has nothing to do with the law).
  236.  
  237. Similarly, I have very strong views on a number of subjects (abortion is one)
  238. BUT do not feel that I have any right to impose those views on anyone else.
  239.  
  240. One of those views is not to distribute viral code to anyone who I do not
  241. personally know is capable of proper handling. This is my perrogative.
  242.  
  243. > You are telling ME, and the rest of us, that we are not as knowledgeable 
  244. >about virus code as you are, therefore we may not have it, but you can.  
  245. >I don't like that.
  246.  
  247. Tough.
  248.  
  249. What you are saying is that you think that you have a "right" to viral code.
  250. By who's grace ? You are saying I do not have a right my ethical and moral
  251. decision not to distribute it. What will you want next ? The vulnerabilities
  252. that some of us have discussed privately (and thank heaven we have not seen 
  253. yet). Sorry.
  254.  
  255. So you want to learn viruses. Viruses are just a special case of programming
  256. and if you really understand the architecture then how they work is self-
  257. evident. Probably you can find someone who will allow you to specialize
  258. before you are a generalist (am told that before Picasso would take on 
  259. a student, he required the ability to paint a flower with photographic
  260. quality), but it will not be me.
  261.  
  262.                         Warmly,
  263.                             Padgett
  264.  
  265. ------------------------------
  266.  
  267. Date:    Sun, 28 Feb 93 12:34:00 +0100
  268. From:    Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz)
  269. Subject: Central Point Antivirus and Stacker (PC)
  270.  
  271. D_Gill@twu.edu writes:
  272.  
  273.  > I use stacker, and recently have begun Internet, etc.  I have Central
  274.  > Point Antivirus, but haven't installed it yet.  Stacker manual warns
  275.  > against using some antivirus packages, but doesn't cite which not to
  276.  > use.
  277.  
  278.  > Are Central Point Antivirus and Stacker compatible?
  279.  
  280. I wouldn't use Central Point AntiVirus, REGARDLESS of its stacker 
  281. compatibility.
  282.  
  283. I haven't seen even ONE version or release that didn't have a stupid bug, or 
  284. nonsense written inside it.
  285.  
  286. Inbar Raz
  287. - - --
  288. Inbar Raz                  5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
  289. Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il
  290.  
  291. - ---
  292.  * Origin: Inbar's.  (9:9721/210)
  293.  
  294. ------------------------------
  295.  
  296. Date:    Sun, 28 Feb 93 12:35:00 +0100
  297. From:    Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz)
  298. Subject: EXE/COM switch (PC)
  299.  
  300.  > From: Peters@DOCKMASTER.NCSC.MIL (Donald G Peters)
  301.  
  302.  > I will also leave it to an enterprising individual to
  303.  > determine wither COMMAND.COM will run if it is renamed
  304.  > to COMMAND.EXE (with the appropriate change to the COMSPEC
  305.  > variable in CONFIG.SYS). Personally, I doubt it, but
  306.  > perhaps a simple modification to the boot sector may make
  307.  > this possible. I think a utility in this regard would be
  308.  > very nice!
  309.  
  310. One reason why NOT to do it, is that a lot of programs issue a shell to dos by 
  311. calling COMMAND.COM. They  don't even bother looking for comspec.
  312.  
  313. Inbar Raz
  314. - - --
  315. Inbar Raz                  5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
  316. Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il
  317.  
  318. - ---
  319.  * Origin: Inbar's.  (9:9721/210)
  320.  
  321. ------------------------------
  322.  
  323. Date:    Sun, 28 Feb 93 13:20:00 +0100
  324. From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
  325. Subject: How can you recover a hrad drive from joshi? (PC)
  326.  
  327. murray@andromeda.rutgers.edu (Murray Karstadt) Asks:
  328.  
  329.  > Can a hard drive once its been attacked by joshi be recovered?
  330.  
  331. It depends.
  332. According to the description, it is not likely that the virus that infected 
  333. you was necessarily Joshi. since this is a boot sector virus and will infect 
  334. only if you boot from an infected floppy. This does not seam to be the case. 
  335. It looks like your "old Anti Virus" had a false detection that caused it to 
  336. CLEAN something that wasent there. The result is that the Master Boot Recors 
  337. of your Hard Disk was overwritten by rubbish.
  338.  
  339. If you absoluttely know what you are doing (or have nothing to lose, here's 
  340. what you should try to do:
  341.  
  342. - - If your disk is an MS-DOS formatted disk, using DOS 3.XX or   higher, and 
  343. with no DISK-MANAGER driver included, just   reboot the PC from a clean MS-DOS 
  344. 5.0 floppy and run
  345.   FDISK /MBR.
  346. - - Reboot the PC, if it does not load, you will have to edit   the partition 
  347. table and set the correct parameters of   Beginning / End location of your 
  348. drive, rebotting after   each attempt and checking if you have access to the 
  349. disk.
  350.   (Norton's DISKEDIT might get handy in this case).
  351.  
  352. A good solution could be if you have another disk of the same configuration: 
  353. Read the Partition Table from it and Write it to the damaged disk's Partition 
  354. Table.
  355.  
  356. Regards
  357.  
  358. * Amir Netiv. V-CARE Anti Virus, head team *
  359.  
  360. - --- FastEcho 1.21
  361.  * Origin: <<< NSE Software >>> Israel (9:9721/120)
  362.  
  363. ------------------------------
  364.  
  365. Date:    01 Mar 93 21:32:00 +0000
  366. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  367. Subject: Re: PC Magazine reviews virus software (PC)
  368.  
  369. Quoting from Christopher Yoong-meng Wo to All About Re: PC Magazine 
  370. reviews v on 02-28-93
  371.  
  372. CY> I am embarassed. Some of you might jump on me for this, so I should
  373. CY> clarify this before others do. I should have been more thorough with
  374. CY> my reading before posting the above. The PC Magazine article does
  375. CY> indeed review the Mc Afee products, under the name of "Pro-Scan", a
  376. CY> commercial product. Also, F-prot's engine was present in 3 of the
  377.  
  378. McAfee's Pro Scan, and Virus Scan (Share ware) are two different products.
  379.  
  380. McAfee's Peo Scan is also sold under two other names. Virus Cure (from 
  381. I.M.S.I), and Virucide (from Parson's technology)
  382.  
  383. The latest revision that I have seen is 2.37. There may be a later one by 
  384. now.
  385.  
  386. Bill
  387.  
  388. - ---
  389.  * WinQwk 2.0 a#383 * DATACRIME II activates Oct 13 - Dec 31
  390.  
  391. ------------------------------
  392.  
  393. Date:    01 Mar 93 21:26:00 +0000
  394. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  395. Subject: PC Magazine on Anti-Virus (PC)
  396.  
  397. Quoting from Joe.george@nd.edu to All About PC Magazine on Anti-Virus on 
  398. 02-28-93
  399.  
  400. J > Do people in this group support Pc Mag's Editor's Choice Awards to
  401. J > Central Point Anti-Virus and Norton's Anti-Virus?  I thought the best
  402. J > protection was McAfee's SCAN backed up by F-PROT or vice-versa.
  403.  
  404. I do NOT support PC-Magazine's Editors Choice.
  405.  
  406. They may be accurate, and the thests appear to be thourough.
  407.  
  408. If they had tested the 70 or 80 common viruses known to be in the wild, 
  409. their tests would have been more valid.
  410.  
  411. I find it very hard to believe that there are more than 2,000 specimens 
  412. known, and 70 or 80 common viruses known to be circulating in the wild, 
  413. and they feel that 11 viruses are enough ti use for testing purposes.
  414.  
  415. Bill
  416.  
  417. - ---
  418.  * WinQwk 2.0 a#383 * VICTOR activates any Wednesday
  419.                                                                                
  420.             
  421.  
  422. ------------------------------
  423.  
  424. Date:    Thu, 04 Mar 93 09:14:54 -0500
  425. From:    RON MURRAY <NMURRAYR@cc.curtin.edu.au>
  426. Subject: Validate values for Vshield v102 (PC)
  427.  
  428. In Virus-L Digest V6 #37, aryeh@mcafee.com (McAfee Associates) writes:
  429.  
  430. [...]
  431. > VALIDATE VALUES
  432. [...]
  433. > VSHIELD 5.22V102 (VSHIELD.EXE)      S:45,724   D:02-27-93   M1: 06BB  M2: 066C
  434.                                                                   ^^^^
  435.    The .doc file, and the results of running Validate on this file, both give
  436. a value of 06EB here. I assume it's just a typo, but perhaps Aryeh can confirm
  437. the correct value here, just in case I have a hacked copy?
  438.  
  439.  .....Ron
  440.                                  ***
  441.  Ron Murray
  442.  Internet: nmurrayr@cc.curtin.edu.au
  443.    "Women are like elephants to me -- I like to look at 'em, but I wouldn't
  444.        want to own one."     -- W. C. Fields
  445.  
  446. ------------------------------
  447.  
  448. Date:    Thu, 04 Mar 93 09:15:16 -0500
  449. From:    Y. Radai <RADAI@vms.huji.ac.il>
  450. Subject: Re: Unloading TSRs (was: scanners) (PC)
  451.  
  452.   Inbar Raz writes:
  453. >The problem with TSRs is, that as simple as they are to INSTALL resident, they
  454. >are also easy do remove from memory.
  455. >
  456. >The moment a virus writer acquires your module, he can write a relatively
  457. >small piece of code that will unload your TSR, without it knowing about it.
  458. >A friend of mine once wrote an 80byte routine to unload Carmel's TSafe. I
  459. >believe that after a little research, I could unload almost anything.
  460.  
  461. 80 bytes?  Your "friend" worked too hard.  TSafe can be unloaded with
  462. just 8 bytes of code.  But that's because Carmel's programmers
  463. supplied an interrupt handler for unloading TSafe.  In general, you
  464. have to work a bit harder ....
  465.  
  466.                                      Y. Radai
  467.                                      Hebrew Univ. of Jerusalem, Israel
  468.                                      RADAI@HUJIVMS.BITNET
  469.                                      RADAI@VMS.HUJI.AC.IL
  470.  
  471.  
  472. ------------------------------
  473.  
  474. Date:    Thu, 04 Mar 93 10:35:45 -0500
  475. From:    "David M. Chess" <chess@watson.ibm.com>
  476. Subject: Re: Why only PC's?
  477.  
  478. >From:    scott@shrug.dur.ac.uk (Scott A. McIntyre)
  479.  
  480. >I'm sure that there is also the technical side of how viruses work --
  481. >on a Unix machine, unless a virus is executed as root, then the damage
  482. >would be limited most likely to one user's files, and could quickly be
  483. >found...processes without owners can be tracked down and so on.
  484.  
  485. I agree with most of the rest of this posting, but this paragraph
  486. misses the mark.  Because viruses can spread from user to user
  487. whevener one user has write access to a program that another user
  488. has execute access to, a virus can spread to many users even in
  489. a system with access controls.  If it then does some damage (on
  490. a certain date, say), it can damage the files of lots of users,
  491. even if none of them happen to be root.  Viruses don't have to
  492. do any odd tricks like creating ownerless processes; all they
  493. have to do is read and write files.  Fred Cohen did some early
  494. experiements in which a very simple virus spread within a Unix
  495. system without any trouble.  PC viruses cause lots of distress,
  496. even though damage is in the same sense "limited... to one
  497. user's files"!  *8)
  498.  
  499. I think the reasons that we've not seen viruses in Unix
  500. environments is more cultural than technical: sharing patterns
  501. are very different, there's lots less exchange, a lower
  502. density of machines in homes, and so on, as you said
  503. earlier in your posting.
  504.  
  505. - - -- -
  506. David M. Chess                 |  "And like the clouds that turn to every
  507. High Integrity Computing Lab   |   passing wind, we turn to any signal
  508. IBM Watson Research            |   that comes through..."  --  Eno/Cale
  509.  
  510.  
  511. ------------------------------
  512.  
  513. Date:    Thu, 04 Mar 93 10:43:49 -0500
  514. From:    "David M. Chess" <chess@watson.ibm.com>
  515. Subject: re: Laws and Viruses
  516.  
  517. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  518.  
  519. >        From a legal standpoint it might be enough to define a virus
  520. >as "a sequence of instructions that intentionally performs an unwanted
  521. >and undocumented modification within a computing system for which it is
  522. >intended."
  523.  
  524. >        Possibly "malicious software" would be a better term but IMHO
  525. >the word "computer virus" has passed beyond any hope of control.
  526.  
  527. Gak!   I normally avoid terminology disputes like the plague,
  528. but why would we want to *codify* a loose popular usage of
  529. an otherwise-useful word?  Do we *enjoy* confusion?  What
  530. word are you going to use to talk about viruses (you know,
  531. those things that spread)?
  532.  
  533. I tend to think:
  534.  
  535.   - We don't need laws against viruses at all, since the
  536.     bad things about viruses isn't that they spread, but
  537.     that they spread to (and otherwise exploit) systems
  538.     belonging to people that don't want them.  *That's*
  539.     what ought to be illegal.
  540.  
  541.   - We don't really need new laws against Trojan horses
  542.     (including the Trojan horse aspects of viruses), because
  543.     we already have laws to cover things like this in
  544.     general.   (We don't need specific laws against
  545.     assualt-with-tuna, because we have general laws
  546.     against assault.)
  547.  
  548.   - If someone does decide to write a law against Trojan
  549.     horse things, it shouldn't use the word "virus" to
  550.     mean Trojan horse.  The reasons not to are obvious,
  551.     and I can't think of any reasons to...
  552.  
  553. These are of course my own opinions, and not my employer's.
  554.  
  555. DC
  556.  
  557.  
  558. ------------------------------
  559.  
  560. Date:    Thu, 04 Mar 93 10:54:34 -0500
  561. From:    "David M. Chess" <chess@watson.ibm.com>
  562. Subject: re: standardization (PC)
  563.  
  564. >From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
  565.  
  566. >I think there is already a naming scheame present.
  567. >It gose like this:
  568. >McAfee gets a virus, Releases the next VIRLIST.TXT, and
  569. >everyone just uses it. If a new virus apears that is not
  570. >there, a name is given to it according to its behaviour,
  571. >and so on...
  572.  
  573. Oh, do I wish it were that simple!  The main problems are:
  574.  
  575.   - Say some authority says "we've found a new virus, its
  576.     name is Blivet, and our scanner detects it as such".
  577.     Now someone else finds a virus, and that scanner identifies
  578.     it as "Blivet".  Is it the same virus that the authority
  579.     first reported?   The only way to tell for sure is if
  580.     that person has access to the original Blivet sample
  581.     (and virus collections probably shouldn't be
  582.     generally-available), or if someone has written a
  583.     program that does precise identification of the virus.
  584.     Writing such a program (or adding a description to an
  585.     existing program) is quite a bit more work than just
  586.     extracting a signature for a scanner, and there are
  587.     some complex issues about avoiding spoofing.
  588.  
  589.     Does the user care whether or not he really has
  590.     the same Blivet virus as was originally named?
  591.     Yes!  The new Blivet might have different behavior,
  592.     requring different clean-up, and the user *must*
  593.     know that.  "Cleaning up" a virus without knowing
  594.     exactly what it does is a contradiction in terms.
  595.  
  596.   - Naming viruses based on behavior isn't as easy as
  597.     it sounds.  Here's a brand-new virus.  It goes
  598.     resident, and infects any file that's executed.  It
  599.     has no payload.  What do you call it?  There are
  600.     probably hundreds of viruses that like.  Naming
  601.     continues to be a hard problem; a good name would
  602.     be easy to remember, different from other names,
  603.     and have something to do with what the virus does.
  604.     It's generally impossible to do all three, though...
  605.  
  606. DC
  607.  
  608.  
  609. ------------------------------
  610.  
  611. Date:    Thu, 04 Mar 93 18:27:48 +0000
  612. From:    cskahrs@sunvis1.vislab.olemiss.edu (John H. Kahrs)
  613. Subject: Re: Virus Development Programs (PC)
  614.  
  615. sgt@lakes.trenton.sc.us (Sgt Rock) writes:
  616.  
  617. >I just picked up the March 16th 93 issue of PC Magazine and was quite 
  618. >interested in the article on antivirus software. It discussed some virus 
  619. >development programs: The Phalcon/Skism Mass-Produced Code Generator, the 
  620. >Virus Construction Set, and the Virus Construction Laboratory.
  621. >These programs sound scarey to me. Does anyone out there know anything 
  622. >about them? Where do they originate and are they available for general 
  623. >use or are they controlled as they should be?
  624.  
  625. The code created by these programs are shotty at best. They weren't
  626. designed to create inovative viruses, there are a fixed number of
  627. possible viruses that can be created and ALL are based on existing
  628. models. I doubt that these programs are a threat at all. The people
  629. that know anything about coding viruses will never use them and the
  630. hatefull people that just want to make a virus for malicous reasons
  631. aren't connected to the community that makes the virus construction
  632. kits available. To be totaly safe from these programs, all one has to
  633. do is create EVERY type of virus possible, and include them in
  634. scanning programs. I admit this is not a very practical soulution, BUT
  635. I can't think of another way off the top of my head.
  636.  
  637. - -----------------------------------------------------------------------------
  638. JJ Kahrs                  "Virtual Reality is like electronic LSD!"
  639. Computer Science                -News Journalist
  640. OleMiss                   "VR doesn't have as good a price/performance ratio."
  641. jj@tacky.cs.olemiss.edu         -VR Researcher
  642. cskahrs@sunvis1.vislab.olemiss.edu
  643. - -----------------------------------------------------------------------------
  644.  
  645. ------------------------------
  646.  
  647. Date:    Thu, 04 Mar 93 18:21:23 +0000
  648. From:    blake@nevada.edu (Rawlin Blake)
  649. Subject: Re: wordperfect virus? (PC)
  650.  
  651. GMS@PSUVM.PSU.EDU (Gerry Santoro - CAC/PSU 814-863-7896) writes:
  652. >After scanning the past years worth of VIRUS-L offerings I've seen
  653. >this question asked before, but with no reply.  Since it has now hit
  654. >at my institution I will ask it again in the hopes that someone knows
  655. >what is happening.
  656. >
  657. >A number of our lab machines are exhibiting very strange WordPerfect
  658. >behavior.  For example, very small user documents are growing to
  659. >extremely large size, until they fill up available disk space.  Scans
  660. >with F-PROT do not identify any known virus.
  661. >
  662. >Can anyone clue me into what is happening?  In all cases the version
  663. >of WP5.1 is being run from a read-only volume of a Banyan network
  664. >server.
  665.  
  666. This one is easy, I see it all the time.
  667.  
  668. The users are doing one of two things-- using shift-F10 and continually 
  669. retrieving the file within itself, or are doing the same thing in F5 list 
  670. files by ignoring the prompt "retrieve into current document?"
  671.  
  672. This is another example of what I teach in my classes and seminars. 99% of 
  673. all virus reports are: 1. user error 2. software problems 3. hardware 
  674. problems.
  675.  
  676. - ---
  677. Rawlin Blake    blake@nevada.edu
  678.  
  679. No .sig is a good .sig
  680.  
  681. ------------------------------
  682.  
  683. Date:    04 Mar 93 19:04:58 +0000
  684. From:    kerchen@k2.cs.ucdavis.edu (Paul Kerchen)
  685. Subject: Re: Virus Development Programs
  686.  
  687. sgt@lakes.trenton.sc.us (Sgt Rock) writes:
  688. >I just picked up the March 16th 93 issue of PC Magazine and was quite 
  689. >interested in the article on antivirus software. It discussed some virus 
  690. >development programs: The Phalcon/Skism Mass-Produced Code Generator, the 
  691.  
  692. >From the PC-MPC documentation:
  693.     The Phalcon/Skism Mass-Produced Code Generator is a tool which
  694. generates viral code according to user-designated specifications.  The
  695. output is in Masm/Tasm-compatible Intel 8086 assembly and it is up to
  696. the user to assemble the output into working executable form.  The
  697. features of the PS-MPC include the following:
  698.     - Over 150 encryption techniques, randomly generated during
  699. each run of the PS-MPC
  700.     - Compact, commented code, much tighter than VCL
  701.     - COM/EXE infections
  702.     - Two types of traversals
  703.     - Optional infection of Command.Com
  704.     - Critical error handler support
  705.  
  706. >Virus Construction Set, and the Virus Construction Laboratory.
  707.  
  708. Don't know about VCS (isn't that an Atari thing?), but VCL came before 
  709. PC-MPC and is similar (but with less features) to PC-MPC.
  710.  
  711. >about them? Where do they originate and are they available for general 
  712. >use or are they controlled as they should be?
  713.  
  714. Depends on what you mean by 'controlled'.  VCL comes encrypted in a
  715. zip file that requires a password to unzip it.  The 'bad guys' want to
  716. keep this toy to themselves.  Other than that, though, all of these
  717. should be available at your local underground BBS (certainly VCL and
  718. PS-MPC are).  So, I guess you could say there are no controls in the
  719. sense that you mean.
  720.  
  721.    |          "Disembodied gutteral noise need not make sense"          |
  722.    |                     Paul Kerchen                  |
  723.    |                     kerchen@cs.ucdavis.edu              |
  724.  
  725. ------------------------------
  726.  
  727. Date:    Thu, 04 Mar 93 19:44:57 +0000
  728. From:    nmalde@hobbes.kzoo.edu (Nutan Malde)
  729. Subject: Identification needed for a Virus Message (PC)
  730.  
  731. Recently one of our 486 machines displayed the following message:
  732.          Infected!!
  733.          There is a passkey to this virus.  Enter the correct
  734.          key word and the effects of the virus will cease.
  735.  
  736. When we issued the command to change directories it would append the
  737. word "Infected" to the directory path.  It would not let us use the A or B
  738. drives.  I ran the latest version of F-Prot and it reported no
  739. infections.  Can anyone shed some light on which virus this could be?
  740.  
  741. I deleted the command.com and copied a clean version of command.com and
  742. that seemed to get rid of the Infected message and we were able to 
  743. use all our programs again which it wouldn't let us before.  However, I
  744. am curious as to whether it is a virus or is someone changing stuff on 
  745. our system?
  746.  
  747. Any help would be appreciated,
  748. Thanks in advance
  749.  
  750. Nutan Malde
  751. nmalde@kzoo.edu
  752.  
  753.  
  754. - -- 
  755. **************************************************************************
  756. Nutan Malde        Kalamazoo College             
  757. Internet Address:      nmalde@kzoo.edu
  758. **************************************************************************
  759.  
  760. ------------------------------
  761.  
  762. Date:    Thu, 04 Mar 93 10:39:12 +0200
  763. From:    eugene@kamis.msk.su (Eugene V. Kaspersky)
  764. Subject: Re: Effect of Form (PC)
  765.  
  766. > We have just discovered that we have been infected by a strain of
  767. > FORM. We do, however, suffer from lack of informaion about the effects
  768. > of the virus.  The virus infects the boot sector and I just read that
  769. > it activates on certain days of the month, but what is the actual
  770. > action of the virus when it activates?
  771.  
  772. This is a very dangerous virus. It hits Boot-sector of floppy disks during
  773. an access to them and Boot-sector of the hard disk on a reboot from an
  774. infected floppy disk. The virus acts on the 24th of every month. It
  775. processes a dummy cycle while pressing on the keys. If you work with a hard
  776. disk, the data can be lost. The virus hooks int 9 and int 13h. It contains
  777. the text "The FORM-Virus sends greetings to everyone who's reading this
  778. text.FORM doesn't destroy data! Don't panic!  Fuckings go to Corinne."
  779.  
  780. > This brings me to my next qestion: I it possible to obtain a file
  781. > somewhere giving a brief description of the action of various vira. I
  782.  
  783. How about 300K of ZIP ?  :-)
  784.  
  785. > Another last qestion: Is there any informaiton around about the virus
  786. > TP4 (TP44)?
  787.  
  788. It's Yankee Doodle virus.
  789.  
  790. Regards,
  791. Eugene
  792. - -- 
  793. - -- Eugene Kaspersky, KAMI Group, Moscow, Russia
  794. - -- eugene@kamis.msk.su +7 (095)499-1500
  795.  
  796. ------------------------------
  797.  
  798. Date:    Thu, 04 Mar 93 18:06:15 -0500
  799. From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
  800. Subject: Removal of Michelangelo (PC)
  801.  
  802. imeslsl@trex.oscs.montana.edu (LEPRICAN~~~) writes:
  803.  
  804. > time.  We tried McAfee v100, which would recognise the virus, but
  805. > would not remove it from hard drives.  It appears to be [Mich] when
  806. > it is on a drive, but when it loads itself into memory, McAfee says
  807. > it's [STONED].
  808.  
  809. > It seems to be easily removed from floppies, but the virus infects
  810. > the partition table of hard drives, where McAfee cannot remove it.
  811.  
  812. > Does anyone have any suggestions on how to combat this virus?
  813.  
  814. It amazes me that anyone could still be unable to remove this virus.  
  815. Our program VET will remove it (and all the other remotely common 
  816. viruses) completely safely and almost automatically.  
  817.  
  818. The original version (released in early 1989) put back the whole of 
  819. the hidden boot sector and I occasionally got reports of cases where 
  820. it had left a PC unbootable after removing Stoned.  
  821.  
  822. Eventually I was able to examine a case where this had happened, and 
  823. worked out that dealers were booting from an infected master disk 
  824. before partitioning the hard disk.  This meant that the partition 
  825. information in sector seven was no longer correct, and if you put 
  826. it back you would be unable to access the hard disk.  
  827.  
  828. I promptly modified the program so it only puts back the partition 
  829. info if it knows the virus overwrites it, and released a revised 
  830. version in July 1989.  We discovered (and named) Michelangelo, and 
  831. released a version of VET which dealt with it in February 1991.  
  832.  
  833. Since 1989 our support staff have listened to hundreds of users 
  834. remove Stoned, Michelangelo and sundry other boot sector viruses, 
  835. and innumerable file viruses, and we can't remember any user 
  836. reporting that VET had rendered a previously accessible hard disk 
  837. inaccessible.  
  838.  
  839. Although the dangers of putting back the whole of sector seven have 
  840. been well known for at least two years (1.), Clean still does so, 
  841. and still does not bother to check that sector seven is not itself 
  842. infected.  We have verified that both faults are still present in 
  843. Clean 9.1V100.  
  844.  
  845.  
  846. Roger Riordan                 Author of the VET Anti-Viral Software.
  847. riordan.cybec@tmxmelb.mhs.oz.au
  848.  
  849.  
  850. 1. R.H.Riordan  VET; a program to detect & remove computer viruses.  
  851. Proc 4th Annual Computer Virus & Security Conference. NY 1991
  852.  
  853. CYBEC Pty Ltd.                                 Tel: +613 521 0655
  854. PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727
  855.  
  856. ------------------------------
  857.  
  858. Date:    Thu, 04 Mar 93 12:48:27 -0800
  859. From:    Richard W. Lefkon <dklefkon@well.sf.ca.us>
  860. Subject: Financial firms open meeting Thursday on Trace Center recovery
  861.  
  862.  SIXTH INTERNATIONAL COMPUTER SECURITY & VIRUS CONFERENCE and Exposition
  863.           sponsored by DPMA Fin.Ind.Chapter in cooperation with
  864. ACM-SIGSAC, BCS, CMA, COS, EDPAAph, ISSAny, NUInyla, IEEE Computer Society
  865.        Box 894 Wall Street Station, NY NY 10268 (800) 835-2246 x190
  866.                                                 
  867.     
  868.      FINANCIAL FIRMS OPEN MEETING THURSDAY ON TRADE CENTER RECOVERY
  869.      --------------------------------------------------------------
  870.  
  871. To address the technical side of network and computer terrorism recovery 
  872. while information systems personnel are interested, a special public forum    
  873. of industry leaders has been scheduled for next Thursday March 11, entitled,
  874. "Trade Center Crisis Recovery."  The in-depth panel will include eight 
  875. industry representatives - from four affected financial firms that successfully
  876. resumed business after Friday's disaster, and four suppliers that helped them
  877.  
  878. The panel will be housed in next week's Sixth International Computer Security
  879. & Virus Conference at the Madison Square Garden Ramada, co-sponsored by the 
  880. eight computing and networking societies.
  881.  
  882. With damage estimates already in the multi-billions, Sally Meglathery, Elec-
  883. tronic Security Head for the New York Stock Exchange and a scheduled panelist,
  884. warns financial data keepers:  "Review [your] restart recovery procedures to
  885. be sure that you have adequate backup to recover from an attack."
  886.  
  887. Other than state and federal offices, the main corporations inhabiting the
  888. famed skyscraper are indeed banks (First Boston, Sumitomo, Dai-ichi), brokers
  889. (Dean Witter, Shearson, Salomon, Mocatta and the Commodities Exchange) and
  890. insurance companies (Hartford and Guy Carpenter).  Each type will send a
  891. representative, as will some service firms.
  892.  
  893. William Houston, Eastern Region Head for Comdisco Data Recovery, notes that
  894. "This is the second time in three years an electrical disaster has completely
  895. shut down" the famed twin skyscraper.  His firm helped rescue the computer, 
  896. networking and "back office" operations of two dozen downtown firms in response
  897. to the August 13, 1990, electrical substation fire.
  898.  
  899. "We have some major customers in the Towers," notes Houston, "and while pre-
  900. serving their anonymity I intend to plainly tell the Thursday audience just
  901. what worked this time and what didn't."
  902.  
  903. Michael Gomoll, an executive with competitor CHI/COR Information Management,
  904. says the terrorist act will have three key results:  "Direct loss of
  905. revenues, effects on global markets and businesses, and concerns of the
  906. business insurance profession."  Ironically, CHI/COR, a firm specializing 
  907. in disaster recovery, was itself assaulted by the crippling Chicago flood 
  908. of April 13, 1992.  As part of his presentation, Gomoll intends to explain
  909. how cable conduits played an important role in both disasters.
  910.  
  911. Last fall, the conference now hosting this "Trade Center Crisis Recovery"
  912. roundtable, received what now seem prophetic words in its greeting from Mayor
  913. David Dinkins:  "As the telecommunications capital of the world . . . we are
  914. also extraordinarily susceptible to the various abuses of this technology."
  915.  
  916. Another irony has to do with the "Meet the Experts" reception at the
  917. Empire State Building Observatory following the forum.  In previous years,
  918. the hosting conference has had its skyline reception at Top of The World,
  919. located within the Trade Center.  That spot will not open this month. 
  920. also extraordinarily susceptible to the various abuses of this technology."
  921.  
  922. ------------------------------
  923.  
  924. End of VIRUS-L Digest [Volume 6 Issue 40]
  925. *****************************************
  926.  
  927.  
  928. Downloaded From P-80 International Information Systems 304-744-2253
  929.