home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.26 < prev    next >
Text File  |  1995-01-03  |  5KB  |  106 lines
  1. VIRUS-L Digest             Thursday, 26 Jan 1989        Volume 2 : Issue 26
  2.  
  3. Today's Topics:
  4. nVir (init 29) (Mac)
  5. Viral protection by checksum registration?
  6.  
  7. ---------------------------------------------------------------------------
  8.  
  9. Date:         Wed, 25 Jan 89 15:13:46 EST
  10. From:         SCOTT <LICHTBLS@DUVM.BITNET>
  11. Subject:      nVir (init 29) (Mac)
  12.  
  13.   I have encountered this new strain of nVir on a bunch of Mac II's
  14. with Interferon, but have not been able to successfully eradicate the
  15. infection.  Also Ferret, VirusRx, and virus detective are not able to
  16. identify this virus.  The virus also shows up as a code segment ID 255
  17. or 256 which is 712 bytes long as previously noted.  What is the best
  18. way to eradicate this "thing"?  Is this new strain of any potential
  19. danger to documents saved on a different disk or will it just cause
  20. memory problems when the infected machine is used?
  21.         Help!!
  22.         Scott.
  23.  
  24. ------------------------------
  25.  
  26. Date:     Wed, 25 Jan 89 14:44 MDT
  27. From:     Pete Klammer 303/556-3915 <PKLAMMER@CUDENVER.BITNET>
  28. Subject:  Viral protection by checksum registration?
  29.  
  30. We could have some protection against viruses if we could compare a
  31. characteristic "signature" of a program file against a "register" of
  32. known program signatures.  The "signature" would have to be fairly
  33. strong, and the problems of trusted registration and distribution of
  34. copies of the register are non-trivial.  Furthermore, a virus attack
  35. can spread more quickly than registered-signature checking can be
  36. done, but at least this method offers some assurance when we're
  37. looking at a clean system.  For that matter, it would let us know if
  38. we're looking at identical copies of a known virus, vs.  slightly
  39. twiddled ones.
  40.  
  41. What I'm suggesting is that something like a checksum be defined, but
  42. it must be long and complex enough, and include the file size, such
  43. that a counterfeit file of the same size and signature which could
  44. even execute at all, let alone do any useful viral-like damage, would
  45. be too hard or too expensive to come up with.  A checksum is too weak:
  46. I can produce any checksum I want from any file if I have a few spare
  47. bytes to "seed" with checksum-compensating values.  Rather, the
  48. algorithm for the "anti-viral-signature" of a file would have to be
  49. more like a high-order cyclic redundancy check or one-way trap-door
  50. encryption.
  51.  
  52. I'm also suggesting that a common, trustworthy repository for
  53. registration of program files be set up.  I could then know that
  54. FORMAT.COM for PC-DOS 2.1 has signature "1140745HL2K6G76G724", and
  55. FORMAT.COM for Zenith MS-DOS 3.1 has signature "1047HD2468K7G6762GR4",
  56. and so forth.  Over time, that could get to be a long list: how many
  57. legitimate versions of C1.EXE (or whatever) for Microsoft C have
  58. actually been distributed (3.0, 4.0, 4.01, 4.1, 5.0, 5.01?, 5.1...?).
  59. And of course, versions of the "anti-viral-signature-checker" would
  60. have to be registered, too.
  61.  
  62. With these tool, one could, on occasion or even constantly in "TSR
  63. background spare time", scrutinize a file system for corruptions.  The
  64. "background" method is itself vulnerable to viral infiltration, but I
  65. should still be able to boot up from a trusted write-protected* floppy
  66. and scan my files whenever things get suspicious.
  67.  
  68. (*NOTE on that noisy subject: PC floppy drives implement write
  69. protection in the hardware quite simply: the "write-enable" pin of the
  70. floppy-disk-controller chip receives its signal from an AND gate --
  71. i.e., whenever you ask to write, AND the write-enable notch is
  72. detected, it writes.  Commodore-64 drives (1541's) do not have such a
  73. hardware AND gate, and in fact, their ROM firmware can be overridden
  74. by executable code downloaded into into on-board RAM.  [Speculation
  75. now:] Since Apple ]['s do so much disk control, and so economically,
  76. from inside the 6502 processor, I suspect Apple ][ write protection is
  77. firmware-based, too.  These kinds of implementations feed the
  78. write-protect misunderstanding.  REAL drives cannot write over a
  79. write-protect tab.)
  80.  
  81. I recognize the anti-viral-signature method might be too cumbersome to
  82. catch a virus in the act, but wouldn't it be worthwhile to have a way
  83. to check if the ARC v5.13 or the MS-KERMIT v2.32A you just downloaded
  84. from somewhere is clean or crooked?
  85.  
  86.  * --poko       Pete Klammer, Systems Programmer, (303)556-3915
  87.  *              CU-Denver Computing Services / Campus Box 169
  88.  *              1200 Larimer St NC2506 / Denver CO 80204-5300
  89.  *              BITNET: PKLAMMER@CUDENVER
  90.  *              INTERNET: PKLAMMER@PIKES.COLORADO.EDU
  91.  * " I'm half Estonian, which makes up for the other half. "
  92.  
  93. [Ed. Ideas like this have been tossed around quite a bit, and they
  94. certainly hold some promise (imho).  They also have a lot of potential
  95. logistics problems (e.g., who distributes the CRC program itself, and
  96. how do we assure that *it* is not corrupt?  a computing environment
  97. in which everyone uses the same CRC (or checksum...) would be, as it
  98. is now, relatively homogeneous - a virus could make use of this fact,
  99. and propagate freely throughout the environment.).  Comments?]
  100.  
  101. ------------------------------
  102.  
  103. End of VIRUS-L Digest
  104. *********************
  105. Downloaded From P-80 International Information Systems 304-744-2253
  106.