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

  1. VIRUS-L Digest   Monday, 29 Jan 1990    Volume 3 : Issue 24
  2.  
  3. Today's Topics:
  4.  
  5. Re: Shrink-Wrapped Software
  6. Re: "Desktop Fractal Design System Not Infected"
  7. Re: Internet worm writer stands trial (Internet)
  8. Re: Signature Programs
  9. More re: Desktop Fractal Design System
  10. Re: Signature Programs
  11. Re: Signature Programs
  12. STONED Virus data (PC)
  13. WDEF Virus in California (Mac)
  14. More about UVDs
  15. Three new viruses (PC)
  16. The V651 virus (PC)
  17. Re: Virus vs. worm
  18.  
  19. VIRUS-L is a moderated, digested mail forum for discussing computer
  20. virus issues; comp.virus is a non-digested Usenet counterpart.
  21. Discussions are not limited to any one hardware/software platform -
  22. diversity is welcomed.  Contributions should be relevant, concise,
  23. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  24. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  25. anti-virus, document, and back-issue archives is distributed
  26. periodically on the list.  Administrative mail (comments, suggestions,
  27. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  28.  - Ken van Wyk
  29.  
  30. ---------------------------------------------------------------------------
  31.  
  32. Date:    26 Jan 90 21:00:24 +0000
  33. From:    draughn@iitmax.iit.edu (Mark Draughn)
  34. Subject: Re: Shrink-Wrapped Software
  35.  
  36. cosell@BBN.COM (Bernie Cosell) writes:
  37. >ensys.ensys.com!silvlis.com!msm@sgi.sgi.com (Michael S. Maiten) writes:
  38. >
  39. >}WHMurray@DOCKMASTER.ARPA writes:
  40. >
  41. >}>   Users can protect themselves
  42. >}>   and discourage this risky practice by refusing to deal with retailers
  43. >}>   that offer them the right to return.
  44. >
  45. >}Stores that offer return policies are exactly the ones with whom I do
  46. >}deal, since it is almost impossible to see if the software will meet
  47. >}my needs by reading the box or trying out the store demonstration
  48. >}copy.  What they should do is to be more careful when accepting the
  49. >}returned items (check for missing materials, and check for infection
  50. >}of the disks) before returning the person's money.
  51. >
  52. >Actually, isn't this almost totally trivial for the store --- all they need
  53. >to is, before they re-shrink-wrap, do a sector-by-sector, byte-by-byte
  54. >comparsion of the *entire* disk(s) that were returned against a master set
  55. >the store keeps.  It doesn't seem hard, and surely cannot take long, and far
  56. >as I can tell totally elminates the problems.
  57.  
  58. This requires the stores to keep safe copies set aside for every piece
  59. of software they sell.  It's a lot of work and it costs a lot in terms
  60. of time and equipment.
  61.  
  62. How about this instead:  Software vendors could ship the media separate
  63. from everything else in the piece of software, including the license
  64. to the software.
  65.  
  66. When someone buys a piece of software from the store, they get the entire
  67. package and the disks.  (Having separate media also makes it easy to choose
  68. 5.25" v.s. 3.5" etc.)  If the customer returns the software, the store keeps
  69. everything except the actual disks.  The disks are returned to the vendor.
  70. The vendor then sends the store a new set of disks.  The store still has
  71. the same number of legal, licensed copies, so nothing much has changed.
  72.  
  73. This seems like a good idea because the vendor already has the equipment,
  74. expertise, legal permissions, and master copies needed to produce virus-free
  75. copies of the software.
  76.  
  77. The cost of doing this is small--just the cost of making and shipping a few
  78. disks.  Whether the cost should be carried by the vendor, the store, or the
  79. customer is a detail that market forces will probably control.  My guess is
  80. that the retail stores will end up eating the cost as part of the cost
  81. of good customer service.
  82.  
  83. There are problems with cheating--the retailer could re-wrap, or the vendor
  84. could simply re-ship returned software--but I don't think this will make
  85. things worse.  The retailer has relatively little to gain by cheating when
  86. he can get good copies so cheaply.  The PR damage from even a single incident
  87. of shipping infected software should keep the vendor from cheating.
  88.  
  89. How does that sound?
  90.  
  91. - --
  92. EMAIL: draughn@iitmax.iit.edu+--------------+ Academic Computing Center
  93. BITNET: SYSMARK@IITVAX       | Mark Draughn | 10 W. 31st St.
  94. VOICE: +1 312 567 5962       +--------------+ Illinois Institute of Technology
  95. ALSO: ...{nucsrl|att}!iitmax!draughn          Chicago, Illinois  60616
  96.  
  97. ------------------------------
  98.  
  99. Date:    Fri, 26 Jan 90 14:50:52 -0500
  100. From:    Eric Roskos <jer@ida.org>
  101. Subject: Re: "Desktop Fractal Design System Not Infected"
  102.  
  103. Since writing the posting in today's VIRUS-L with the above Subject line,
  104. I have received some seemingly rather hostile mail criticizing the above
  105. statement.
  106.  
  107. I would urge people who object to the above statement to (a) reread the
  108. original posting, (b) note the quotation marks around the statement, and
  109. (c) reread past issues of VIRUS-L regarding this problem more closely.
  110.  
  111. My point in writing that particular Subject line was, and is, that to
  112. date there is no evidence *which has been presented on VIRUS-L* that the
  113. Desktop Fractal Design System, as shipped from the publisher, is
  114. infected.  There is only the claim that it is, and the statement
  115. (secondhand) that the publisher is "aware" of the problem.  Whether they
  116. are aware that some people say the program is infected, or whether they
  117. have copies of it from their stock that are infected, is not known from
  118. this statement.
  119.  
  120. On the other hand, we do have evidence -- I have it right here -- that
  121. at least one copy is *not* infected, as purchased from a local bookstore
  122. (Reiter's Scientific Bookstore in Washington, DC).  This also is not
  123. evidence that the copy was not infected when shipped -- someone might
  124. have bought the copy, disinfected it, and returned it to the store, for
  125. example -- but the converse possibility is true for the allegedly
  126. infected copies.  Since I write-protected the disk before I used it the
  127. first time, I know it has not been written upon since I unwrapped it.
  128.  
  129. It would be helpful to those of us who have to deal with these issues to
  130. know more about details of alleged virus infections, things such as:
  131.  
  132.         - Did you personally open and install the infected disk?
  133.  
  134.         - Did you write-protect the disk before doing so?
  135.  
  136.         - How many copies do you have that you know to be infected?
  137.  
  138.         - What is the version number of the software?  Is there any other
  139.           date or serial number information involved?
  140.  
  141. More facts and less rumors would be helpful, both in understanding the
  142. problem, and ensuring that it is properly identified, particularly when
  143. a virus report contains some highly specific information (such as stating
  144. that a particular item of software is infected).
  145.  
  146. (Incidentally, I would add here that it would also be beneficial to
  147. software publishers if they would publish their software on floppy disks
  148. without write enable notches in them.  IBM used to do this with their
  149. early PC software disks; I don't recall seeing any like this in a long
  150. time.  It would protect the publishers from being falsely accused of
  151. spreading a virus when in fact the disk was infected by the user during
  152. installation; although it would also eliminate their ability to claim
  153. the latter if they were, indeed, responsible for the infection.  All
  154. around, the practice would seem to be an improvement.)
  155.  
  156. Disclaimer:  I have no connection with the author or publisher of the
  157. Desktop Fractal Design System; I simply own an uninfected copy of it.
  158.  
  159. ------------------------------
  160.  
  161. Date:    26 Jan 90 13:38:02 +0000
  162. From:    woody@rpp386.cactus.org (Woodrow Baker)
  163. Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)
  164.  
  165. > >Gene, in your report (_The Internet Worm Program:  An Analysis_), you
  166.  
  167. Where or how can I get a copy of this report?
  168.  
  169. Cheers
  170. Woody
  171.  
  172. [Ed. It is available via anonymous FTP from cs.purdue.edu in
  173. /pub/reports.  I also keep a copy of it on the CERT anonymous FTP,
  174. cert.sei.cmu.edu, in /pub/virus-l/docs.]
  175.  
  176. ------------------------------
  177.  
  178. Date:    26 Jan 90 13:53:51 +0000
  179. From:    woody@rpp386.cactus.org (Woodrow Baker)
  180. Subject: Re: Signature Programs
  181.  
  182. Where can a description of ISO 8731-2 be obtained at little or no cost?
  183.  
  184. Cheers
  185. Woody
  186.  
  187. ------------------------------
  188.  
  189. Date:    Fri, 26 Jan 90 18:51:35 -0500
  190. From:    Eric Roskos <jer@ida.org>
  191. Subject: More re: Desktop Fractal Design System
  192.  
  193. In keeping with my own suggestion, I checked the version number on the
  194. copy of this software that is not infected; it is version 1.0, as
  195. labeled on the disk (near the bottom of the green label on the disk),
  196. and when started up it also displays 1.0 as the version number.  Can
  197. someone who has an infected copy post the version number involved? If
  198. it is a different version, that will give some insight.  Thanks...
  199. - --E.R.
  200.  
  201. PS - This copy I have was purchased about the 2nd week in December.
  202. There is not any other date or serial number marking present, other than
  203. a serial number for the floppy disk itself, "46892C", stamped on the
  204. back in ink.
  205.  
  206. ------------------------------
  207.  
  208. Date:    Fri, 27 Jan 90 00:28:39 +0000
  209. From:    utoday!greenber@uunet.UU.NET (Ross M. Greenberg)
  210. Subject: Re: Signature Programs
  211.  
  212.  71435.1777@CompuServe.COM (Bob Bosen) writes:
  213. >
  214. >
  215. >1- The PERCENTAGE of the file that is subjected to the sophisticated
  216. >algorithm. This can sometimes be quite a small fraction of the whole
  217. >file.  (The remainder of the file can be processed by an industry-
  218. >standard CRC algorithm. There are various techniques deriving from
  219. >cryptology that can be used to cause the effects of the sophisticated
  220. >algorithms to "ripple through" all the way to the final signature.)
  221. >Properly implemented, these techniques can result in a reliable,
  222. >virtually unforgeable signature that is calculated almost as quickly as a
  223. >conventional CRC.
  224.  
  225. True, only if you're looking for a known pattern.  Otherwise, you're
  226. guessing that your algorithm is smarter than the bad guys.  Not on my
  227. machine you don't!  You're gonna have to scan the whole file, every
  228. byte to tell me if there has been a change. It's incredible what a
  229. simple one byte change may produce:  changing an INT25 to an INT26 (or
  230. vice versa) makes for a difference that can destroy your hard disk. A
  231. one byte difference.
  232.  
  233. >
  234. >2- WHEN the signature is calculated. Obviously you can infuriate your
  235. >users if you make them stand around twiddling their thumbs while all your
  236. >files are authenticated in batch mode during the bootstrap process. On
  237. >the other hand, if most authentication is done "on the fly" as programs
  238. >are loaded, users hardly notice the delays.
  239.  
  240. Assume that your user has a mongo file, maybe .5Meg of code s/he wants
  241. to load up.  For the reasons cited above, you have to do *something* with
  242. each byte of the code.  Take an XT, clocking at 4.77MHz.  Add algorithm
  243. for *each* byte.  Stir slowly.  In the case of the XT, very slowly.  Now,
  244. start adding to the complexity of the algorithm.  Notice the chair in
  245. front of the terminal suddenly gone empty?  That's because the user got
  246. frustrated at the time cost of a very sophisticated algorithm.
  247.  
  248. >
  249. >3- How OFTEN the signatures are calculated. It really isn't necessary to
  250. >recalculate each and every signature every day, or even every time a
  251. >program is executed. Sensible authentication frequencies will depend on
  252. >the work environment, presence of known threats, and the value of assets
  253. >controlled, but may average once or twice a month in typical business
  254. >environments.
  255.  
  256. Every time the file is loaded.  Unless you'll guarantee the user, in writing,
  257. that there is no chance the next time I run a program on a supposedly clean
  258. system that I'm not running a damaging program.  Of course, if you'll
  259. guarantee me that the system the user is on is clean and you'll also
  260. guarantee me that the user has introduced *no* new program whatsoever
  261. onto their system, well, maybe I can see your point.  Would you be willing
  262. to guarantee this type of thing?
  263.  
  264. >
  265. >4- The ALGORITHM chosen. Although its strength is not as well researched
  266. >as DES, ISO 8731-2 has withstood at least some respectable public
  267. >scrutiny, and runs at least ten times as fast as DES. Early indications
  268. >are that SNEFRU is a very strong algorithm that is much faster than DES.
  269. >RSA is much slower than DES. (And as I've consistently said since my
  270. >earliest posting, CRCs of varying strengths are available and can be used
  271. >in appropriate combinations with some of the more sophisticated algorithms
  272. >to speed things up still further.)
  273.  
  274. Any two simple routines will outfunction a singular more complex routine.
  275. A well known routine, no matter the nomenclature, is easily breakable by
  276. anyone who a) understand the algorithm and b) has a dis-asm program handy.
  277. Two differing methods, say a simply  checksum and a simple bit-add-rotate
  278. will do the trick faster and be just as effective.
  279. >
  280. >By judiciously balancing these variables, it is possible to create a
  281. >fast, reliable, sophisticated system that performs so quickly that users
  282. >hardly notice it.
  283.  
  284. Interesting claim, but I've not seen usable proof yet -- usable to the real
  285. world, that is.  I agree that complex algorithms will produce complex
  286. results that are difficult to get around -- but so what?
  287.  
  288. > I have to agree with Ross Greenberg that a
  289. >sophisticated algorithm that performs poorly won't get used at all, and
  290. >is therefore worse than an unsophisticated algorithm. But I also know,
  291. >from direct, first-hand experience, that we need not limit ourselves to
  292. >thinking of sophisticated algorithms as being slow performers. All things
  293. >considered, there is really no reason NOT to abandon the simplistic
  294. >algorithms in favor of those that are likely to be beyond compromise by
  295. >virus writers for several years to come.
  296.  
  297. I'd be interested in two things, both of which are (I think) easily available.
  298. One:  timing results on real live files with anyone of the more sophisticated
  299. routines you propose versus sime CRC and checksum, and Two: any proof at all
  300. that one is going to prove more difficult than the other for a determined
  301. bad guy with a debugger and the ability to do "MOV DS:[BX], OPCODE_FOR_NOP"
  302. when they feel like it.
  303.  
  304. Ross M. Greenberg, Technology Editor, UNIX Today!   greenber@utoday.UUCP
  305.              594 Third Avenue, New York, New York, 10016
  306.  Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  307.   To subscribe, send mail to circ@utoday.UUCP with "Subject: Request"
  308.  
  309. ------------------------------
  310.  
  311. Date:    Fri, 27 Jan 90 00:36:46 +0000
  312. From:    utoday!greenber@uunet.UU.NET (Ross M. Greenberg)
  313. Subject: Re: Signature Programs
  314.  
  315. 71435.1777@CompuServe.COM (Bob Bosen) writes:
  316. >When I began this in-depth series of discussions on authentication
  317. >algorithms and signature programs late last year, I was alarmed and
  318. >frustrated by the lack of attention being paid to the subject of well-
  319. >researched "standard" authentication algorithms.
  320.  
  321. Bob continues, indicating that a bunch of people seem to agree with his
  322. premise that sophisticated algorithms are inherently superior than the
  323. less sophisticated ones.  As one of the named parties, allow me to
  324. disagree, in part:  for authentication that need be done only once, let
  325. the routine be as sophisticated as the data being authenticated need be.
  326. For data that must be scanned and authenticated regularly, I think that
  327. the expression "good enough" must come into play, alas.  Otherwise, the
  328. 100% authoentication method will turn to 0% as the user simply stops
  329. using it.
  330.  
  331. Ross M. Greenberg, Technology Editor, UNIX Today!   greenber@utoday.UUCP
  332.              594 Third Avenue, New York, New York, 10016
  333.  Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  334.   To subscribe, send mail to circ@utoday.UUCP with "Subject: Request"
  335.  
  336. ------------------------------
  337.  
  338. Date:    Sat, 27 Jan 90 10:47:00 -0500
  339. From:    Highland@DOCKMASTER.ARPA
  340. Subject: STONED Virus data (PC)
  341.  
  342. Response to Dave Lovless at UWO and Peter Jaspers-Fayer at Guelph:
  343.  
  344. Explanation of what STONED virus does and step-by-step instructions to
  345. remove that virus from a hard disk can be found in:
  346.  
  347. [1] COMPUTERS & SECURITY - Volume 8, Number 1 on page 11 [2] CAS -
  348. Volume 8, Number 2 on page 97 [3] CAS - Colume 8, Number 5 on page 369
  349.  
  350. All are part of my "Bits & Bytes" column in the journal of IFIP TC 11.
  351. Received the first copy of that virus directly from John Beatson of Data
  352. Systems in Wellington, New Zealand in October 1988.  Data Systems is
  353. similar to our Federal Reserve System, only run by the banks.  John is a
  354. close friend and is Manager of Risk and Security.
  355.  
  356. Bill Kinny of Digital Dispatch, Inc., producers of Data Physician [I ran
  357. a review of product in February 1988 issue] and Virhunt and VirRes [scan
  358. programs] wrote piece on how to remove STONED virus from hard disk.  His
  359. code was checked in real-time by me; I infected one of our machines and
  360. used his "cure" program.
  361.  
  362. Complete information about STONED, aka Marijuana, New Zealand, is
  363. contained on pages 61 through 70 of COMPUTER VIRUS HANDBOOK just
  364. published by Oxford Advanced Technology Press [publishers of COMPUTERS &
  365. SECURITY] located in Oxford, England.
  366.  
  367. David Loveless at University of Western Ontario has copies of CAS as
  368. does Professor John Carroll at UWO.  John should have a copy of COMPUTER
  369. VIRUS HANDBOOK within two to three weeks.
  370.  
  371. If anyone cannot get their hands on CAS issues, contact David, John or
  372. me.  Both CAS issues and COMPUTER VIRUS HANDBOOK contain step-by-step
  373. explanation of how virus code works.  The HANDBOOK also has this data
  374. for some 20 additional common viruses plus other information about this
  375. subject.
  376.  
  377. - ----------------------------------------------------------------------------
  378. Dr.  Harold Joseph Highland, FICS [FICS = Fellow of Irish Computer
  379. Society] Distinguished Professor Emeritus of SUNY Editor-in-Chief
  380. Emeritus of COMPUTERS & SECURITY Managing Director of International
  381. Institute for Information
  382.      Security Education and Training Highland -at DOCKMASTER.NCSC.MIL
  383. MCI Mail 406-5012 Voice contact for emergency:  516-488-6868 EST
  384. - ----------------------------------------------------------------------------
  385.  
  386. ------------------------------
  387.  
  388. Date:    Sat, 27 Jan 90 12:52:02 -0800
  389. From:    GCO0000@CALSTATE.BITNET
  390. Subject: WDEF Virus in California (Mac)
  391.  
  392. One of our Macintosh microcomputer labs was target of the new WDEF
  393. virus despite intense daily anti-viral measures.  This warning is
  394. posted especially for the other universities in Northern California.
  395. Our staff are developing measures against this new virus.
  396.  
  397. Gerry Gray
  398. Academic Computing Department
  399. Humboldt State University
  400. Arcata, California  95521
  401. (707)826-4206, 4207, 4208
  402.  
  403. ------------------------------
  404.  
  405. Date:    Sun, 28 Jan 90 15:18:47 +0000
  406. From:    frisk@rhi.hi.is (Fridrik Skulason)
  407. Subject: More about UVDs
  408.  
  409.                 Can an Universal Virus Detector (UVD) be written ?
  410.  
  411. In order to answer this question, we need to define just what is meant by
  412. the term "virus".
  413.  
  414. We can start with the definition by Fred Cohen, from his "Computer Viruses:
  415. Theory and Experiments":
  416.  
  417.         "We define a computer virus as a program that can infect
  418.          other programs by modifying them to include a slightly altered
  419.          copy of itself"
  420.  
  421. This definition is not perfect.
  422.  
  423.         "program" should also include boot sectors, INITs and all
  424.         other forms of executable code.
  425.  
  426.         "include" must also cover cases like the 405 virus, that
  427.         overwrite the victim, and may destroy it completely.
  428.  
  429.         "slightly altered" is much too inaccurate. It is easy to imagine
  430.         a virus that would only include a small part of itself in the
  431.         programs it infects. See note #1 at the end for details.
  432.  
  433. But is this modified definition just what we want ?  Consider the following
  434. program.
  435.  
  436.                 Program P1
  437.                 Display "This is a copy utility"
  438.                 Display "Name of input file ?"
  439.                 Input In-File
  440.                 Display "Name of output file ?"
  441.                 Input Out-File
  442.                 Copy In-File to Out-File
  443.                 End
  444.  
  445. Is P1 a virus ?
  446.  
  447. Well, according to our definition, it is. If we give it the name of itself
  448. as In-File and the name of some other existing program as Out-File, it will
  449. behave just like any other destructive overwriting virus. Since P1 is able
  450. to place a copy of itself within another program, it is (according to this
  451. definition) a virus.
  452.  
  453. So, any UVD would classify the above program as a virus.  In fact, it would
  454. classify most operating systems as viruses, since they can easily "infect"
  455. other programs in the same way - you just have to give them the right sequence
  456. of commands.  Any compiler used to compile a copy of itself would also
  457. qualify.
  458.  
  459.         "COMMAND.COM is a virus"
  460.         "csh is a virus"
  461.         "C is a virus"
  462.         "OS/2 is a virus"     I like that one.....   :-) :-)
  463.  
  464. But is this what we want ?  Well - hardly.
  465.  
  466. The major reasons for not wanting to call P1 a virus are:
  467.  
  468.         1) It asks the user for the name of source and target files.
  469.         2) It destroys the "victim", instead of executing it more
  470.            or less normally, after executing the virus.
  471.  
  472. Objection 2 is not valid - as mentioned before we already have some programs
  473. like 405 and the AIDS virus (not to be confused with the AIDS trojan), that
  474. work like that. They are labeled as "viruses" without hesitation.
  475.  
  476. Let's change the program a bit:
  477.  
  478.                 Program P2
  479.                 Display "Name of output file ?"
  480.                 Input Out-File
  481.                 Copy P2 to Out-File
  482.                 End
  483.  
  484.                 Program P3
  485.                 Display "Name of input file ?"
  486.                 Input In-File
  487.                 Select Out-File at random
  488.                 Copy In-File to Out-File
  489.                 End
  490.  
  491.                 Program P4
  492.                 Select Out-File at random
  493.                 Copy P4 to Out-File
  494.                 End
  495.  
  496. We probably want our UVD to tell us that P4 is a virus, but also that
  497. P2 and P3 might behave like viruses in some circumstances.
  498.  
  499. But, and this is the all-important question, is it theoretically possible to
  500. write a UVD that will tell us if a program may behave as a virus under
  501. some circumstances ?
  502.  
  503. The UVD must always return with a "Yes" or "No".
  504.  
  505. The answer is Yes, if we make some assumptions:
  506.  
  507.         The program which is to be examined will be called P.
  508.  
  509.         The computer P runs on will be called C.
  510.  
  511.         The environment of P will be called E.
  512.  
  513.         E is assumed to contain the values of registers, memory and data
  514.         in external storage.
  515.  
  516.         P is assumed to be of finite size.  Writing a UVD for programs
  517.         of infinite length is impossible.  It is left as an exercise to
  518.         he reader to determine the result if we have a multi-processing
  519.         system, with an infinite number of processors, each running an UVD
  520.         and throw an infinitely long program at it. :-)
  521.  
  522.         E is also assumed to be of finite size, with a specified maximum.
  523.         This excludes Turing machines.  Writing an UVD for a Turing Machine
  524.         is impossible, just as solving the halting problem for it.  We can,
  525.         however, in theory determine if a program will halt on some input on
  526.         some specific real-world computer.
  527.  
  528.         All I/O operations consist of the transfer of finite amount of data.
  529.  
  530.         The UVD program runs on a different machine, C*.  This machine must
  531.         be many orders of magnitude more powerful than C. In fact, if C is
  532.         a simple machine like Sinclair ZX80, with 1K of memory, C* would
  533.         need to be more powerful than all current supercomputers combined.
  534.         However, we must not be distracted by small problems like that. :-)
  535.  
  536. The proof itself is not included, since it is too lengthy, but if there is
  537. interest I'll make it available.
  538.  
  539.  
  540.                         Note #1 - Multi-Part viruses
  541.  
  542. Let us imagine we have the following three program parts
  543.  
  544.         Part A contains the main program
  545.  
  546.         Part B contains procedures for locating programs and making a
  547.                program memory resident.
  548.  
  549.         Part C contains a file I/O routines.
  550.  
  551. Let us then create two programs, one containing A+B and one containing A+C.
  552. If we only look at one of them, it is unable to replicate and (by definition)
  553. not a virus.
  554.  
  555. Now the fun begins.
  556.  
  557. If we run a program containing A+B, it will not infect other programs.
  558. It will however, hide a part of itself, namely B, somewhere in memory. and
  559. then execute the original program.
  560.  
  561. If we run a program containing A+C, it is also unable to infect other programs,
  562. but it can check if B is present in memory. If so, then we can combine A, B and
  563. C in memory and run the combined program. It will use B to find all programs
  564. not yet infected. They will the either be infected (using C) with parts A+B
  565. or parts A+C. Repeat this for all programs that can be found by B. Then
  566.  
  567. The "virus" here is the program containing A, B and C, but as I said I would
  568. demonstrate, it does not just include a "slightly altered" copy of itself in
  569. other programs, but rather just an "inert" part. The virus will only activate
  570. when its parts are combined.
  571.  
  572. - -frisk
  573.  
  574. ------------------------------
  575.  
  576. Date:    Sun, 28 Jan 90 15:23:56 +0000
  577. From:    frisk@rhi.hi.is (Fridrik Skulason)
  578. Subject: Three new viruses (PC)
  579.  
  580. New virus:  Devil's Dance.
  581.  
  582.     Even though the name sounds as if this is a complex and interesting
  583.     virus, it is not so. This virus is a very simple direct-action .COM
  584.     infector reported to be from Spain.  It will add 941 bytes to the end
  585.     of any file it infects and overwrite the first three bytes with a JMP
  586.     to the viral code.  The virus may infect the same file over and over,
  587.     just as the original Jerusalem virus did.
  588.  
  589.     Those of you having a copy of F-PROT can add the following line to
  590.     SIGN.TXT, in order to enable detection of this virus:
  591.  
  592. Dance       BEbjA5tjKtmmT5mX4Kurg8uIgum4J628UGYOVjk5LOeDVjimIp
  593.  
  594.  
  595. New virus:  Virus101
  596.  
  597.     This virus is written by the author of Virus90.  According to the
  598.     documentation file, some changes have been made. The virus is now
  599.     supposed to infect .EXE files and the boot sector, as well as .COM
  600.     files.  From the documentation file:
  601.  
  602.                      VIRUS101 is the "big brother" of VIRUS-90.
  603.  
  604.            VIRUS-90 was a true non-overwriting virus designed to operate
  605.            under the PC-DOS/MS-DOS operating systems.  VIRUS-90 was
  606.            specifically designed to give both experienced programmers and
  607.            novice computer enthusiasts experience in dealing with computer
  608.            viruses.  VIRUS101, like VIRUS-90, is designed to educate the
  609.            public on computer viruses, but is aimed more towards the
  610.            programming populace.
  611.  
  612.     The author also states that the virus is tamper-proof and disassembly
  613.     resistant.  This is of course absolute bullsh*t - it would probably
  614.     take an experienced assembly language programmer less than an hour to
  615.     create a harmful variant of it.  At least it took me only a few minutes
  616.     to examine Virus90 enough to be able to write a program to detect it and
  617.     remove it from infected files.
  618.  
  619.     The copy I have is labeled as pre-distribution and does not work. Since
  620.     I no not include non-working viruses (like Pentagon) in my anti-virus
  621.     program, I will not include this one yet.
  622.  
  623.     The author states that Virus90 and Virus101 are harmless, and he even
  624.     has the nerve to ask authors of virus detection programs to
  625.  
  626.         "mention that both VIRUS-90 and VIRUS101 are educational utilities
  627.          and that I have designed them for the benefit of programmers"
  628.  
  629.     and
  630.  
  631.         "include a short description of the programs for the good of the
  632.          programming public.  Thanks for your help on this."
  633.  
  634.     But, the fact remains that this is a virus, and could very easily
  635.     be turned into a very dangerous one. So, as soon as I get a working copy
  636.     of it, I will update my programs to detect and remove it.
  637.  
  638.     Still, at least the author has agreed to stop selling the sources.
  639.  
  640.  
  641. New virus:  1260
  642.  
  643.     There is no doubt about it - this is the most interesting virus
  644.     to appear recently. It uses an encryption method similar to that
  645.     used by Cascade (1701/1704), but there is one VERY important
  646.     difference: It is not possible to use ordinary identification strings
  647.     to find infected programs, since the longest sequence of bytes
  648.     identical in all infected programs has a length of three!
  649.  
  650.     To demonstrate the problem, here are the first five instructions from
  651.     three infected files:
  652.  
  653.        INC  SI             CLC                   MOV  AX,86FA
  654.        MOV  AX,F69F        MOV  DI,0147          MOV  DI,0147
  655.        NOP                 INC  SI               INC  SI
  656.        MOV  CX,0550        CLD                   CLD
  657.        CLC                 DEC  BX               DEC  BX
  658.  
  659.    The first 39 bytes of the virus are not encrypted, but they only
  660.    contain 8 instructions, with a length of 17 bytes, for doing the
  661.    actual decoding.  The rest is just garbage, mostly one-byte
  662.    instructions like NOP, CLC, STC, CLD, INC SI, DEC BX etc, that have
  663.    no effect on the program, but are only meant to confuse.
  664.  
  665.    The last "feature", which nobody had expected is that the eight
  666.    encoding instructions are not always in the same order, but may be
  667.    permuted in 24 different ways.  My virus detection program was not able
  668.    to handle that, so I will have to create a new version - expect it in a
  669.    day or two.
  670.  
  671.    "1260" is a resident .COM infecting virus. Infective length is 1260 bytes.
  672.  
  673. - -frisk
  674.  
  675. ------------------------------
  676.  
  677. Date:    28 Jan 90 20:00:00 +0700
  678. From:    T762102%DM0LRZ01.BITNET@IBM1.CC.Lehigh.Edu
  679. Subject: The V651 virus (PC)
  680.  
  681.                             The V651 Virus
  682.                             --------------
  683.  
  684.         This virus can be considered as a teaching example (a state of
  685. the art) of how to construct viruses.  It is only 651 bytes long (I
  686. have named it V651 or Eddie-2, you will see later why) but contains
  687. solutions of almost all problems which a virus designer may encounter.
  688.  
  689.         The virus attacks both .COM- and .EXE-files.  They are
  690. infected when you start them and the .EXE-files are distinguished from
  691. the .COM- ones by the `MZ' marker in the first two bytes.  So you
  692. cannot fool the virus by renaming your *.COM files to, say, *.CMD and
  693. *.EXE to *.EXX and fixing the default extensions in COMMAND.COM.
  694.  
  695.         To be infected, the files must have a length larger than 651
  696. and smaller than 64372 bytes.  The virus installs itself in the memory
  697. by manipulating the memory control blocks, so it cannot be seen with
  698. such utilities as the public-domain MAPMEM.  However, by using PC
  699. Tools (F3, system Info), you can see that the amounts of available
  700. memory found by PC Tools and by PC-DOS differ by 1 K byte (e.g., 640
  701. and 639). (WARNING! I know at least 3 computers which show the above
  702. difference but have no viruses --- maybe sometimes this difference may
  703. be caused by the strange firm/hardware.)
  704.  
  705.         The virus' marker is like the one of the VHP-648 (Vienna A,
  706. Austrian) --- 62 seconds in time-of-last-update field of the directory
  707. entry for the infected files.  This makes possible to design a vaccine
  708. (just like for the VHP-648 virus).  One has simply not to forget to
  709. vaccinate both the .COM- and the .EXE-files.  I'm wondering why the
  710. virus author did not made his virus three bytes shorter (which is
  711. possible) --- just to make it look like the VHP-648 one.
  712.  
  713.         When in memory, this virus intercepts two PC-DOS functions ---
  714. find-first (FCB) and find-next (FCB).  They return various information
  715. about the respective directory entry --- its name, size, date and time
  716. of last update and so on.  When an entry for an infected file is
  717. encountered (which is recognized by the time-of-last-update field),
  718. the virus changes the information in the `size' field, by subtracting
  719. 651 (its own size) from it.  So if you type DIR with the virus
  720. resident in memory, you will obtain a directory listing with the
  721. original (non-infected) file lengths.  This reduces the chances to
  722. discover the virus.
  723.  
  724.         The virus has his own critical error handler, so you won't get
  725. the "Abort, Retry, Ignore? " message when it tries to infect a write-
  726. protected diskette.
  727.  
  728.         However, the virus' author has made two mistakes.  First, the
  729. virus does not intercept the find-first/find-next functions which are
  730. using the file handle (instead of FCBs used by DIR) method.  So, if
  731. you look at a directory with a file-manager utility, you will almost
  732. certainly notice the increased file lengths.  Second, if you already
  733. have a small (under 651 bytes) .COM-file, which is vaccinated against
  734. the VHP-648 virus and the V651 virus is resident in memory, you will
  735. obtain a huge number for the file length when listing the directory
  736. with the DIR command.
  737.  
  738.         The virus has no destructive functions.  In fact it does not
  739. have any effects at all.  The string "Eddie lives" is contained in its
  740. body but is never displayed.  (The string contained in the original
  741. Eddie or Dark Avenger virus is "Eddie lives...somewhere in time!".)
  742. Obviously, the author of the V651 virus was envious for the faith of
  743. the Dark Avenger.  Of course, this reveals also the fact that this
  744. virus was created in Bulgaria (I do not know its author).
  745.  
  746.         Just like the Eddie (Dark Avenger) virus, this one saves the
  747. critical information from the infected files in the last 11 bytes of
  748. its code.  They have the following layout:
  749.  
  750.                 IP (2 bytes) - The contents of the IP field of the
  751.                                EXE-header
  752.                 CS (2 bytes) - The contents of the CS field of the
  753.                                EXE-header
  754.                 SP (2 bytes) - The contents of the SP field of the
  755.                                EXE-header
  756.                 SS (2 bytes) - The contents of the SS field of the
  757.                                EXE-header
  758.                 (3 bytes)    - The first 3 bytes of the file
  759.  
  760.         The (IP, CS, SP, SS) fields are used when an infected .EXE-
  761. file is run and the last 3 bytes are for the .COM-files. So, if you
  762. want to disinfect (cure? I'm not sure for the right word) an infected
  763. file, you have to restore the original contents of the .EXE-header
  764. (resp. - the first 3 bytes of the .COM-file) from the last 11 bytes
  765. described above and then to shorten the file by 651 bytes.
  766.  
  767.                         Sincerely,
  768.                                         Vesselin Bontchev
  769.  
  770. ------------------------------
  771.  
  772. Date:    29 Jan 90 05:40:13 +0000
  773. From:    spaf@cs.purdue.edu (Gene Spafford)
  774. Subject: Re: Virus vs. worm
  775.  
  776. hp-sdd!hplred.HP.COM!perry@ucsd.edu (Jeff Perry) writes:
  777. >   This is probably a simple question, but I haven't heard it asked (or
  778. >answered). What is the difference between a virus and a worm?
  779.  
  780. Well, there are many differing definitions, with one extreme being
  781. that all worms are viruses.
  782.  
  783. The definitions I think most people use are:
  784.  
  785.   A virus is code that cannot run on its own.  It is inserted into
  786. another ("host") program, and cause that program to run the virus
  787. code when the host is run.  The virus code, when run, will insert a
  788. copy of itself in another "host," then possibly do some other task
  789. (often known as the "manipulation" task), then possibly execute the
  790. original host code.  Viruses are not self-contained programs.
  791.  
  792.   A worm is a program that can run by itself.  It is self-contained in
  793. that it can run as an independent program.  It may use system programs
  794. to propagate itself.  Worms travel (and possibly multiply) over
  795. communications links.  They do not necessarily do anything other than
  796. travel from machine to machine (or propagate around a network), but
  797. they may also perform manipulation tasks, carry viruses, etc.
  798.  
  799. Gene Spafford
  800. NSF/Purdue/U of Florida  Software Engineering Research Center,
  801. Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
  802. Internet:  spaf@cs.purdue.edu   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf
  803.  
  804. ------------------------------
  805.  
  806. End of VIRUS-L Digest
  807. *********************
  808. Downloaded From P-80 International Information Systems 304-744-2253
  809.