home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.06 < prev    next >
Text File  |  1995-01-03  |  28KB  |  590 lines

  1. VIRUS-L Digest   Monday,  8 Jan 1990    Volume 3 : Issue 6
  2.  
  3. Today's Topics:
  4.  
  5. re: comment by William Hugh Murray
  6. Re: Spafford's Theorems
  7. Gatekeeper Privileges (MAC)
  8. Questioning ethics at computing sites
  9. The Amstrad virus (PC)
  10. Re: Where to Get Mac Anti-Virals
  11. Jerusalem B problem (PC)
  12. Re: Authentication/Signature/Checksum Algorithms
  13. Re: Virus Trends (and FAXes on PCs)
  14. Alternative Virus Protection (Mac)
  15. Murray's Theorems (Was Re: Spafford's Theorems)
  16. Implied Loader 'Pack' Virus (Mac)
  17. Re: Virus Trends (and FAXes on PCs)
  18. Re: Viruses Rhyme And Reason
  19.  
  20. VIRUS-L is a moderated, digested mail forum for discussing computer
  21. virus issues; comp.virus is a non-digested Usenet counterpart.
  22. Discussions are not limited to any one hardware/software platform -
  23. diversity is welcomed.  Contributions should be relevant, concise,
  24. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  25. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  26. anti-virus, document, and back-issue archives is distributed
  27. periodically on the list.  Administrative mail (comments, suggestions,
  28. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  29.  - Ken van Wyk
  30.  
  31. ---------------------------------------------------------------------------
  32.  
  33. Date:    Thu, 04 Jan 90 23:01:00 -0500
  34. From:    "Gerry Santoro - CAC/PSU 814-863-4356" <GMS@PSUVM.PSU.EDU>
  35. Subject: re: comment by William Hugh Murray
  36.  
  37. In V3 N1 of Virus-L Digest, William Hugh Murray wrote:
  38.  
  39. >2. The press speculation about the DATACRIME virus was much more
  40. >damaging than the virus.
  41.  
  42. For the sake of academic argument I would dispute this.  I agree that the
  43. actual damage from Datacrime (or Oct 13 or whatever) was minimal, and
  44. virtually nonexistent on our campuses, and I would also agree that there
  45. was mucho media hype.  However, I really think that there was a major
  46. benefit to all of this.
  47.  
  48. As Mr. Murray correctly pointed out, much more users damage their own
  49. data than are damaged by 'nasty' software.  The Oct 13 scare made our users,
  50. who number in the tens of thousands,  FINALLY listen to our pleadings
  51. to make backup copies of their software and data.
  52.  
  53. The situation is similar to that with seat belts.  Few of us are actually
  54. in an accident, but if we see one (or the effects) it may cause us to wear
  55. the belts, which *may* save our lives.  In the case of the Oct 12  virus
  56. we had one grand  chance to get people to listen to our message regarding
  57. making backups and preparing for the chance of disaster, whether by
  58. accident, ignorance, hardware failure or 'nasty' software.
  59.  
  60. -
  61.  -------------------------------------------------------------------------------
  62. |   |        gerry santoro, ph.d.  --  center for academic computing      |   |
  63. | -(*)-  penn state university -- gms@psuvm.psu.edu -- gms@psuvm.bitnet -(*)- |
  64. |   |             standard disclaimer -->  "I yam what I yam"             |   |
  65. -
  66.  -------------------------------------------------------------------------------
  67.  
  68. ------------------------------
  69.  
  70. Date:    Fri, 05 Jan 90 04:46:06 +0000
  71. From:    soup@penrij.LS.COM (John Campbell)
  72. Subject: Re: Spafford's Theorems
  73.  
  74. WHMurray@DOCKMASTER.ARPA writes:
  75. > 1. The amount of damage to data and availability done by viruses to date
  76. > has been less than users do to themselves by error every day.
  77.  
  78.         OK, OK.  True enough, though we don't often like to be reminded of
  79.         this.
  80.  
  81. > 4. Viruses and rumors of viruses have the potential to destroy society's
  82. > already fragile trust in our ability to get computers to do that which
  83. > we intend while avoiding unintended adverse consequences.
  84.  
  85.         This is the most worrying aspect of virus/trojan/worm infections.
  86.         We have a population which has no intrinsic immune system which
  87.         leaves itself open to such attack.  Vectors now consist of
  88.         communications networks (BBS and other means) as well as physical
  89.         media.  Since we are moving towards a networked future we will
  90.         need immune systems in our computers-  society (all of us) are
  91.         currently subject to these terrorist acts (like the tylenol
  92.         scare).  Remember-  any linchpin/choke point in technology, be
  93.         it transportation, food delivery, water supply, communications
  94.         is subject to interruption by killers.  Set some of these loose
  95.         in a Hospital and the virus writer is _at least_ as dangerous
  96.         as the individual who slips cyanide into food and drug products.
  97.  
  98. > 5. We learn from the biological analogy that viruses are self-limiting.
  99.  
  100.         We also learn that when the population is large enough for the
  101.         entity to take advantage of, an entity will attempt to take
  102.         hold.  Once we had standard PC's (and Macs, Amigas, etc) we
  103.         then had a "fixed" cellular mechanism to subvert.  S-100 systems
  104.         which lacked such standardization were not subject;  even the
  105.         "standard" S-100 systems did not constitute a large enough
  106.         population to invite attack...
  107.  
  108. > Clinically, if you catch a cold, you will either get over it, or you
  109. > will die.  Epidemiologically, a virus in a limited population
  110. > will either make its hosts immune, or destroy the population.  Even in
  111. > open population, a virus must have a long incubation period and slow
  112. > replication in order to be successful (that is, replicate and spread).
  113.  
  114.         Point taken.  A virus, since it _does_ act in the system as
  115.         non-invasively as possible (beyond spreading its "genetic code"
  116.         wherever possible) will be fairly successful.  Subtlety pays
  117.         off.  Of course, these viruses are much like the HIV will eventually
  118.         kill the host...
  119.  
  120. - --
  121.  John R. Campbell       ...!uunet!lgnp1!penrij!soup       (soup@penrij.LS.COM)
  122.                  "In /dev/null no one can hear you scream"
  123.  
  124. ------------------------------
  125.  
  126. Date:    Fri, 05 Jan 90 07:57:45 -0500
  127. From:    V2002A@TEMPLEVM.BITNET
  128. Subject: Gatekeeper Privileges (MAC)
  129.  
  130. Hi,
  131.  
  132.      Before I install Gatekeeper, I was wondering if anyone knows
  133. the set of privileges required by the TextPac and PublishPac software.
  134. We are using a Dest page scanner in our public access lab.  The device
  135. is configured SCSI in order to talk to the MAC II so I think I'm correct
  136. in assuming that in order to scan text and pictures the software will
  137. need to do all sorts of low level stuff.
  138.  
  139.      Anyone else out there with Gatekeeper and a Dest scanner installed?
  140.  
  141.                        Andy Wing
  142.                        Senior Analyst
  143.                        Temple University School of Medicine
  144.  
  145. ------------------------------
  146.  
  147. Date:    Fri, 05 Jan 90 09:28:30 -0500
  148. From:    Jeff_Spitulnik@um.cc.umich.edu
  149. Subject: Questioning ethics at computing sites
  150.  
  151. I write this commentary on ethical issues concerning the dissemination
  152. of information about the existence of viruses and how to get rid of
  153. them as both an employee of the University of Michigan and as a
  154. concerned member of the UM community.  The following scenario
  155. describes the events leading up to my questioning the ethicality of
  156. the procedures (or more appropriately, the lack of procedures) here.
  157. Finally, I ask for comments and suggestions (e.g. how informing the
  158. public is done at your institution) with hopes that the UM policy
  159. makers are listening.
  160.  
  161.   I recently joined the ranks of the many computer experts employed at
  162. the University of Michigan.  About 1 month after I started working
  163. here, I became familiar enough with downloading Mac files from a
  164. public file to notice that there was a new version of Disinfectant.  I
  165. downloaded it and noticed the report of the WDEF virus.  I checked my
  166. personal disks as well as the school owned disks in my public lab ---
  167. all were infected with the WDEF virus.  I sent an e-mail message to
  168. the online_help people (most of which are student "consultants"),
  169. asking them what was to be done.  It was apparent from the response,
  170. that the virus had been here such a short time (a few days?) that no
  171. one was doing anything yet.  I expected a public announcement of some
  172. sort informing users that they may be infected and that they run the
  173. risk of being infected when they use the UM public facilities.  No
  174. announcement was made.  Furthermore, as a specialist employed to
  175. preside over a public computing facility (most of the computers are
  176. Macs), I expected to be both informed that there was a new virus as
  177. well as instructed what to do about it I heard nothing.  Two weeks
  178. after the WDEF virus hit UM, most users were still not aware of it.  I
  179. sent an e-mail message to my most immediate contact in the Information
  180. Technology Division expressing my concerns.  "Shouldn't the public be
  181. informed," I asked.  I expected a response from him and hoped that he
  182. would forward the message on to the appropriate policy makers if he
  183. was not in the position to deal with it himself.  I have not received
  184. a response to my message nor have I heard any public mention of the
  185. WDEF virus.  Users continue to infect the disks in my lab and be
  186. infected by the disks in my lab and, as far as I know, other public
  187. facilities at the Universtiy of Michigan.  The virus persists here.
  188.   What should be done to rid UM of the WDEF virus or of any virus for
  189. that matter?  How does the bureaucracy at your institution handle it?
  190. I question the ethicality of a laissez-faire attitude on viruses at
  191. any institution.
  192.  
  193.   Jeff Spitulnik
  194.  
  195. ------------------------------
  196.  
  197. Date:    Fri, 05 Jan 90 12:13:27 +0000
  198. From:    frisk@rhi.hi.is (Fridrik Skulason)
  199. Subject: The Amstrad virus (PC)
  200.  
  201. I mentioned the Amstrad virus in a recent posting, saying that "..it
  202. has nothing to do with Amstrad computers...". It now appears that it
  203. does.
  204.  
  205. The original (unmodified) version of the virus contains an
  206. advertisement for Amstrad computers.  This text was replaced by a
  207. short message to John McAfee, when the virus was first uploaded to
  208. HomeBase. The name appearing in my original note about the virus is
  209. therefore not the name of the author, but instead the name of a
  210. respected professor in Portugal.
  211.  
  212. - -frisk
  213.  
  214. ------------------------------
  215.  
  216. Date:    04 Jan 90 19:04:45 +0000
  217. From:    briang@bari.Corp.Sun.COM (Brian Gordon)
  218. Subject: Re: Where to Get Mac Anti-Virals
  219.  
  220. XRJDM@SCFVM.BITNET (Joe McMahon) writes:
  221. >Hi, Mike.
  222. >
  223. >We've set up an automatic distribution service here at Goddard. You
  224. >can sign up by sending mail containing the following text to
  225. >listserv@scfvm.gsfc.nasa.gov:
  226. >       [...]
  227.  
  228. Assuming this is available to those of us on usenet, not just bitnet, can you
  229. post a path to "scfvm.gsfc.nasa.gov"?  It doesn't appear to be findable from
  230. my maps.  Thanks.
  231.  
  232. [Ed. I believe that ...!uunet!scfvm.gsfc.nasa.gov would do the trick.]
  233.  
  234. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235. | Brian G. Gordon       briang@Corp.Sun.COM (if you trust exotic mailers)     |
  236. |                       ...!sun!briangordon (if you route it yourself)        |
  237. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.  
  239. ------------------------------
  240.  
  241. Date:    Fri, 05 Jan 90 18:24:23 +0000
  242. From:    861087a@aucs.UUCP (Andreas Pikoulas)
  243. Subject: Jerusalem B problem (PC)
  244.  
  245.           Can someone tell me how do I get rid of the Jerusalem B virus
  246. without getting rid of the infected program too?
  247. I remember someone told me that i have to edit some specific sectors of the
  248. disk in order to deactivate the virus.
  249.  
  250.                                    Thanks in advance
  251.                                          A n d r e a s
  252.  
  253. Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a
  254. TOWER 410       | E-MAIL       : 861087a@AcadiaU.CA
  255. WOLFVILLE-NS    | Phone(voice) : (902) 542-5623
  256. CANADA  B0P 1X0 | ------- IF YOU CAN'T CONVINCE THEM, CONFUSE THEM. --------
  257.  
  258. ------------------------------
  259.  
  260. Date:    05 Jan 90 17:26:20 +0000
  261. From:    well!rsa@lll-crg.llnl.gov (RSA Data Security)
  262. Subject: Re: Authentication/Signature/Checksum Algorithms
  263.  
  264. In response to Y. Radai's post:
  265.  
  266. To protect against viruses, the best protection can be obtained by
  267. using a fast hashing algorithm together with an assymetric
  268. cryptosystem (like RSA).  This is also by far the most cost-effective
  269. (based on compute-time) approach.
  270.  
  271. A good "message digest" should be a one-way function: it should be
  272. impossible to invert the digest and it should be computationally
  273. infeasible to find two useful messages producing the same digest in
  274. any reasonable amount of time.  The algorithm must read every bit of
  275. the message.  Therefore, the best one is the fastest one deemed to be
  276. secure.  This should not be left to individual users to develop as
  277. Jeunemann and Coppersmith, among others, have shown that this is not
  278. a trivial undertaking.  Let's use Snefru and MD2 (Internet RFC 1113)
  279. as examples of good ones.
  280.  
  281. The digest attached to a program or message should then be encrypted
  282. with the private half of a public-key pair.  What is the
  283. computational cost of enhancing this process with public-key?
  284.  
  285. Since RSA can be securely used with small public-key exponents such
  286. as 3 (see Internet RFC's 1113-1115 and/or CCITT X.509) a small number
  287. of multiplies is required to perform a public-key operation such as
  288. *signature verification*, where one decrypts an encrypted digest with
  289. the public key of the sender (and then compares it to a freshly
  290. computed digest).  Therefore, the "added" computational cost of using
  291. RSA on an AT-type machine is approximately 80 milliseconds (raising a
  292. 512-bit number to 3 mod a 512 bit number) REGARDLESS of the size of
  293. the file being verified (the digest is fixed, and less than 512 bits,
  294. requiring one block exponentiation).  Of course the 80 ms gets
  295. smaller on faster machines like Suns.  I think anyone would agree
  296. that that is a fair tradeoff for signer identity verification.  Since
  297. one "signs" files only once, this "cost" is irrelevant.  The cost of
  298. verifying, over and over, is what is important.
  299.  
  300. So what do you get for your milliseconds? You always know the source
  301. of the digest (and you get non-repudiation, providing an incentive to
  302. signers to make sure programs are clean before signing them).  No one
  303. can change a program and recalculate the digest to spoof you.  If
  304. schemes like this became widespread, the lack of signer
  305. identification would be a hole people would quickly exploit.  You
  306. also get a secure way to *distribute* software over networks.  Pretty
  307. hard to do if everyone "does their own thing".  The Internet RFC's,
  308. if widely adopted, provide a perfect mechanism for this.
  309.  
  310. Regardless of the hashing algorithm employed, there are powerful
  311. benefits available if RSA is used with it.  And the computational
  312. cost is negligible.
  313.  
  314. It may be true that simpler methods are adequate for some people.
  315. That determination requires a risk analysis, and people will make
  316. their own decisions.  It has been shown, however, that if a system
  317. can be defeated, it will be.  Certainly secure software distribution
  318. requires something more than an unprotected hash, since keys will
  319. presumably not be shared.  This is where public-key has the most
  320. value.
  321.  
  322. Using X9.9 is OK if (1) you trust DES (2) can live with its speed,
  323. and (3) don't need to distribute trusted software in a large network.
  324. X9.9 key management becomes a serious problem in a network like the
  325. Internet.  It does have the advantage of being a standard, but it was
  326. developed for a relatively small community of wholesale banks, not
  327. large networks.  Note aboput standards: RSA was named as a supported
  328. algorithm in the NIST/OSI Implementor's Workshop Agreements (for
  329. strong authentication, in the Directory SIG) of December 1989.
  330.  
  331. Jim Bidzos
  332. RSA Data Security, Inc.
  333.  
  334. ------------------------------
  335.  
  336. Date:    05 Jan 90 20:07:02 +0000
  337. From:    kelly@uts.amdahl.com (Kelly Goen)
  338. Subject: Re: Virus Trends (and FAXes on PCs)
  339.  
  340. ras@rayssdb.ssd.ray.com (Ralph A. Shaw) writes:
  341. >Nagle@cup.portal.com says:
  342. >
  343. >>     - A FAX message is a bitstream interpreted by an interpreter at
  344. >>       the receving end.  Could it be induced to do something interesting
  345. >>       through the use of illegal bit patterns?  Group III is probably too
  346. >>       simple to be attacked, but group IV?  Imagine a message which
  347. >>       causes a FAX machine to send an extra copy of transmitted documents
  348. >>       to another location.
  349. >
  350. >Something that has come to the attention of security paranoids here
  351. >lately is that some manufacturers of PC FAX boards have added a
  352. >feature that allows the FAX modem to be used as a bisync modem to
  353. >communicate with the PC directly, rather than transmitting just FAXes.
  354. >
  355. >I assume the PC would have to be running some software to enable it
  356. >and reassign the console (requiring local intervention), but a
  357. >networked PC could then prove to be a leak onto the corporate network,
  358. >(or at least, for handy distribution of the Trojan-of-the-month program).
  359. >Added to this is the promise that at least one FAXboard vendor
  360. >promises that both async and bisync modem capability will be available
  361. >in the future.
  362.  
  363. - -I would have clipped more of this but this is a complex subject that merited
  364. serious consideration unlike the infamous modem virus scare of 1988....
  365. actually while a receiving process has to be available on the machine to
  366. be infected(i.e. either the legitimate file transfer program
  367.  or a masquerading process
  368. using this as a means to load further extensions of itself)...the important
  369. point to remember here is that g-3 and g-4 fax formats are from what some of
  370. techs have told me on alt.fax are internally, modified dialects of HDLC
  371. so in this case it is possible that a sufficiently sophisticated infectious
  372. process could use this as a pipeline to load further updates to code...
  373. (i.e. new ways to defeat anti-viral nostrums) I will post ISBN numbers
  374. on the protocol definitions when they finally arrive...as to whether this is
  375. a probable scenario... who knows
  376.    cheers
  377.    kelly
  378. p.s. AS I dont want to cause anyone unecessary worry let me remind all
  379. once again that a receiving process HAS to be on the receiving machine
  380. if it is not the legitimate File XFER program then it is illegitimate
  381. in any case....the point that I am trying to clarify that while
  382. an infectious process could use this as a conduit to an ALREADY EXISTING
  383. infected host... unless there is a way to force execution of the received
  384. code then your virus will lay dormant(i.e.nonexecutable) because of some
  385. fax type file extension on msdos...typically something like .FAX .PIC .PCX
  386. etc....get the picture??? on *nix type systems the problems faced
  387. by the theoretical COMPUTER/FAX-MODEM infectious process are simpler in some
  388. ways but require even more cooperation from receiving processes...
  389.  
  390. ------------------------------
  391.  
  392. Date:    Fri, 05 Jan 90 17:12:07 -0500
  393. From:    "Chris Khoury (Sari's Son)" <3XMQGAA@CMUVM.BITNET>
  394. Subject: Alternative Virus Protection (Mac)
  395.  
  396.       Is there any alternative virus protection, detection init/cdev
  397. besides vaccine and gatekeeper? I need to save space on my disk, so
  398. gatekeeper is too large, but vaccine does not protect me disk from
  399. the other virus's besides Scores and nVir. Any suggestions? I would
  400. prefer that the program is shareware/PD.
  401.  
  402.     Chris Khoury
  403. Acknowledge-To: <3XMQGAA@CMUVM>
  404.  
  405. ------------------------------
  406.  
  407. Date:    03 Jan 90 22:59:29 +0000
  408. From:    ewiles@netxdev.DHL.COM (Edwin Wiles)
  409. Subject: Murray's Theorems (Was Re: Spafford's Theorems)
  410.  
  411.             WHMurray@DOCKMASTER.ARPA writes:
  412. >
  413. >1. The amount of damage to data and availability done by viruses to date
  414. >has been less than users do to themselves by error every day.
  415.  
  416. Granted.  However, self-inflicted damage is generally recognized much sooner,
  417. and is often much easier to repair.  Perhaps more time consuming, but easier
  418. because the user generally needs no special tools that he does not already have
  419. .
  420.  
  421. >6. The current vector for viruses is floppy disks and diskettes, not
  422. >programs.  That is to say, it is the media, rather than the programs,
  423. >that are moving and being shared.
  424.  
  425. This is not entirely so.  There have already been cases where programs were
  426. used as Trojan Horses to initiate viral infections.  Thus, the floppy is not
  427. the only vector.
  428.  
  429. True, a floppy is most often used to pass the program, but that will not always
  430. be the case.  Already, services like Compu$serve are used for exchange of
  431. programs.  Fortunately, the sysops (at least of the amiga groups) test uploaded
  432. software before allowing general access to it. However, such testing cannot be
  433. perfect.
  434.  
  435. Consider a viral vector designed not to infect anything at all until a certain
  436. date is reached, then the virus is 'quiet' until yet another date has passed.
  437. If the vector is passed only in binary form, the chances of discovering the
  438. virus before the vector has widely spread is quite small.  Especially if the
  439. date that the vector starts infecting is more than 30 days in the future.
  440.  
  441. Binary only distributions are quite common, especially with the advent of
  442. shareware.  The catch is, the designer must make the item sufficiently
  443. usefull/interesting to get the user to download it, and then to keep using it
  444. until the infection start date has passed.  If he is able to do that, it is
  445. highly likely that the designer would get greater pleasure out of praise for
  446. the inital tool!  The greater danger is a designer who modifies the binary
  447. received from some other source.  Modification taking less effort than
  448. ground-up design/code/test.  This would even be prefered if you wished to
  449. destroy the reputation of the original tool designer!
  450.  
  451. Gack!  A whole new reason for paranoia!
  452.         "Who?... Me?... WHAT opinions?!?"       | Edwin Wiles
  453.     Schedule: (n.) An ever changing nightmare.  | NetExpress, Inc.
  454.   ...!{hadron,sundc,pyrdc,uunet}!netxcom!ewiles | 1953 Gallows Rd. Suite 300
  455.        ewiles@iad-nxe.global-mis.DHL.COM        | Vienna, VA 22182
  456.  
  457. ------------------------------
  458.  
  459. Date:    07 Jan 90 19:46:35 +0000
  460. From:    gford%nunki.usc.edu@usc.edu (Greg Ford)
  461. Subject: Implied Loader 'Pack' Virus (Mac)
  462.  
  463. Does anyone know what this is?  Last night, while using SUM's Tune-up
  464. option to clean up my HD, a dialog box popped up from GateKeeper Aid
  465. saying "Gatekeeper Aid has found and removed the Implied Loader 'Pack'
  466. virus from the PIC file on the Games Disk".  (Games disk being one of
  467. my partitions).  When I clicked ok in the dialog box, the dialog
  468. immediately reappeared with the same message.  It took about 30 clicks
  469. in the ok box for the dialog to go away (reappearing everytime).  On
  470. top of all that, there is no file called PIC on my HD.
  471.  
  472. Any clues?  It said it removed it, so I'm not worried, but I haven't
  473. heard of this "virus".  If one of you virus-basher guys need to check
  474. this virus out, I can rummage through my backup (which I had just done
  475. before) to try and find it.
  476.  
  477. Greg
  478.  
  479. *******************************************************************************
  480. * Greg Ford                             GEnie:    G.FORD3                     *
  481. * University of Southern California     Internet: gford%nunki.usc.edu@usc.edu *
  482. *******************************************************************************
  483.  
  484. ------------------------------
  485.  
  486. Date:    07 Jan 90 03:38:01 +0000
  487. From:    woody@rpp386.cactus.org (Woodrow Baker)
  488. Subject: Re: Virus Trends (and FAXes on PCs)
  489.  
  490. Nagle@cup.portal.com says:
  491. >     - A FAX message is a bitstream interpreted by an interpreter at
  492. >       the receving end.  Could it be induced to do something interesting
  493. >       through the use of illegal bit patterns?
  494.  
  495. Now that hard disks are available on Postscript printers, We have
  496. another problem.. It is concievable to embed a virus, or a trojan in a
  497. font.  If the font were encrypted, it would be mighty hard to hunt the
  498. virus down.  It could convievably alter fonts on the hard disk, screw
  499. up font chache images, and or plain crash the hard disk.  It would,
  500. however be difficult for it to infect other systems, unless one
  501. retrieves a contaminated file and sends it to another laser printer.
  502. The potential for abuse also exists in prolouges.  I have not seen or
  503. heard of one yet, but now is the time to give some thought to how to
  504. prevent them BEFORE they start getting out of hand.
  505.  
  506. Cheers
  507. Woody
  508.  
  509. p.s.  Some of the new VIDEO cypherrs are viruses of a sort.  They play
  510. with the signal to screw-up VCR's.  Messing with the Automatic Gain
  511. control among other things.  If some one manages to overcome them, and
  512. make a copy of the tape, the messed up signal could sort of take on
  513. viral properties, though they would not do any damage.
  514.  
  515. ------------------------------
  516.  
  517. Date:    07 Jan 90 04:18:00 +0000
  518. From:    clear@actrix.co.nz (Charlie Lear)
  519. Subject: Re: Viruses Rhyme And Reason
  520.  
  521. Bill.Weston@f12.n376.z1.FIDONET.ORG (Bill Weston) writes:
  522. >I'm not sure that writing viruses will ever stop.
  523. >
  524. >Ross Greenberg wrote perhaps the best psychological profile of the
  525. >"virus programmer" that I have ever read.  (It's in the docs of
  526. >FLUSHOT, you've all read it...)
  527. >
  528. > The virus writer likes causing damange.  He thinks it's funny and makes him
  529. >feel powerful.
  530. > To this day, tha STONED virus still infects thousands of systems all over the
  531. >world.  (Poorly written as it is..)
  532. >
  533. >The target of many virus writers are the millions of PC users who don't know
  534. >much about computers.  The novice user, or perhaps the user who knows how to
  535. >run programs but does not know much about DOS, is the primary mark.  A friend
  536. >of mine was just such a person.  Less than 20 days after buying his PC he was
  537. >hit by the STONED virus.  He did not know how to protect himself.  Lots of
  538. >grins for the programmer.
  539.  
  540. One day, you'll actually write something you know something about,
  541. Bill... 8-)
  542.  
  543. The schoolkid who wrote the Stoned virus did it on a dare from an
  544. Amiga owner who was suffering from the first effects of the SCA virus.
  545. It was believed *impossible* by the "experts" for a PC virus to be
  546. written, so he went ahead and wrote a simple, non-destructive bsv on a
  547. standard XT.  Having written it, the consequences of unleashing it
  548. became a bit much to think about, so he made sure all copies were
  549. destroyed bar one which he kept at his house.
  550.  
  551. Despite being under lock and key, his little brother and a couple of
  552. his friends thought it would be a huge joke to steal the disk and
  553. deliberately infect disks in a local computer store.  This was fine,
  554. but after the initial laffs it proved impossible to trace ALL infected
  555. disks and the STONED epidemic was born.
  556.  
  557. Since then, the programmer has lived a very cloistered, paranoic life.
  558. Huge publicity has done nothing to help his studies or his state of
  559. mind, even though his identity has not been publicly revealed.  The
  560. last burst of publicity was later discovered to be a protection
  561. mechanism for the guy, although front page coverage on a capital city
  562. daily is bizarre protection.
  563.  
  564. It seems that after the "blue" side in an Australian army exercise
  565. deliberately infected "red" side computers with the virus to gain
  566. military advantage, certain people in certain security organisations
  567. wished to interview the man who wrote Stoned.  The press coverage
  568. allegedly stopped a kidnap attempt in its tracks - the threat of a
  569. full diplomatic incident was too much for the Aussies and they went
  570. home.
  571.  
  572. Of course, I have no documentary proof of the above as anyone
  573. connected with the writing or dissemination of a virus would be stupid
  574. to write anything down.  I believe I have just illustrated how an
  575. "innocent" prove-it-can-be-done scenario can turn unbelievably bad.
  576. Is it really the programmers fault that the virus does not damage 360k
  577. floppies or 20meg XT disks, and only becomes a danger when used on
  578. large capacity floppies or big hard disks?  He had no access to, or
  579. knowledge of, such hardware when he wrote it...
  580.  
  581. - --
  582. Charlie "The Bear" Lear: Call The Cave BBS, 64(4)643429 157MB Online!
  583. Snail: P.O. Box 12-175, Thorndon, Wellington, New Zealand
  584.  
  585. ------------------------------
  586.  
  587. End of VIRUS-L Digest
  588. *********************
  589. Downloaded From P-80 International Information Systems 304-744-2253
  590.