home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.133 < prev    next >
Text File  |  1995-01-03  |  13KB  |  317 lines
  1. VIRUS-L Digest              Friday, 9 Jun 1989         Volume 2 : Issue 133
  2.  
  3. Today's Topics:
  4. Re: naming confusion
  5. Re: Your assistance please...
  6. GateKeeper
  7. re: possible virus (pc)
  8. Software companies writing nasty s/w
  9. Warning New Virus (PC)
  10. RE: Possible virus? (PC)
  11. more on developers releasing viruses
  12. Upcoming Flu_Shot+ version (PC)
  13.  
  14. ---------------------------------------------------------------------------
  15.  
  16. Date:    Thu, 8 Jun 89 12:55:58 PDT
  17. From:    rmorey@ORION.CF.UCI.EDU
  18. Subject: Re: naming confusion
  19.  
  20.   Regarding the "PLO" virus and your suggestion that we not call it by
  21. that name, don't you think that your desire to suppress the link
  22. between the virus and something which obviously offends you (the name
  23. "PLO") is a political tactic?  That particular virus is known to many
  24. people already as the "PLO virus"--now you expect them to have to
  25. worry about changing that name in their minds because it offends
  26. someone?
  27.   Don't forget that viruses offend everyone, most certainly everyone
  28. who reads this net.  We all have a common interest in combating
  29. viruses and their spread but I really doubt that we are going to spend
  30. much time worrying about their names.  I apologize if this offends you
  31. but, given both my interest in international politics and my work in
  32. computers, I don't see how both should be meshed or affected at such a
  33. perfunctory level.
  34.                                               Robert J. Morey
  35.  
  36. [Ed. In mentioning the confusion in the naming convention for viruses,
  37. I never intended to start a political discussion/war - let's please
  38. not turn this into one.]
  39.  
  40. ------------------------------
  41.  
  42. Date:    Thu, 8 Jun 89 22:21:25 +0200
  43. From:    Johan Bengtsson <d85-ben@sm.luth.se>
  44. Subject: Re: Your assistance please...
  45.  
  46. Name of Virus:  Israeli Virus (I belive)
  47.  
  48. Computers/OS:   Does run on IBM compatibles with DOS operating system.
  49.                 (though not when using the Novell network, interupt conflict)
  50.  
  51. Virus activity: After infection, every program run received a copy of the
  52.                 virus.  One type of executables (EXE files) were infected
  53.                 many times.  This led to the eventual discovery of the virus.
  54.  
  55.                 The sick systems did have a "symptom"; about two times each
  56.                 hour a small part of the screen was blanked out.
  57.  
  58.                 Each Friday 13th, after an initial delay of about 30 min,
  59.                 *every* program run was *deleted*.  This did not happen to
  60.                 us, countermeasures were applied in time.
  61.  
  62. Countermeasures:A "vaccine" was developed by me, after disassembly of the
  63.                 virus code.  This detected and prevented further infections.
  64.  
  65.                 An "antidote" program was developed by the Comp. Dep. which
  66.                 was able to restore most infected programs.
  67.  
  68.                 Later, we discovered that a "vaccine" and "antidote" had
  69.                 already been developed at an Israeli University.
  70.  
  71. Place of events:University of Lulea, Sweden, October 1988
  72.  
  73. My name:        Johan Bengtsson, at the time a last year student in Comp. Sc.
  74.  
  75. Good luck with the book!
  76.  
  77. - --BEN
  78.  
  79. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  80. Johan Bengtsson             University of Lulea, SWEDEN
  81. Forskarvagen 149B
  82. S-951 63  LULEA        Domain:          d85-ben@luth.se
  83. SWEDEN                 Path: mcvax!enea!luth.se!d85-ben
  84. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  85.  
  86. ------------------------------
  87.  
  88. Date:    Thu, 8 Jun 89 16:14:25 -0500
  89. From:    chrisj@emx.utexas.edu (Chris Johnson)
  90. Subject: GateKeeper
  91.  
  92. >Though this is probably old news, I'd recommend adding GateKeeper to
  93. >your INITs.  Though it's absolutely transparent for all disc writes
  94. >you tell it to allow, it forbids completely any writes it doesn't know
  95. >to be authorised.  As soon as I discovered how effective it is, I
  96. >removed Vaccine from my system: GateKeeper is much more thorough (as
  97. >it checks the writing of *any* resource, not just CODE) and much less
  98. >intrusive.
  99. >
  100. >Best of luck with your disinfection.
  101. >
  102. >Alastair Milne
  103.  
  104. If you liked GateKeeper 1.1, you'll really like GateKeeper 1.1.1.
  105. It's been in testing (in various stages of completion) for several
  106. months now and should be available in the next few weeks.  One
  107. (potentially) troublesome bug has been fixed and a good number of
  108. enhancements have been added.  More details on 1.1.1 later.
  109.  
  110. By the way, you're right that GateKeeper doesn't *just* protect CODE
  111. resources, but it's not true that it protects *all* resources.
  112. Protecting all resources is unnecessary (besides, you wouldn't want to
  113. have to grant privileges to every program that modifies one of its own
  114. 'STR ' resources).  What GateKeeper does do is protect every type of
  115. resource known to contain executable code (there're about 26 of them,
  116. running from INIT and CODE (which you might expect viruses to attack)
  117. to others like 'snth' and 'MBDF' (which you might not)).  [Anyone
  118. interested in the exact list can check GateKeeper's 'Type' 1
  119. resource.]  Fortunately, most of these protections are unnecessary
  120. against the current crop of viruses (and let's hope it stays that
  121. way), but the protections are there just the same (to help make sure
  122. it *does* stay that way).
  123.  
  124. In response to another question I noticed a few articles down,
  125. GateKeeper is available for anonymous ftp from Sumex, Simtel,
  126. emx.utexas.edu and rascal.ics.utexas.edu.  If these won't work for
  127. you, you can always send me (Chris Johnson) mail as
  128. chrisj@emx.utexas.edu and I'll send you a copy.
  129.  
  130. Cheers,
  131. - ----Chris (Johnson)
  132. - ----Author of GateKeeper
  133.  
  134. ------------------------------
  135.  
  136. Date:    Thu, 08 Jun 89 16:09:40 CDT
  137. From:    "Rich Winkel    UMC Math Department" <MATHRICH@UMCVMB>
  138. Subject: re: possible virus (pc)
  139.  
  140. >        Another wierdness (or maybe not).  If you are (BY THE WAY, WE
  141. >ARE TALKING ABOUT IBM CLONES) booting up from a bootable diskette (not a
  142. >full DOS disk) with no config.sys file, does it get the files and buffers
  143. >limits from the dos disk that originally made the bootable disk?  It
  144. >must, obviously.  Where does it keep this stuff?
  145.  
  146. No, it just uses default values hardcoded in dos.  The default for buffers
  147. is 2 for a PC, 3 for an AT. The default for files is 8.
  148.  
  149. Rich
  150.  
  151. ------------------------------
  152.  
  153. Date:    ???, 02 Jan 80 17:06 EDT
  154. From:    Bob Stratton <BSTRATTO@NAS.BITNET>
  155. Subject: Software companies writing nasty s/w
  156.  
  157. In VIRUS-L Digest, Thursday, 8 Jun 1989, Volume 2 : Issue 132:
  158.    odawa@well.sf.ca.us (Michael Odawa) writes:
  159.  
  160. > Let us set the record straight on this subject:
  161.  
  162. > No known software publisher has ever intentionally released a virus
  163. > into circulation, nor is it likely that any would do so, as it would
  164. > be contrary to their interests.  Viruses threaten the entire software
  165. > industry and expose the releasing party to an enormous legal
  166. > liability.
  167.  
  168. While the following information pertains specifically to a trojan
  169. horse, it is a prime example of a software company (or at the very
  170. least - individuals at a software company) writing deleterious
  171. software to further personal aims.
  172.  
  173. I quote from the "Dirty Dozen List, Revision 8D";
  174.  
  175. SUG.ARC  - "    Words can not express my feelings about this trojan.
  176.             SUG.ARC advertises that it can break SOFTGUARD copy protection,
  177.             but upon invocation, it will scramble the FATs on drive A, B,
  178.             C, and onwards to your highest drive.
  179.  
  180. - ---->           While this is certainly  a nasty trojan, it is particularly
  181. - ---->       repulsive because SOFTGUARD, CORP, THE CREATORS OF SOFTGUARD
  182. - ---->       COPY-PROTECTION, WROTE IT - perhaps in response to declining
  183. - ---->       business. [My emphasis - RJS III]
  184.  
  185.                 They claim that anyone who runs SUG is breaking an
  186.             original license agreement; therefore they may legally destroy
  187.             data.
  188.  
  189.                 I don't credit this, and neither does an attorney I
  190.             know, so I eagerly anticipate Softguard's day in court."
  191.  
  192. I wouldn't normally credit rumors of this sort, but this list has
  193. generally been well-researched, and the author(s) seem(s) to put a lot
  194. of time into verification of the reports he receives.
  195.  
  196. Cheers,
  197. Bob
  198. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  199. Robert J. Stratton, III   BITNET:   BSTRATTO@NAS
  200. Stratton Systems Design   INTERNET: BSTRATTO%NAS.BITNET@UUNET.UU.NET
  201. Alexandria, VA, USA       USENET:   uunet!NAS.BITNET!BSTRATTO
  202.                           PSTNET:   1-202-334-3638
  203. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  204. "Software is like entropy. It is difficult to grasp, weighs nothing, and
  205.  obeys the Second Law of Thermodynamics; i.e., it always increases."
  206.  -- Law XVII: "Augustine's Laws" -- Norman R. Augustine --
  207.  
  208. ------------------------------
  209.  
  210. Date:    THU 08 JUN 1989 18:34:00 EDT
  211. From:    IA96000 <IA96@PACE.BITNET>
  212. Subject: Warning New Virus (PC)
  213.  
  214. Just thought you all might like to know the following:
  215.  
  216. There is a new virus floating around, which attacks WP.EXE in
  217. particular and almost every other .EXE file it comes in contact
  218. with. It is self propogating and trashes files and disks.
  219.  
  220. Some of the things to look for are as follows:
  221.  
  222. 1) Strange blue/green blocks appear on the screen.
  223. 2) Running a .EXE you know is on the disk and getting a
  224.    "File not found" error even though the .EXE is on the disk.
  225. 3) After 30 to 45 minutes everything seems to slow down. Doing
  226.    a DIR takes 30 or 40 seconds for each line to appear.
  227. 4) It definitely spreads between .EXE files, although it
  228.    appears .COM files are immune.
  229. 5) It will spread to all types (sizes) of floppy disk drives
  230.    and will jump to a hard drive.
  231. More later...
  232.  
  233. ------------------------------
  234.  
  235. Date:    Thu, 8 Jun 89 21:40:26 -0400
  236. From:    Joe Sieczkowski <joes@scarecrow.csee.Lehigh.EDU>
  237. Subject: RE: Possible virus? (PC)
  238.  
  239. >        Another wierdness (or maybe not).  If you are (BY THE WAY, WE
  240. >ARE TALKING ABOUT IBM CLONES) booting up from a bootable diskette (not a
  241. >full DOS disk) with no config.sys file, does it get the files and buffers
  242. >limits from the dos disk that originally made the bootable disk?
  243.  
  244. If there is no config.sys file on a bootable disk, DOS just uses
  245. the default buffer and file sizes which are quite small.  It does
  246. not keep them from the original DOS disk that made it bootable.
  247.  
  248. Dbase requires a minimium file and buffer size in order for it to run
  249. properly.  Every bootable Dbase disk should have a config.sys file on
  250. it to meet these requirements. This might have been the cause of your
  251. problem.
  252.  
  253. Joe
  254.  
  255. ------------------------------
  256.  
  257. Date:    Thu, 08 Jun 89 23:30 CDT
  258. From:    Gordon Meyer   <TK0GRM1@NIU.BITNET>
  259. Subject: more on developers releasing viruses
  260.  
  261. At the risk of beating a dead horse, and restating a position that
  262. I made quite clear in my first posting, I feel I must respond
  263. in some form to the message from Michael Odawa of the "Software
  264. Development Council of North America".
  265. Rather than issue political statements about the possibilities I'll
  266. refer interested readers to the article I was speaking of.  Despite
  267. Mr. Odawa's claims, there is evidence of "unknown" developers doing
  268. just what I outlined.  I remind him, and all readers, that such
  269. evidence does *not* constitute proof.  Can we agree that it is
  270. undesirable, but not impossible?
  271. - -=->G<-=-
  272.  
  273. "The Revenge of the Developers"
  274. _Current Notes_  Volume 8. Number 6.  August 1988
  275.  Back issues available for $2.50 from:
  276.  Current Notes, Inc.
  277.  122 N. Johnson Rd.
  278.  Sterling, VA 22170
  279.  
  280. Standard disclaimers apply.
  281. - --------------------------------------------------------------------
  282. | Gordon R. Meyer, Northern Illinois University, Dept of Sociology |
  283. | GEnie: GRMEYER, CIS: 72307,1502, Phone: (815) 753-0555           |
  284. | Bitnet: Tee-Kay-Zero-Gee-Are-Em-One AT Enn-Eye-You.bitnet        |
  285. |------------------------------------------------------------------|
  286.  
  287. ------------------------------
  288.  
  289. Date:    Thu, 8 Jun 89 15:00:24 EDT
  290. From:    utoday!greenber@uunet.uu.net (Ross Greenberg)
  291. Subject: Upcoming Flu_Shot+ version (PC)
  292.  
  293. Rob, a future version of FLU_SHOT+ will be available in the next few
  294. months to a)search your hard disk (upon request) to look for strains
  295. of a virus I know about and b)remove that virus from the infected
  296. program if possible.  Same thing goes for Boot Sector Viruses, too.
  297.  
  298. However, since I can only program in such a manner against viruses I
  299. know of, a new virus would not be noticed or removed.  Each new virus
  300. I found would require a new version of FLU_SHOT+, and (after ten
  301. versions!) I'm sure some people are looking at the incremental
  302. benefits and presuming it isn;t worth the expense in time to update.
  303. I know that I'm sorta cautious not to release trivial updates, and I
  304. presume that the majority of the other anti-virus people must have the
  305. same attitude.
  306.  
  307. Ross M. Greenberg
  308. Author, FLU_SHOT+
  309.  
  310. ------------------------------
  311.  
  312. End of VIRUS-L Digest
  313. *********************
  314.  
  315.  
  316. Downloaded From P-80 International Information Systems 304-744-2253
  317.