home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / v / vl6-2.zip / VL6-2.TXT < prev   
Internet Message Format  |  1993-01-15  |  40KB

  1. From lehigh.edu!virus-l Thu Jan  7 07:06:32 1993
  2. Date: Tue, 5 Jan 1993 10:09:29 -0500
  3. Message-Id: <9301051402.AA11929@barnabas.cert.org>
  4. Comment: Virus Discussion List
  5. Originator: virus-l@lehigh.edu
  6. Errors-To: krvw@cert.org
  7. Reply-To: <virus-l@lehigh.edu>
  8. Sender: virus-l@lehigh.edu
  9. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  10. From: "Kenneth R. van Wyk" <krvw@cert.org>
  11. To:   Multiple recipients of list <virus-l@lehigh.edu>
  12. Subject: VIRUS-L Digest V6 #2
  13. Status: R
  14.  
  15. VIRUS-L Digest   Tuesday,  5 Jan 1993    Volume 6 : Issue 2
  16.  
  17. Today's Topics:
  18.  
  19. Re: A user's view of IBM's antivirus/2 (OS/2)
  20. Re: A user's view of IBM's antivirus/2 (OS/2)
  21. Re: Bugs in Mcafee OS/2 Clean (OS/2)
  22. Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
  23. Re: Viruses in OS/2 HPFS (OS/2)
  24. Re: NEW MPC On the way (PC)
  25. Virus Simulator MtE Suppliment (PC)
  26. TBAV 5.01 (PC)
  27. SUMMARY: FORM virus infection in Germany (PC)
  28. Re: Virus Simulator MtE Available (PC)
  29. Re: VSHIELD, VIRSTOP, ... comparison ? (PC)
  30. Solution to using %VARIABLE% with scan (PC)
  31. Re: Integrity Management (PC)
  32. Re: SVC 6.0 not rem. by F-PROT206a (PC)
  33. Re: Virus Simulator MtE Available (PC)
  34. Chkdsk / undelete fix from Microsoft. (PC)
  35. Clearing out old signatures (PC)
  36. "Beneficial" viruses
  37. Checksums, signatures, and "good enough" algorithms. (Generic)
  38. Definition of computer virus (was FC on virus creation)
  39.  
  40. VIRUS-L is a moderated, digested mail forum for discussing computer
  41. virus issues; comp.virus is a non-digested Usenet counterpart.
  42. Discussions are not limited to any one hardware/software platform -
  43. diversity is welcomed.  Contributions should be relevant, concise,
  44. polite, etc.  (The complete set of posting guidelines is available by
  45. FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
  46. your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
  47. Information on accessing anti-virus, documentation, and back-issue
  48. archives is distributed periodically on the list.  A FAQ (Frequently
  49. Asked Questions) document and all of the back-issues are available by
  50. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  51. (comments, suggestions, and so forth) should be sent to me at:
  52. <krvw@CERT.ORG>.
  53.  
  54.    Ken van Wyk
  55.  
  56. ----------------------------------------------------------------------
  57.  
  58. Date:    22 Dec 92 12:17:35 +0000
  59. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  60. Subject: Re: A user's view of IBM's antivirus/2 (OS/2)
  61.  
  62. tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser) writes:
  63.  
  64. > DC>> or that their boot record had changed (because they
  65. > DC>> changed a volume serial number).
  66.          ^^^^^^^^^^^^^
  67. > >Hey, they should be really power users, if they know how to do that!
  68. > >For instance, I don't know how it can be done, without reformatting
  69. > >the disk, or using a sector editor... And anybody who is competent
  70. > >enough to mess with a sector editor in the boot sector, should not be
  71. > >surprised by a message that the said sector has been modified afterwards...
  72.  
  73. >    No, it is not really necessary to be a power user. If you use the
  74. > LABEL command with DOS 4.0 or above, it will update the BPB in the
  75. > boot sector.  DOS 4.0+ records the volume label at offset 2Bh in the
  76. > boot sector.
  77.  
  78. I know that. That's why a boot sector integrity checker should exclude
  79. this area. But David mentioned the volume SERIAL NUMBER, not the
  80. volume label... I didn't know that the serial number can be changed
  81. with the LABEL command... Can't verify it now - I am running DR-DOS -
  82. but I am pretty much convinced that it cannot...
  83.  
  84. Regards,
  85. Vesselin
  86. - --
  87. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  88. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  89. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  90. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  91.  
  92. ------------------------------
  93.  
  94. Date:    22 Dec 92 12:21:38 +0000
  95. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  96. Subject: Re: A user's view of IBM's antivirus/2 (OS/2)
  97.  
  98. tck@fold.ucsd.edu (Kevin Marcus) writes:
  99.  
  100. > >Hey, they should be really power users, if they know how to do that!
  101. > >For instance, I don't know how it can be done, without reformatting
  102. > >the disk, or using a sector editor... And anybody who is competent
  103. > >enough to mess with a sector editor in the boot sector, should not be
  104. > >surprised by a message that the said sector has been modified
  105. > >afterwards...
  106.  
  107. > Well, I don't have the entirety of the original sentence, so I might
  108. > be missing something, but, int 25h will let you read in the boot
  109. > sector, you modify it however, and rewrite it with int 26h.
  110.  
  111. Yes, of course, but as I said, anybody who is competent enough to do
  112. that (especially if s/he knows the difference between using INT
  113. 25h/26h under DOS 4.x+ and the DOS versions below) is a power user and
  114. shouldn't be surprised by a message the the boot sector has been
  115. changed... Besides, it is trivial to make the integrity checker
  116. exclude this area of the DOS boot sector from the integrity check...
  117.  
  118. > Additionally, I have just recently seen some 486-50s with AMI BIOS's
  119. > (copyright 1992, I dont' know the exact date, though), that allow for
  120. > a "bootsector virus protection".  Which is somewhat funny.  Since I do
  121. > a lot of fdisking and formatting of drives on new systems, they scream
  122. > these messages, "Boot sector write - continue? (Y/n)" type of thing.
  123.  
  124. Sounds like a very nice feature, unless it is not possible to turn it
  125. off, of course... :-)
  126.  
  127. > THe funniest thing, however, is that it didn't do that when I ran sys
  128. > on a hard drive.  In fact, they mean bootsector of floppy, or MBR on
  129. > hard drive.
  130.  
  131. No, they probably mean track 0, side 0, sector 1 of ANY drive... This
  132. the boot sector on diskettes and the MBR on hard disks.
  133.  
  134. Regards,
  135. Vesselin
  136. - --
  137. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  138. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  139. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  140. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  141.  
  142. ------------------------------
  143.  
  144. Date:    Tue, 22 Dec 92 09:57:19 -0500
  145. From:    Otto Stolz <RZOTTO@NYX.UNI-KONSTANZ.DE>
  146. Subject: Re: Bugs in Mcafee OS/2 Clean (OS/2)
  147.  
  148. Hello,
  149.  
  150. on Fri, 18 Dec 92 18:13:10 +0000 Brett J.L. Landry <bjl1@Ra.MsState.Edu>
  151. said:
  152. > OScan discovered that there was stoned in two partitions on 120 meg
  153. > drive
  154.  
  155. Obviously a canard! On hard-disks, Stoned is a MBR infector, hence it is
  156. *never* in a partition. (There is only one MBR on any one HD, which is
  157. outside of all partitions; rather, it defines the partitions.)
  158.  
  159. > The problem came into play when I cleaned using OSclean.  It
  160. > removed stoned but also removed the second partition loosing the 80
  161. > meg section.
  162.  
  163. I do not know OSclean. But if it indeed tried to clean Stoned off
  164. partitions (i.e. OS boot records), anything seems possible...
  165.  
  166. > Any thoughts on this would be appreciated.
  167.  
  168. Just my 2 Pennies' worth of thoughts...
  169.  
  170. Merry Xmas to those who celebrate it, and best wishes to all,
  171.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  172.                                <RZOTTO@nyx.uni-konstanz.de>
  173.  
  174. PS. I've sent detailed Stoned info to J.L.Landry, privately.
  175.  
  176. ------------------------------
  177.  
  178. Date:    22 Dec 92 18:40:09 +0000
  179. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  180. Subject: Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/
  181.      2)
  182.  
  183. aryeh@mcafee.com (McAfee Associates) writes:
  184.  
  185. > >Do you know any way in which a known DOS virus can infect an extended
  186. > >filename on an HPFS partition?
  187.  
  188. > Nope.  But I myself create directories under OS/2 HPFS with names like
  189. > "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
  190. > files.  I'm sure other people do as well :-)
  191.  
  192. Yup, you are right. And there is one more possibility, which I figured
  193. out myself after posting my message. A virus could infect a file with
  194. a short filename and the user could rename it later to an extended
  195. filename. If the scanner does not scan those files, then there is a
  196. danger for reinfection.
  197.  
  198. Regards,
  199. Vesselin
  200. - --
  201. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  202. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  203. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  204. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  205.  
  206. ------------------------------
  207.  
  208. Date:    22 Dec 92 18:53:08 +0000
  209. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  210. Subject: Re: Viruses in OS/2 HPFS (OS/2)
  211.  
  212. bjl1@Ra.MsState.Edu (Brett J.L. Landry) writes:
  213.  
  214. > There has been aa lot of talk about OS/2 not being able to be infected
  215. > from regular old DOS boot sector viruses using the HPFS. This is false
  216. > since regular old STONED can infect both logical and physical parttions
  217. > on OS/2 using HPFS.  Why wait for true OS/2 viruses when you can suffer
  218. > from regular DOS viruses.
  219.  
  220. I don't know what do you call logical and physical partitions on OS/2
  221. using HPFS, but Stoned can infect only one thing - the Master Boot
  222. Record of the hard disk. That is, the sector at track 0, side 0,
  223. sector 1. It can be infected on any IBM PC compatible machine,
  224. regardless whether it runs MS-DOS, OS/2, Unix, or whatever.
  225.  
  226. Some systems (Unix) may become non-bootable after the infection. On
  227. other systems (OS/2) the virus will be unable to spread further, i.e.
  228. to infect diskettes.
  229.  
  230. Regards,
  231. Vesselin
  232. - --
  233. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  234. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  235. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  236. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  237.  
  238. ------------------------------
  239.  
  240. Date:    Mon, 21 Dec 92 19:48:00 -0500
  241. From:    ncoast!arnold@usenet.INS.CWRU.Edu
  242. Subject: Re: NEW MPC On the way (PC)
  243.  
  244. JDG111@PSUVM.PSU.EDU writes:
  245. >Rumor has it that a newer verion of the Phalcon/Skism MPC (Mass
  246. >Produced Code Generator) is going to be released sometime soon.  My
  247. >source didn't say when, but "soon".  Also, a new edition of the 40-Hex
  248. >magazine is suposedly coming out around New Years.  Happy New Year
  249. >everyone.  <sigh>
  250.  
  251. Yes there is a new 40-hex comming out, I am in-contact with a member
  252. and he said issue 9 would be out.  The group for to everyone's releif
  253. disbanded after their big Bust, but unfortunately they banded together
  254. again about a week after the anouncement.  I have also been told that
  255. McAFEE can already detect all the virus created with the MPC.  Note:
  256. There is a new Mutation Engine out called TPE, it E It is from Italy
  257. or Somewhere near in, and supposedly it is better an MTE.  I don't
  258. know I will have to test it but I will post my results..
  259.  
  260. Arnold
  261.  
  262. ------------------------------
  263.  
  264. Date:    22 Dec 92 02:24:13 +0000
  265. From:    as194@cleveland.Freenet.Edu (Doren Rosenthal)
  266. Subject: Virus Simulator MtE Suppliment (PC)
  267.  
  268.  Doren Rosenthal
  269.  Rosenthal Engineering
  270.  3737 Sequoia
  271.  San Luis Obispo, CA USA 93401
  272.  
  273.  November 21, 1992
  274.  
  275.  
  276.       >From: frisk@complex.is (Fridrik Skulason)
  277.       >Subject: Re: Virus Simulator MtE Available (PC)
  278.       >Date: Fri Dec 18 05:15:10 1992
  279.  
  280.       >as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
  281.  
  282.       >>     are  using  their MtE virus detecting  programs  correctly,
  283.       >>     additionally  affording  an  opportunity  for  a   practice
  284.       >>     training drill under safe and controlled conditions.
  285.  
  286.  >I just hope that everybody realizes that the ability of a program to
  287.  >detect the files generated by the "Virus Simulator" does not at all
  288.  >indicate if it will detect the actual viruses or vice versa, which
  289.  >makes this effort quite pointless, IMHO.
  290.  
  291.  >- -frisk
  292.  
  293.  Frisk,
  294.  
  295.  Thank  you for your comments on my Virus Simulator MtE Supplement. I'll  be
  296.  mailing  the first copies january 1, so I hope your opinion  is  mistakenly
  297.  based  on  my original Virus Simulator and not your technical review  of  a
  298.  program you could not possibly have examined yet. Readers of this forum may
  299.  recall  the  considerable  controversy and  strong  opinion  you  expressed
  300.  beginning two weeks before my release of that program as well.
  301.  
  302.  Because of the security nature of the Virus Simulator MtE Supplement, it is
  303.  only available directly from Rosenthal Engineering and you should not trust
  304.  it  to  be harmless unless you can directly trace its source  to  Rosenthal
  305.  Engineering without compromise. The Virus Simulator MtE Supplement is  only
  306.  available  to  registered users of Virus Simulator, it  is  not  shareware.
  307.  Registered users of Virus Simulator should be receiving the Virus Simulator
  308.  MtE Supplement shortly, without additional charge.
  309.  
  310.  The  Virus  Simulator  MtE  Supplement compiles  a  test  suite  of  highly
  311.  controlled,  safe test viruses and special dummy programs they will  infect
  312.  (only).  The test viruses will only infect the special dummy test  programs
  313.  generated by the Virus Simulator MtE Supplement. Provisions have been taken
  314.  to  discourage modification and tampering. Both .EXE and .COM  viruses  and
  315.  dummies  are  provided.  With the exception of  their  special  safety  and
  316.  security provisions, the MtE test simulations are real polymorphic viruses.
  317.  
  318.  At  the hart of these MtE virus simulations is an actual Dark  Avenger  MtE
  319.  mutation engine. The MtE engine provides virus writers with the ability  to
  320.  turn  their relatively simple programs into very sophisticated  polymorphic
  321.  viruses  which  are extremely difficult to detect by virus  scanners.  Each
  322.  time  the  virus infects a host program it mutates, changes  its  signature
  323.  pattern  to avoid recognition. A few examples of viruses that  employ  this
  324.  same MtE engine are:
  325.  
  326.  Pogue,  Dame, MtE, Gotcha, 7S, Mut, Dedicated, Fear, Groove,  Coffee  Shop,
  327.  MtE-Spawn, Questo, Crypto Lab, Encroach.
  328.  
  329.  Although  the  MtE  simulations  produced  by  my  program  are  safe   and
  330.  controlled, they are real viruses, capable of infecting their special dummy
  331.  host  programs. Vigilant anti-virus programs that are capable  of  reliably
  332.  detecting the MtE mutation engine should report these simulations as  being
  333.  infected.  Because these are real polymorphic viruses several  samples  are
  334.  required  to validate a virus detector, as each time the virus  mutates  in
  335.  attempt to avoid detection, its signature changes.
  336.  
  337. Doren Rosenthal
  338.  
  339. ------------------------------
  340.  
  341. Date:    Mon, 21 Dec 92 02:47:00 +0000
  342. From:    Malte_Eppert@f6002.n491.z9.virnet.bad.se (Malte Eppert)
  343. Subject: TBAV 5.01 (PC)
  344.  
  345. Hello Vesselin,
  346.  
  347. you wrote about TBCHECK:
  348.  
  349.  > It doesn't know about PATH companions.
  350.  
  351. Well, it won't let them through. If you have a validated file called
  352. HELLO.EXE, and a path companion virus creates some HELLO.COM in a
  353. directory listed in the DOS path, and you issue "HELLO" in a path
  354. different from that one where HELLO.  EXE resides in, then TBCHECK
  355. would give a warning like "HELLO.COM is not listed in the
  356. ANTIVIR.DAT-File. Stop execution?". So it takes care of it. Of course
  357. you're right with the other weaknesses (DOS file fragmentation, fixed
  358. polynomial). The product is unfortunately not designed to stand a
  359. directed attack, but it's a nice approach for a multilayer concept, I
  360. think.
  361.  
  362. BTW: what do you think about the tunneling-stopping features of TBAV?
  363. Do the utilities effectively stop tunneling? They e.g. prevented
  364. TBSCAN from tracing to the BIOS entry point :-)) in version 5.01, and
  365. when I executed the Tequila virus, TBAV said: TEQUILA.EXE tries to
  366. trace to the BIOS entry point and advised me to reboot.
  367.  
  368.  >> BTW: I managed to have Armageddon infect a file after I allowed the
  369.  >> virus to go TSR, though I've activated the whole product palette.
  370.  >> What's that - a special way to put its code into a file, which TB
  371.  >> doesn't recognize?
  372.  
  373.  > I'm afraid that I do not understand the question... There's nothing
  374.  > special with Armagedon - it just prepends itself to the COM files -
  375.  > like the Jerusalem virus does...
  376.  
  377. That's what I thought, too... Well, how does it manage to successfully
  378. infect a file via 'standard methods' when TBAV is active, then? Any
  379. other link virus I tested was stopped (I just have a few ones). For
  380. example, the Cascade triggers the same warning ("This program tries to
  381. remain resident in memory and is not confirmed to be allowed to do
  382. this") as Armageddon, and when I allow it to go TSR, it tries to
  383. infect COM files on execution - but is caught by TBAV. Armageddon is
  384. not, it happily infects any COM file without any interception - why?
  385.  
  386. cu!
  387. eppi
  388.  
  389. - --- Via SCANTOSS V 1.37
  390.  * Origin: No Point for viruses - The EpiCentre! (9:491/6002)
  391.  
  392. ------------------------------
  393.  
  394. Date:    Tue, 22 Dec 92 04:39:41 -0500
  395. From:    David Hanson <cfsc-hga-gc-mis@augsburg-emh1.army.mil>
  396. Subject: SUMMARY: FORM virus infection in Germany (PC)
  397.  
  398. I wrote:
  399.  
  400. >On 18 November 1992, we discovered the FORM virus on the boot
  401. >sector of 12 of our PC hard disks.
  402. >Question:  Outside of using a commercial anti-virus package,
  403. >           is there any way of eliminating this virus "manually"
  404. >           (ie. editing sectors on the disk)?
  405.  
  406.  
  407. mcafee@netcom.com (McAfee Associates) writes:
  408.  
  409. >> The DOS SYS command can be used to overwrite the boot sector off
  410. >> infected disks to remove the virus.  Afterwards, run the DOS CHKDSK /F
  411. >> command to recover any clusters marked as bad by the virus (if using
  412. >> DOS 5.00, make sure your disk can have CHKDSK /F run safely on it, or
  413. >> upgrade to MS-DOS 5.00a).
  414.  
  415. >>Oops, my mistake, CHKDSK recovers lost clusters, not bad
  416. >>ones.
  417.  
  418. Thanks to all who wrote to tell me to use SYS.COM.  However, I don't
  419. think that I would recommend SYS without the caveat that you may lose
  420. some FAT information.  Areyah alludes to it in his response, and in
  421. reality, there can be quite a bit of destruction.
  422.  
  423. CHKDSK can be pretty heavy-handed in doing FAT repair, so I would
  424. suggest to anyone attempting to use SYS to remove a FORM infection:
  425. Have your Disk Doctor (or whatever) handy 'cause you're going to need
  426. it!
  427.  
  428. Again, thanks to all who responded...
  429.  
  430. David Hanson
  431. cfsc-hga-gc-mis@augsburg-emh1.army.mil
  432.  
  433. ------------------------------
  434.  
  435. Date:    Tue, 22 Dec 92 11:11:40 +0000
  436. From:    icking@gmd.de (Werner Icking)
  437. Subject: Re: Virus Simulator MtE Available (PC)
  438.  
  439. as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
  440. >              Virus Simulator MtE Supplement Available
  441. >          ------------------------------------------------
  442.  
  443. >
  444. >     An  MtE virus simulation test suite generator is  available
  445. >     suitable   for   use   by   general   end   users,   system
  446. >     administrators  and  educators. [...]
  447.  
  448. Where? How to get it? Free/share/beg/charity/.../ware?
  449.  
  450. - --
  451. Werner Icking        Werner.Icking@gmd.de        (+49 2241) 14-2443     __o
  452. GMD - Gesellschaft fuer Mathematik und Datenverarbeitung mbH          _`\<,_
  453. Schloss Birlinghoven, P.O.Box 1316, D-5205 Sankt Augustin, Germany   (_)/ (_)
  454.                              "Der Dativ ist dem Genitiv sein Tod." ~~~~~~~~~~~
  455.  
  456. ------------------------------
  457.  
  458. Date:    Tue, 22 Dec 92 07:20:53 -0500
  459. From:    David_Conrad@MTS.cc.Wayne.edu
  460. Subject: Re: VSHIELD, VIRSTOP, ... comparison ? (PC)
  461.  
  462. In VIRUS-L v5i203 (Vesselin Bontchev) writes:
  463. >mramey@u.washington.edu (Mike Ramey) writes:
  464. >> [requesting] a point-by-point comparison of VSHIELD and
  465. >> VIRSTOP?
  466. >> One of my questions is this: VSHIELD intercepts a keyboard reboot and
  467. >> checks for the presence of an infected diskette in the boot diskette
  468. >> drive;
  469. >
  470. >No, VIRSTOP doesn't have such feature (yet).
  471. >
  472. >2) VShield can scan a file while it is being copied. VirStop does not
  473. >have such a feature yet, although Frisk is promising it since a long
  474. >time.
  475. >
  476.  
  477. >From recent comments Frisk has made here it sounds as though scanning
  478. while copying and scanning diskette boot sectors on access will be in
  479. the next version.  For preventing boots from diskettes (to the extent
  480. it can be done) Padgett's NoFboot and SumFboot programs are excellent
  481. and have served me well.
  482.  
  483. >3) VShield uses much more memory than VirStop.
  484. >
  485. >4) VShield can be swapped out to the disk, in order to reduce the
  486. >amount of memory used. This slows down the loading of the programs.
  487. >VirStop does not have such an option (although Frisk intends to
  488. >implement it), but then the memory requirements for VirStop are much
  489. >more modest.
  490.  
  491. This isn't really correct.  The /DISK option to VirStop causes it to
  492. read the signatures from disk instead of loading them into memory, and
  493. reduces the memory requirements from 12K to 2K.  It is true that there
  494. is no way to swap out the 2K kernel, but that would almost be silly.
  495.  
  496. Otherwise a fine comparison.
  497.  
  498. Regards,
  499. David R. Conrad
  500. David_Conrad@mts.cc.wayne.edu, dave@michigan.com
  501.  
  502. ------------------------------
  503.  
  504. Date:    Tue, 22 Dec 92 07:20:55 -0500
  505. From:    David_Conrad@MTS.cc.Wayne.edu
  506. Subject: Solution to using %VARIABLE% with scan (PC)
  507.  
  508. In VIRUS-L v5i203 (Vesselin Bontchev) writes:
  509. >craig@cadzook.columbiasc.NCR.COM (Craig.Williamson) writes:
  510. >> OK here is what I am trying to do:
  511. >
  512. >> SET NETDRV=x:
  513. >> scan c: d: e: /date/report %NETDRV%\vir_rep
  514. >
  515. >> The %NETDRV% is not getting replaced with x: like it should.
  516. >
  517. >Hmm... Very strange... It -should- work... What does %NETDRV% get
  518. >replaced with? What DOS version are you using? What command
  519. >interpreter (COMMAND.COM/4DOS)? In any case, it is not a problem of
  520. >SCAN; it is a problem of the operating environment you are using...
  521. >
  522. >[Moderator's note: I agree that this appears to be a problem with the
  523. >operating environment, and I'd like to request that follow-ups get
  524. >handled via e-mail, with the exception of a follow-up summary of the
  525. >solution (if anyone cares to post one).]
  526.  
  527. There's nothing wrong with his operating environment; chalk this one up
  528. to user error.  He's typing those lines at the command prompt -- DOS only
  529. replaces environment variables when interpreting lines of batch files.
  530. Put those lines in SCANIT.BAT and it would work.
  531.  
  532. (Try typing "echo %COMSPEC%" at the command prompt and see what you get.)
  533.  
  534. I'm cc'ing this solution to Craig.
  535.  
  536. Regards,
  537. David R. Conrad
  538. David_Conrad@mts.cc.wayne.edu, dave@michigan.com
  539.  
  540.  
  541. ------------------------------
  542.  
  543. Date:    22 Dec 92 12:51:18 +0000
  544. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  545. Subject: Re: Integrity Management (PC)
  546.  
  547. RADAI@vms.huji.ac.il (Y. Radai) writes:
  548.  
  549. > ing").  First, you write as if all algorithms have a seed.  Well, in
  550.  
  551. My initial thought was that the database of checksums is kept on-line.
  552. If it isn't (i.e., if it is stored on a write-protected diskette),
  553. then you don't need any cryptographic checksum, of course. But if it
  554. is, you cannot just use plain MDx or any other known keyless
  555. algorithm, because a virus could use the same algorithm to compute the
  556. new checksum of the infected file and update the database of checksums,
  557. so that everything will look OK... In these cases, you -must- have
  558. some kind of key that is kept unknown to the virus.
  559.  
  560. > the case of the MDx algorithms, I suppose you could say that the
  561. > initial contents of the buffers constitute a seed; also that DES has a
  562. > seed when used for authentication purposes (ANSI X9.9), namely the
  563. > initial block.  But what do you mean by "using a different seed for
  564. > the checksum" in the case of CRC?
  565.  
  566. Well, a CRC is usually computer like this:
  567.  
  568.    crc = INITIAL_VALUE;
  569.    while ((c = getc (file)) != EOF)
  570.       crc = crc_table [(crc & 0x00FF) ^ c] ^ (crc >> 8);
  571.  
  572. Usually INITIAL_VALUE is 0, but you could set it to anything you would
  573. like...
  574.  
  575. >   More important, in the case of MDx and X9.9, how do you know that
  576. > varying the seed is enough?  You *may* be right, but to the best of my
  577. > knowledge, neither the buffer contents of MDx nor the initial block of
  578. > X9.9 were designed for that purpose.
  579.  
  580. You are right, I don't know whether it is secure enough. But you have
  581. to do something with the keyless algorithms, if you want to achieve
  582. different checksums for each user and not allow the virus to guess the
  583. correct checksum of the modified object...
  584.  
  585. Regards,
  586. Vesselin
  587. - --
  588. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  589. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  590. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  591. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  592.  
  593. ------------------------------
  594.  
  595. Date:    22 Dec 92 13:26:30 +0000
  596. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  597. Subject: Re: SVC 6.0 not rem. by F-PROT206a (PC)
  598.  
  599. kratz%orville@uunet.UU.NET (Thomas Kratz) writes:
  600.  
  601. > A week ago I had two guys with their pc's in our office who had
  602. > cought the SVC virus in version 6.0.
  603.  
  604. Gosh, how did you manage to get infected by this relatively not
  605. widespread Russian virus?!
  606.  
  607. > SCAN V99 reported [SVC] and(!) [SVC 5.0] in the boot sector and on
  608. > various .com & .exe files, an information I decided not
  609. > to trust, because of the multiple report of infection.
  610.  
  611. Right, SCAN 99 incorrectly reports two infections for this virus. If
  612. there is enough interest, I could post a full list of viruses that
  613. SCAN 99 detects as more than one.
  614.  
  615. > F-PROT found (correctly) SVC 6.0 (4644 bytes), but only on the .com & .exe
  616. > files.
  617.  
  618. The virus also infects SYS files. If F-Prot does not say this or if it
  619. does not detect this, then it is a bug.
  620.  
  621. > After removing the virus (which f-prot claims to do correctly)
  622. > all infected files were absolutely identical with the originals, that were
  623. > present on security-disks, but knowing that SVC 6.0 does infect the boot-
  624. > sector i ran scan again; with the result, that it reports [SVC] and [SVC5.0]
  625. > still present in the boot sector.
  626.  
  627. Sounds indeed like a bug in F-Prot to me... The virus is indeed
  628. multipartite and infects boot sectors, COM, EXE, and SYS files. It
  629. also does funny things to the source of the program AIDSTEST
  630. (AIDSTEST.C), if it finds it... This is a Russian anti-virus program,
  631. written by Lozinsky.
  632.  
  633. Regards,
  634. Vesselin
  635. - --
  636. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  637. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  638. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  639. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  640.  
  641. ------------------------------
  642.  
  643. Date:    22 Dec 92 13:35:04 +0000
  644. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  645. Subject: Re: Virus Simulator MtE Available (PC)
  646.  
  647. frisk@complex.is (Fridrik Skulason) writes:
  648.  
  649. > I just hope that everybody realizes that the ability of a program to
  650. > detect the files generated by the "Virus Simulator" does not at all
  651. > indicate if it will detect the actual viruses or vice versa, which
  652. > makes this effort quite pointless, IMHO.
  653.  
  654. Well, I tend to agree with you, just maybe "not at all" is a too
  655. strong expression. Depending on how exactly his dummy files are
  656. generated, their detection might, or might not be connected with the
  657. ability of a scanner to detect the MtE-based viruses. I suspect that
  658. he's using the MtE itself to generate them. In this case, not
  659. detection of one of them by a scanner does not necessarily mean that
  660. the scanner will not detect the real virus, but in any case should
  661. prompt further investigation...
  662.  
  663. Regards,
  664. Vesselin
  665. - --
  666. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  667. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  668. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  669. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  670.  
  671. ------------------------------
  672.  
  673. Date:    Tue, 22 Dec 92 09:57:21 -0500
  674. From:    Jon Freivald <jaflrn!jaf@uunet.UU.NET>
  675. Subject: Chkdsk / undelete fix from Microsoft. (PC)
  676.  
  677. In line with our discussion of the CHKDSK bug in DOS 5.0, I received
  678. an upload on my BBS from a user who has a relative who works for
  679. Microsoft.  It contains a text file, as well as a new chkdsk.exe and
  680. undelete.exe.
  681.  
  682. For any who wish to obtain this, you can download it by calling (516)
  683. 483-5841, n-8-1, 300-9600.  Sorry, due to feed troubles my mail-server
  684. is off-line.  The file is /public/dos/chkupdt.zip.
  685.  
  686. Jon
  687.  
  688. =============================================================================
  689.                    Jon Freivald ( jaf%jaflrn@uunet.UU.NET )
  690.     Nothing is impossible for the man who doesn't have to do it.
  691. =============================================================================
  692. - -----BEGIN PGP PUBLIC KEY BLOCK-----
  693. Version: 2.0
  694.  
  695. mQCNAiqxd1UAAAEEAMFukk0cHx1XUSNdnwuDC9+paXaH5DAQfRQaADxoTQddbh/P
  696. UJ9GAfFvpmnTYNvNjZYZ6GtMS8E/VlNyPnpqNuqbFVkDJhhBTYq5FeKBZVHItSNW
  697.  
  698.  
  699. ------------------------------
  700.  
  701. Date:    Tue, 22 Dec 92 14:37:55 -0500
  702. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  703. Subject: Clearing out old signatures (PC)
  704.  
  705. Enclosed is a DEBUG script that will create a 68 byte .COM file
  706. (CLEAR.COM) that will zero out memory between the current load
  707. position and the TOM. To use, extract the portion of this message
  708. between the (cut here) lines and name it CLEAR.DEB (the portion
  709. beginning with "a100" and ending with the blank line after the
  710. "q" - NOTE: that last blank line must be there as must the blank
  711. line following "JMP 102".
  712.  
  713. Next run "DEBUG <CLEAR.DEB" When run there should be no errors.
  714. This will create the program CLEAR.COM.
  715.  
  716. NOTE: It will not clear the disk buffers or any high/upper RAM
  717.       nor will it remove any viruses that are properly resident
  718.       in allocated space, it just clears free memory.
  719.  
  720. Weasel-words: this is FreeWare but carries no guarantee of fitness
  721.               of any kind. Caveat etc.
  722.  
  723. - ----beginning of CLEAR.DEB------------8<------cut here-------------
  724. a100
  725. JMP   010D                 ;skip around loop
  726. MOV   ES,AX
  727. XOR   AX,AX
  728. MOV   DI,AX
  729. REPZ                       ;clear out memory
  730. STOSW
  731. MOV   AX,ES                ;replaced by CD 20 for last loop
  732. RET                        ;move stack to protected area
  733. MOV   AX,0100
  734. MOV   SP,AX
  735. MOV   DX,CS
  736. MOV   SS,DX                ;make sure program does not get
  737. ADD   DX,+20               ;overwritten until end
  738. INT   12                   ;Find the TOM
  739. MOV   CL,06
  740. ROL   AX,CL
  741. SUB   AX,1000              ;Can only clear 64k at a time
  742. CMP   AX,DX                ;Make sure we are not back down
  743. JBE   012E                 ;to where program is.
  744. MOV   CX,8000
  745. CALL  0102                 ;if not, clear 64k
  746. JMP   011F                 ;then try again
  747. MOV   WORD PTR [010A],20CD ;last loop - put termination in
  748. SUB   DX,+0F               ;can overwrite most of program
  749. MOV   AX,DX
  750. MOV   CL,03                ;DX contains amount of this segment
  751. SHL   DX,CL                ;that is in use plus loop.
  752. MOV   CX,8000
  753. SUB   CX,DX                ;Subtract from 64k gives amount to
  754. JMP   0102                 ;clear. No return so JMP not CALL
  755.  
  756. rcx
  757. 44
  758. nclear.com
  759. w
  760. q
  761.  
  762. - ----------end of CLEAR.DEB---------8<--------cut here--------
  763.              *
  764.              |
  765.             abc
  766.            defgh               And a Merry Christmas to All,
  767.           ijklmno
  768.          pqrstuvwx                               Padgett
  769.         yzabcdefghi
  770.        jklmnopqrstuv
  771.            wxyz
  772.           __||__
  773.  
  774. ------------------------------
  775.  
  776. Date:    Mon, 21 Dec 92 23:24:08 -0500
  777. From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
  778. Subject: "Beneficial" viruses
  779.  
  780. I believe that Fred Cohen, who is flogging his "beneficial" viruses
  781. again, is being very mischievous, and doing the industry a great
  782. deal of harm.  I gather that in fact these are not viruses at all,
  783. in the sense that we use the term.  They may fit Fred's original
  784. definition, but the modern definition makes much more sense, and it
  785. is impossible for Fred to turn the clock back single handed, any
  786. more than I can resurrect the original meaning of the word "gay".
  787.  
  788. Fred is well aware of this, but he persists in using the term
  789. "virus" for his product, as he knows it will get him far more
  790. publicity, but when you attack him he says 'Are you going to ban
  791. FORMAT?', which, by his definition, is apparently a virus.
  792.  
  793. The trouble with this talk of 'good' viruses is that it provides all
  794. the would be virus writers in our schools with the perfect
  795. justification for their activities.  After all, if Dr. Fred Cohen is
  796. selling 'good' viruses, why shouldn't they see if they can do the
  797. same?
  798.  
  799. He makes the situation even worse when he announces that he has made
  800. 1500 viruses in an afternoon, and that this shows scanners are dead.
  801. In the first place it shows nothing at all, as no one is interested
  802. in viruses until they enter circulation, and in the second place it
  803. provides evidence for the skeptics who believe that we amuse
  804. ouselves in our spare time writing viruses to keep ourselves in
  805. business.  Unfortunately there are already so many kids trying
  806. to emulate Fred, that none of us have the time, let alone the need,
  807. to write viruses.
  808.  
  809.  
  810. Seasons Greetings to everyone.
  811.  
  812. Roger Riordan                     riordan.cybec@tmxmelb.mhs.oz.au
  813.  
  814. CYBEC Pty Ltd.                                 Tel: +613 521 0655
  815. PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727
  816.  
  817. ------------------------------
  818.  
  819. Date:    Tue, 22 Dec 92 10:04:27 -0500
  820. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  821. Subject: Checksums, signatures, and "good enough" algorithms. (Generic)
  822.  
  823. From:    Y. Radai <RADAI@vms.huji.ac.il>
  824.  
  825. >  Padgett Petersen wrote:
  826. >>> I agree but take it one step further, again the algorithm should be
  827. >>> tailored to the specific machine and use a different seed on each - this
  828. >>> in no way weakens the algorithm but gives each PC a different signature
  829. >>> for a particular file. Break one machine and "malware" must start all over
  830. >>> again on the next.
  831.  
  832. >  Vesselin Bontchev replies:
  833. >> In fact, it depends on the algorithm used. If you are using a CRC,
  834. >> just using a different seed for the checksum does not make it secure -
  835. >> you must change the polynomial each time. If you are using something
  836. >> cryptographically strong as DES, MD4, MD5, MD2, or some such, then
  837. >> just changing the seed is enough.
  838.  
  839. >I agree with part of this.  Yes, it depends on the algorithm, and
  840. >using a different seed does not necessarily make an algorithm secure.
  841.  
  842. Ok, I did not explain fully. This is a expansion of a discussion that
  843. Ross Greenberg, Yisreal Radai, & I had in Virus-L about two years ago.
  844.  
  845. The complete concept did not use a single algorithm, rather it was
  846. selected from a 3x3 matrix at the time of installation. Combine a 1 of
  847. nine algorithm with a unique seed and you have a signature that is
  848. difficult for software to forge - at least forging the signature would
  849. be more difficult than breaking the mechanism.
  850.  
  851. First a sample matrix:
  852.  
  853. Row:         ROL  ROR  NOP
  854. Column: XOR
  855.         ADD
  856.         SUB
  857.  
  858. In practise the code might select two to make things more difficult
  859. & would look something like this for .COM files (stages would be needed
  860. for .EXEs over 64k). CX contains the file size. DS points to the file in
  861. memory.
  862.  
  863. Row:         ROL  ROR  NOP
  864. Column: XOR  BX
  865.         ADD       DX
  866.         SUB
  867.  
  868.  
  869.     XOR SI,SI
  870.     MOV BX, sig1
  871.     MOV DX, sig2
  872. L1: LODSB
  873.     XOR BL,AL
  874.     ROL BX,1
  875.     ADD DL,AL
  876.     ROR DX,1
  877.     LOOP L1
  878.  
  879. (please, no jibes at the algorithm - this is just an example)
  880.  
  881. Appending  BX to DX would produce a 32 bit signature. A final confusion
  882. might be whether the order is BX-DX or DX-BX. Since we have three unknowns
  883. (initial seed, algorithm, final order) that are selected at installation,
  884. it becomes very difficult for malware to determine which is acually in use.
  885.  
  886. The easiest way is to compare a known program with its signature but even
  887. there there are many crossing points & if the wrong branch is taken, the
  888. forgery will fail. Further the process will have to start from scratch on
  889. the next PC.
  890.  
  891. Now, it becomes easier for the malware to try to break the program than
  892. to forge a signature so armoring is the next step.
  893.  
  894. The basic point is that the above code is very tight so performance
  895. would not suffer (in tests I have been able to process nearly 64k/second
  896. on a 4.77 Mhz 8088 PC). The selection process can take a little longer
  897. since it is only done once.
  898.  
  899. The above is an example of quantum economics: the strenght of the algorithm
  900. is matched to the speed of the process and the strength of the process
  901. itself. IMHO there is no point in making the signature any stronger since,
  902. unlike DES, it is never transmitted outside the PC it is used on (and,
  903. in fact the user never needs to know what it is).
  904.  
  905. I trust this is sufficient explination.
  906.  
  907.  
  908.              *
  909.              |
  910.             abc
  911.            defgh               And a Merry Christmas to All,
  912.           ijklmno
  913.          pqrstuvwx                               Padgett
  914.         yzabcdefghi
  915.        jklmnopqrstuv
  916.            wxyz
  917.           __||__
  918.  
  919. ------------------------------
  920.  
  921. Date:    Tue, 22 Dec 92 14:29:28 -0500
  922. From:    celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta))
  923. Subject: Definition of computer virus (was FC on virus creation)
  924.  
  925. Hello everybody,
  926.  
  927. I was following for some time discussion about ethical correctness of
  928. Fred Cohen's virus creation. It seems to me that most of dilemmas
  929. arises from different understanding of term computer virus. I am
  930. relatively new on this list, so don't know if the definition of
  931. computer virus was properly discus- sed earlier and if some general
  932. definition was accepted. If was I would like to know which one. I saw
  933. different definitions in literature (I looked in the VIRUS-L FAQ too
  934. :-))and would like to sublime what I've read till now in following
  935. statement :
  936.  
  937.       Computer virus is set of instruction written with intention to
  938. cause some unwanted function in system in which is currently situated.
  939. Virus has ability of reproduction, it can propagate through different
  940. media, may evolve over time and can mutate.
  941.  
  942. Is that correct definition ? I would really like to know one which
  943. wouldn't lead to misunderstandings.
  944.  
  945.  Cheers,                                       ______________
  946.                                               |              |
  947.  Suzana                                      /|  Who am I ?  |
  948.                                  /~~~~~~\~\ / |______________|
  949.                                 (  * *   )/
  950.                                /(  ___   )
  951.                               ~  \______/
  952.                                 @/       \@
  953.  
  954. - ---------------------------------------------------------------------------
  955. Address: Suzana Stojakovic-Celustka          e-mail addresses:
  956.          Department of Computers             celustka@sun.felk.cvut.cs
  957.          Faculty of Electrical Engineering   celustkova@cs.felk.cvut.cs
  958.          Karlovo namesti 13
  959.          12135 Prague 2                      phone : (+42 2) 293485
  960.          Czechoslovakia                      fax : (+42 2) 290159
  961.  
  962. ------------------------------
  963.  
  964. End of VIRUS-L Digest [Volume 6 Issue 2]
  965. ****************************************
  966.  
  967.  
  968.