home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / v / vl5-207.zip / VL5-207.TXT < prev   
Internet Message Format  |  1993-01-06  |  29KB

  1. From lehigh.edu!virus-l Thu Dec 24 09:56:36 1992
  2. Date: Tue, 22 Dec 1992 09:26:08 -0500
  3. Message-Id: <9212221358.AA03720@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 V5 #207
  13. Status: R
  14.  
  15. VIRUS-L Digest   Tuesday, 22 Dec 1992    Volume 5 : Issue 207
  16.  
  17. Today's Topics:
  18.  
  19. CPAV leftovers: summary (PC)
  20. Another Kind Of Droppers (PC)
  21. Re: Integrity Master update (PC)
  22. VSHIELD, VIRSTOP, ... comparison ? (PC)
  23. Pink dos color -Virus? (PC)
  24. Re: Is this a new virus? (PC)
  25. Re: Virus Simulator MtE Available (PC)
  26. Tequila on the Pc (PC)
  27. CHKDSK & PC-DOS 5.00 (IBM) (PC)
  28. RE: VI-SPY 10.0 spitting out strange numbers... (PC)
  29. Re: INFO SOUGHT: FILLED virus (PC)
  30. Re: DAME update (PC)
  31. Re[2]: Stoned Virus (PC)
  32. Re: Vshield vs Virstop (PC)
  33. Viruses in OS/2 HPFS (OS/2)
  34. Problems in MCAFEE OS/2 Clean (OS/2)
  35. viruses in OS/2 environment (OS/2)
  36. Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
  37. Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
  38. Re: Viral Based Distribution System
  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:    Sat, 19 Dec 92 17:15:09 -0500
  59. From:    Luca Parisi <MC1980@mclink.it>
  60. Subject: CPAV leftovers: summary (PC)
  61.  
  62. Here is what I've found out about the "leftovers" I mentioned.
  63.  
  64. The "CARMEL Software" string is indeed added to files by the
  65. "Immunize" option of Central Point Anti Virus 1.0 and 1.2 (At least; I
  66. could only find those versions, and the new Windows one that has no
  67. such option).
  68.  
  69. It is not part of the integrity checking program, however. It seems to
  70. be used to pad the executable file to a multiple of 16 before adding
  71. the self-checker, but only under certain conditions (I was unable to
  72. replicate it except on NU.EXE, and I found another padding string
  73. elsewhere).  It is not deleted by the "Remove Immunization" option,
  74. although the file is restored to its original size. The padding string
  75. and a copy of the first bytes of the original immunized program can be
  76. read in the slack space and will disappear as expected when the
  77. deimmunized file is copied.
  78.  
  79. The user who originally faced the program had indeed used CPAV, not
  80. the original CARMEL product.
  81.  
  82. Thanks to those who supported me with suggestions.
  83.  
  84. Luca Parisi
  85. <MC1980@mclink.it>
  86.  
  87.  
  88. ------------------------------
  89.  
  90. Date:    Sat, 19 Dec 92 17:15:35 -0500
  91. From:    Luca Parisi <MC1980@mclink.it>
  92. Subject: Another Kind Of Droppers (PC)
  93.  
  94. Not much time ago, a posting by Stefano Turci (Stefano_Turci@
  95. f108.n391.z9.virnet.bad.se) prompted discussion about the fact that
  96. converting a file from .COM to .EXE caused scanners not to recognize
  97. some virus infections any more.
  98.  
  99. I don't have much to object to the views expressed by the scanners
  100. themselves (well, actually their authors :-) but I faced the same
  101. problem while dealing with the "leftovers" of my previous posting.
  102.  
  103. That is, files infected with virus 855 (Nov. 17th) and subsequently
  104. immunized with CPAV 1.2 are not recognized as such by F-Prot 2.06,
  105. Scan 97 or VirX 2.4 (I know they are not entirely up-to-date, but all
  106. three recognize the 'vanilla' infection on the same files).
  107.  
  108. I don't think this is more than an "academic" problem unless the
  109. current DOS version of CPAV still offers immunization, and a bit more
  110. if the rumored MSDOS 6.0-bundled one does (the most recent plain DOS
  111. CPAV I have is 1.2, and WinCPAV doesn't). More generally, I'd say that
  112. the integrity check should be a built-in function, otherwise it can
  113. only build false security.  But somebody here must have said that
  114. before and better than me...
  115.  
  116. Luca Parisi
  117. <MC1980@mclink.it>
  118.  
  119. ------------------------------
  120.  
  121. Date:    Fri, 18 Dec 92 22:38:06 +0000
  122. From:    Sara_Gordon@f0.n10.z9.virnet.bad.se (Sara Gordon)
  123. Subject: Re: Integrity Master update (PC)
  124.  
  125. just a note..
  126.  
  127. some people reading the virus-l/comp.virus want to get the a-v files,
  128. but aren' t able to use ftp, etc.  the list rob slade made of bbs that
  129. have the files is really quite good, but i'm not sure if they would
  130. all have the latest files such as integrity master, f-prot, tbscan,
  131. scan.
  132.  
  133. for people who do not know how to ftp or do file requests, simple
  134. downloading of files is available on 'traditional' type bbs (not the
  135. internet sites), and rob's list is very good for helping find a bbs
  136. near you that has these files.
  137.  
  138. anyone who wants to file request, or download these files can do so
  139. from my ( private) system :), the number is 219-273-2431. the login,
  140. if you wish to not identify yourself, is demo account.  the password
  141. is system. of course, i dont really want my system tied up all day and
  142. night doing this, so please look near you first, but if you cant find,
  143. consider this an invitation to get them here.
  144.  
  145. If you want to read the virus-L faq and cant ftp it, you can d/l it
  146. here, or read it online.
  147.  
  148. Intergrity Master is sent to this system directly from the author as
  149. is VirX.  F-Prot, Scan, TBscan, and the other programs are obtained
  150. from either the author's ftp sites, or a site utilized by the author.
  151. With all of the hacked a- v programs floating around, it is of course
  152. important to verify that the file you get is really -helping- you.
  153.  
  154.  
  155. # talk to me about those computer viruses....
  156. # sara@gator.use.com
  157. # vfr@netcom.com
  158. # SGordon@Dockmaster.ncsc.mil
  159.  
  160. - --- GEcho 1.00
  161.  * Origin: VFR SYSTEMS (219)273-2431 'ask us about VIRNET' (9:10/0)
  162.  
  163. ------------------------------
  164.  
  165. Date:    Sat, 19 Dec 92 06:03:00 +0000
  166. From:    Nemrod_Kedem@f101.n9721.z9.virnet.bad.se (Nemrod Kedem)
  167. Subject: VSHIELD, VIRSTOP, ... comparison ? (PC)
  168.  
  169. (Sorry, Aryeh... I just have to...)
  170.  
  171.  > 1) VShield can check the authentication codes added to the files by
  172.  > SCAN /AV (it is a BAD idea to modify other people's files!) and refuse
  173.  > to run those that are not "checksummed". Unfortunately, this feature
  174.  > can be trivially bypassed (i.e., it is trivial to write a virus that
  175.  > adds a correct checksum to the file it infects).
  176.  
  177. This is true when using VSHIELD with the /CV option. A better option
  178. to use is the /CF one, which compares the checksums from an external
  179. file created by SCAN /AF command and does not alter any executable
  180. file.
  181.  
  182.  > 3) VShield uses much more memory than VirStop.
  183.  
  184. But may be loaded to high memory, and then needs less then 1K of
  185. conventional memory.
  186.  
  187.  > 6) VShield can be removed from memory (very BAD idea!).
  188.  
  189. That's why there is the /NOREMOVE option...
  190.  
  191.      Regards,
  192.      Rudy.
  193.  
  194. - ----------------------------------------------------------
  195. Nemrod.Kedem@f101.n9721.z9.virnet.ftn       (Nemrod Kedem)
  196. FidoNet: 2:403/138   VirNet: 9:972/0, 9:9721/0, 9:9721/101
  197. (972)3-966-7562 (14.4K)            (972)3-967-0348 (Voice)
  198. P.O.Box 8394,     Rishon Le-Zion,   Zip 75253,     Israel.
  199. - ----------------------------------------------------------
  200.  
  201. - --- FastEcho 1.21/Real!
  202.  * Origin: <Rudy's Place - VirNet, Israel> Make Safe Hex! (9:9721/101)
  203.  
  204. ------------------------------
  205.  
  206. Date:    Sat, 19 Dec 92 20:58:00 +0000
  207. From:    Malte_Eppert@f6002.n491.z9.virnet.bad.se (Malte Eppert)
  208. Subject: Pink dos color -Virus? (PC)
  209.  
  210. Hello!
  211.  
  212.  > My default dos foreground color is Pink not low intensity
  213.  > white. Is this possibly a virus? I booted from a protected floppy
  214.  > master disk - - no change!
  215.  
  216. Does your monitor display the default gray at all after the failure?
  217. If not, try to fix your video cable. It just may be a loose contact.
  218. Had that before, and all the gray on the screen turned pink, until I
  219. fixed the cable.
  220.  
  221. cu!
  222. eppi
  223.  
  224. - --- Via SCANTOSS V 1.37
  225.  * Origin: No Point for viruses - The EpiCentre! (9:491/6002)
  226.  
  227. ------------------------------
  228.  
  229. Date:    21 Dec 92 11:50:23 +0000
  230. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  231. Subject: Re: Is this a new virus? (PC)
  232.  
  233. tck@fold.ucsd.edu (Kevin Marcus) writes:
  234.  
  235. > I have varients of stoned which copy to 0,0,15, and 0,0,7, as well as a
  236. > few other locations.  They do not necessarily copy to the same spot.
  237.  
  238. And we have here variants that put the original MBR at 0,0,2 and
  239. 0,0,8. This is irrelevant. What is rellevant is that the problem with
  240. Michelangelo occurs exactly because the "standard" Stoned variant put
  241. the original MBR at 0,0,7 - at the same place as Michelangelo, and
  242. because the two viruses do not recognize each other.
  243.  
  244. Regards,
  245. Vesselin
  246. - --
  247. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  248. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  249. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  250. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  251.  
  252. ------------------------------
  253.  
  254. Date:    21 Dec 92 12:45:03 +0000
  255. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  256. Subject: Re: Virus Simulator MtE Available (PC)
  257.  
  258. as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
  259.  
  260. >               Virus Simulator MtE Supplement Available
  261.  
  262. [stuff deleted]
  263.  
  264. >      Virus  Simulator  (introduced earlier) and this  new  Virus
  265. >      Simulator  MtE Supplement are not intended to  replace  the
  266. >      comprehensive   collection   of  real  virus   samples   as
  267. >      maintained  by Rosenthal Engineering and  other  anti-virus
  268. >      product   developers  for  testing.  Virus  Simulator   MtE
  269. >      Supplement  produces safe and controlled dummy  test  files
  270. >      that  enable users to verify that they have  installed  and
  271. >      are  using  their MtE virus detecting  programs  correctly,
  272. >      additionally  affording  an  opportunity  for  a   practice
  273. >      training drill under safe and controlled conditions.
  274.  
  275. I've had some very strong objections against your virus simulator in
  276. the past. I have not seen yet your MtE simulator, but I have the
  277. following questions about it:
  278.  
  279. 1) Does is simulate perfectly the behavior of the MtE? I.e., are the
  280. dummy files generated by it the same as if generated by the MtE? If
  281. not, then it is not good as a simulator, because the simulation is not
  282. perfect enough.
  283.  
  284. 2) If the answer of the above question is "yes", then it means that it
  285. uses the MtE itself to encrypt the dummy files - because using
  286. anything else would mean imperfect simulation. If it uses the MtE, do
  287. you include the MtE itself in the generated dummies?
  288.  
  289. 3) If the answer of the above question is "no", then the simulation is
  290. again not good enough, since the only way a scanner could detect the
  291. unencrypted replicants of an MtE-based virus is to scan for a scan
  292. signature of the unencrypted body of MtE. If the answer of the above
  293. question is "yes", then it is pretty easy to extract the MtE from the
  294. unencrypted dummies... Therefore, you are distributing malicious
  295. software...
  296.  
  297. Conclusion: regardless how you answer to the above questions, either
  298. the simulator is useless, or you are distributing malicious
  299. software... Hmm, I was able to draw this conclusion even without
  300. having to look at the simulator... Pretty good, isn't it?... :-)
  301.  
  302. Leaving the ethical problems aside, do you try all kinds of flags
  303. (i.e., the contents of the AX register before calling the MtE)?
  304. Because, if you don't, you'll be able to generate only a small subset
  305. of the code that can be generated with the MtE...
  306.  
  307. Regards,
  308. Vesselin
  309. - --
  310. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  311. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  312. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  313. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  314.  
  315. ------------------------------
  316.  
  317. Date:    Mon, 21 Dec 92 09:01:07 -0500
  318. From:    Mike Mulrooney <mulroonm@marvin.edge-hill-college.ac.uk>
  319. Subject: Tequila on the Pc (PC)
  320.  
  321. Could somebody out there please give me some info on the various
  322. strains of the TEQUILA virus. We have unfortunately contracted it at
  323. one of our sites here and there was no virus protection there to stop
  324. it (they feel pretty daft).
  325.  So I am left to try and pick up there pieces and would like to know a
  326. little background info on the little critter.  Also I am sorry if this
  327. is a FAQ but - what is the best SHAREWARE-FREEWARE-ETC software to use
  328. for the first line of defence, the RAM overhead and sig updates is
  329. important.  Many Thanks Mike Mulrooney -- Senior Network Technician
  330.                               Edge Hill College of HE - Lancs - UK
  331.  
  332. ------------------------------
  333.  
  334. Date:    Mon, 21 Dec 92 10:01:08 -0500
  335. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  336. Subject: CHKDSK & PC-DOS 5.00 (IBM) (PC)
  337.  
  338. My last last word on DOS 5.00 CHKDSK problem with big disks (promise)
  339.  
  340. It seems that the same problem *may* exist in PC-DOS 5.00 from IBM
  341. however I do not have PC-DOS 5.00 so cannot say for sure. However if
  342. it does exist, here is how to tell.
  343.  
  344. First PC-DOS VER/R is said to give a slightly different output than
  345. MS-DOS 5.00 VER/R e.g.
  346.  
  347.    IBM DOS Version 5.00
  348.    Revision 1  CSD URxxxxx 02/92
  349.  
  350. (note: this version apparently has the "fix")
  351.  
  352. According the report, PC-DOS uses CHKDSK.COM instead of CHKDSK.EXE
  353. (though still in .EXE format) and further, it is 16 bytes shorter than
  354. the MS-DOS 5.00 CHKDSK.EXE (16,184 bytes vs 16,200).
  355.  
  356. Accordingly, the fragment in question appears to be at DEBUG offset
  357. DS:2633h instead of DS:263Eh (offset used in my .BAT file was
  358. different since file was "converted" to permit update).
  359.  
  360. The same check should be valid (8B 4F 0F 8B F9 indicates the "early"
  361. version while 8B 7F 0F 32 ED is an indicator of the "fixed" CHKDSK)
  362. just at the different offset, but as said, I do not have a copy of
  363. either version of PC-DOS 5.00 so your guess is probably better than
  364. mine.
  365.  
  366.              *
  367.              |
  368.             abc
  369.            defgh               And a Merry Christmas to All,
  370.           ijklmno
  371.          pqrstuvwx                               Padgett
  372.         yzabcdefghi
  373.        jklmnopqrstuv
  374.            wxyz
  375.           __||__
  376.  
  377. ------------------------------
  378.  
  379. Date:    21 Dec 92 17:08:51 +0000
  380. From:    yoshida@microsupport.sas.upenn.edu (Dan P. Yoshida)
  381. Subject: RE: VI-SPY 10.0 spitting out strange numbers... (PC)
  382.  
  383. 12/21 I talked to RG Software:
  384.  
  385. According to them the numbers are debugging codes that only beta
  386. versions of 10.0 should display.  The numbers only showed up when
  387. vi-spy was being run by the AUTOVS program, so this could have been
  388. the problem somehow.
  389.  
  390. Their recommendation: erase the current version of vi-spy and
  391. reinstall from an original disk know to be a release version.
  392.  
  393. - --dan
  394.  
  395. [Moderator's note: Thanks for the follow-up, Dan.  This is exactly the
  396. sort of thing that I had in mind with regards to posting product
  397. support questions and summaries here.  I hope that others follow this
  398. example.]
  399.  
  400. Original post:
  401. > VI-SPY 10.0
  402. > RG Software Systems, Inc.
  403. >
  404. > Has anyone encountered this problem with VI-SPY 10.0?
  405. >
  406. > I have vi-spy running from the autoexec.bat on a Northgate
  407. > 386 that has a Stacker "stacked" drive.
  408. >
  409. > On boot up, vi-spy starts to check for viruses, then it spits
  410. > out four numbers, <<3031>>,<<3120>>,<<E8F4>>,<<4549>>,
  411. > then the system freezes (need to hit the reset button).
  412.  
  413.  
  414.  
  415. ------------------------------
  416.  
  417. Date:    Mon, 21 Dec 92 21:49:06 +0000
  418. From:    aryeh@mcafee.com (McAfee Associates)
  419. Subject: Re: INFO SOUGHT: FILLED virus (PC)
  420.  
  421. Hello Ken McVa,
  422.  
  423. You write:
  424. [...deleted...]
  425. >When SCANV was run, it warned of FILLED three times, after the format
  426.                                   ^^^^^^
  427. Filler virus, perhaps?
  428.  
  429. >- - local rumour has it FILLED resides on an area of the disk DOS
  430. >doesn't read - at any rate, after three warnings, the system was shut
  431. >down.
  432. [...deleted...]
  433.  
  434. When SCAN is run in the presence of certain other anti-viral programs,
  435. such as Central Point Anti Virus, it can erroneously report the presence
  436. of viruses because if the other program uses the same piece of code SCAN
  437. does to detect the virus but does not hide that code in memory.
  438.  
  439. Regards,
  440.  
  441. Aryeh Goretsky
  442. Technical Support
  443. - --
  444. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  445. McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
  446. 3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | IP# 192.187.128.1
  447. Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
  448.  
  449. ------------------------------
  450.  
  451. Date:    Mon, 21 Dec 92 18:23:54 -0500
  452. From:    Jimmy Kuo <cjkuo@ccmail.norton.com>
  453. Subject: Re: DAME update (PC)
  454.  
  455. Dave Mickle x5205 <MICKLE@csmcmvax.bitnet> reports:
  456. >Further investigation reveals DAME was reported by NAV V9.5, *NOT*
  457.                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  458. >some infected program running on the machine. SCAN V99 did not find
  459. >it.  The owner has good habits, controls access to the PC and is
  460. >careful about installing new software.  I'm concluding it's a false
  461. >positive.  I'd like to thank the folks at MacAfee and HI Industries
  462. >who were kind enough to call and offer the benefit of their
  463. >experience.
  464.  
  465. Um... DAME could *NOT* have been reported by NAV V9.5.  NAV does not
  466. have a version 9.5 and NAV uses the name "MtE", not "DAME".
  467.  
  468. Jimmy Kuo                                       cjkuo@ccmail.norton.com
  469. Norton AntiVirus Research
  470.  
  471. ------------------------------
  472.  
  473. Date:    Mon, 21 Dec 92 18:27:59 -0500
  474. From:    Jimmy Kuo <cjkuo@ccmail.norton.com>
  475. Subject: Re[2]: Stoned Virus (PC)
  476.  
  477. mrosen@nyx.cs.du.edu (Michael Rosen) writes:
  478. >I've encountered what seems to be a new variant of stoned (according
  479. >to a guy who works in the computer center here) on my diskettes when I
  480. >use them in our computer labs occassionally.  Norton Anti-Virus sees
  481. >as it as my boot sector being infected by Bloomington, while f-prot
  482. >says I have stoned.  According to f-prot's files in viruses,
  483. >Bloomington is a cousin to stoned.
  484.  
  485. What NAV reports as Bloomington is more commonly known as NoInt and has
  486. since had its name changed in NAV to NoInt.  NoInt is a stoned variant.
  487.  
  488. >The guy I spoke to is sending my diskette to the author of f-prot.
  489. >It's quite annoying; it creates invisible junk files on my diskettes.
  490. >I'll get a file name on there with portions of garbage characters and
  491. >some partial words like "DOS 5.0" or other words.  Just recently it
  492. >destroyed a bunch of files that thankfully I couldn't find again,
  493. >though it was a major pain.
  494.  
  495. Your data corruption is likely the result of the virus overwriting one of
  496. the sectors with its saved copy of the original boot sector.  The original
  497. boot sector looks to have been written over a sector that serves as your
  498. directory sector thus creating a number of strange looking files.  It is
  499. not that you have invisible junk files on your diskettes but rather the
  500. directory table is bad.  (Garbage in certain fields that get translated as
  501. file names, garbage in other fields that translated into where the supposed
  502. file begins...)  You can edit the directory to eradicate the bad filenames
  503. or better yet, copy off the files you know and reformat the diskettes.
  504.  
  505. Jimmy Kuo                                       cjkuo@ccmail.norton.com
  506. Norton AntiVirus Research
  507.  
  508.  
  509.  
  510. ------------------------------
  511.  
  512. Date:    22 Dec 92 00:24:47 +0000
  513. From:    frisk@complex.is (Fridrik Skulason)
  514. Subject: Re: Vshield vs Virstop (PC)
  515.  
  516. maven@kauri.vuw.ac.nz (Jim Baltaxe) writes:
  517.  
  518. >Maybe this is being greedy, but would it be possible for you to put a
  519. >switch into VIRSTOP that would force it to use the Secure scan
  520. >mechanism?
  521.  
  522. Possible, but difficult.  The biggest problem is that VIRSTOP is written in
  523. 100% assembly, while the Secure scan is in a C/assembly mix.  If I created
  524. a "Secure Scan" version of Virstop, I don't see how I could get the memory
  525. requirements below 30K.  The 2K size (if using /DISK) is ok for most users,
  526. but 30K is a different story...
  527.  
  528. - -frisk
  529.  
  530. ------------------------------
  531.  
  532. Date:    Sun, 20 Dec 92 15:02:25 +0000
  533. From:    bjl1@Ra.MsState.Edu (Brett J.L. Landry)
  534. Subject: Viruses in OS/2 HPFS (OS/2)
  535.  
  536. There has been aa lot of talk about OS/2 not being able to be infected
  537. from regular old DOS boot sector viruses using the HPFS. This is false
  538. since regular old STONED can infect both logical and physical parttions
  539. on OS/2 using HPFS.  Why wait for true OS/2 viruses when you can suffer
  540. from regular DOS viruses.
  541. - --
  542.  
  543. - ---------------------------------------------------------------------
  544. |------------------ Brett J.L. Landry,  bjl1@ra.msstate.edu, -------|
  545.  
  546. ------------------------------
  547.  
  548. Date:    Sun, 20 Dec 92 15:12:05 +0000
  549. From:    bjl1@Ra.MsState.Edu (Brett J.L. Landry)
  550. Subject: Problems in MCAFEE OS/2 Clean (OS/2)
  551.  
  552. I downloaded the new OS/2 wares from Mcafee and had mixed results.
  553. OScan discovered that there was stoned in two partitions on 120 meg
  554. drive that was partitioned into a 40 and 80 meg C and D respective
  555. drives.  The problem came into play when I cleaned using OSclean.
  556. It removed stoned but also removed the second partition loosing the 80
  557. meg section.    This was in a single boot HPFS scenario.
  558.  
  559. Any thoughts on this would be appreciated.
  560.  
  561. Brett J.L. Landry
  562. - --
  563.  
  564. - ---------------------------------------------------------------------
  565. |------------------ Brett J.L. Landry,  bjl1@ra.msstate.edu, -------|
  566.  
  567. ------------------------------
  568.  
  569. Date:    Mon, 21 Dec 92 11:32:23 +0000
  570. From:    tytgat@esat.kuleuven.ac.be
  571. Subject: viruses in OS/2 environment (OS/2)
  572.  
  573. I'm looking for information (books, articles, news-items...) about the
  574. spread of virusses in an OS/2-environment : have any infections (DOS
  575. or OS/2 viruses) been reported yet ; what's the impact of
  576. compartmentalisation on the infection power of DOS-viruses ; how is
  577. this compartmentalisation actually realised within OS/2, etc. ...
  578. Thanks.
  579.                      Pedro Tytgat
  580.  
  581. ------------------------------
  582.  
  583. Date:    Mon, 21 Dec 92 22:07:12 +0000
  584. From:    aryeh@mcafee.com (McAfee Associates)
  585. Subject: Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
  586.  
  587. Hello Vesselin,
  588.  
  589. You write:
  590. >>I write:
  591.  
  592. >This is not actually a problem. Since the scanner runs in its own area
  593. >of memory, protected from the other processes, it cannot be fooled by
  594. >a stealth virus and cannot be made to spread a fast infector on all
  595. >files it scans... In fact, I am wondering why a memory check is
  596. >performed at all by an OS/2-based scanner...
  597.  
  598. Are you aware OS/2 scanners that do?  I know that IBM's Antivirus/2
  599. has a DOS-based TSR component which scans memory when a DOS session is
  600. started up.  But that's really an anti-viral for DOS, not OS/2.
  601.  
  602.  
  603. >> - -      OS2SCAN checks "extended filenames" and HPFS-partitioned
  604. >>        drives as well as DOS (FAT) drives.
  605.  
  606. >Do you know any way in which a known DOS virus can infect an extended
  607. >filename on an HPFS partition?
  608.  
  609. Nope.  But I myself create directories under OS/2 HPFS with names like
  610. "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
  611. files.  I'm sure other people do as well :-)
  612.  
  613. Regards,
  614.  
  615. Aryeh Goretsky
  616. Technical Support
  617.  
  618. - --
  619. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  620. McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
  621. 3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | IP# 192.187.128.1
  622. Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
  623.  
  624. ------------------------------
  625.  
  626. Date:    Tue, 22 Dec 92 08:51:58 -0500
  627. From:    Kenneth R. van Wyk <krvw@cert.org>
  628. Subject: Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/
  629.      2)
  630.  
  631. Aryeh Goretsky writes (in response to Vesselin):
  632.  
  633. > >Do you know any way in which a known DOS virus can infect an extended
  634. > >filename on an HPFS partition?
  635. >
  636. > Nope.  But I myself create directories under OS/2 HPFS with names like
  637. > "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
  638. > files.  I'm sure other people do as well :-)
  639.  
  640. I, for one, use long file/dir names (such as these) extensively on my
  641. home OS/2 system.  A short filename scanner (e.g., a DOS-based product
  642. running in a DOS session) would see only a very small portion of my
  643. primary HPFS partition, which has DOS files strewn all over it.  That
  644. is why I use an OS/2-specific product.  Opinion: long filenames is one
  645. of the things that makes HPFS so nice to work with, especially when
  646. combined with a command interpreter that can do name completion.
  647.  
  648. Cheers,
  649.  
  650. Ken van Wyk
  651.  
  652. ------------------------------
  653.  
  654. Date:    21 Dec 92 12:35:04 +0000
  655. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  656. Subject: Re: Viral Based Distribution System
  657.  
  658. ygoland@edison.SEAS.UCLA.EDU (The Jester) writes:
  659.  
  660. > If the purpose of the program is to automatically cause some
  661. > 'change' in various computers, then the program must execute from a
  662. > loader or an infected file. If its being launched from a loader then
  663. > the need for the distribution system is nullified. Assuming the goal
  664. > is to still keep absolute system security, then the loader will be
  665. > 'allowed' in by the administrator but the virus it is loading won't
  666. > be allowed to attach itself to another program, just make the change
  667. > for the single user that activated the loader.
  668.  
  669. Yes, this is exactly how the current products with virus-like
  670. distribution work. The "loader" is the system login script of Novell
  671. NetWare. When the user logs in, the script checks whether his/her
  672. workstation has an up-to-date version of the software, and if not
  673. copies the newest version of the software from a secure directory on
  674. the server to the workstation and requests a reboot.
  675.  
  676. > If this is an
  677. > effective means of distribution then why use a virus at all?
  678.  
  679. The question is incorrect. According to Dr. Cohen's definition, "this"
  680. - -is- a virus. And, since you are using it to do something you would
  681. like to be done, it is obviously a benevolent virus. Do you see the
  682. misunderstanding now? It's all matter of definitions...
  683.  
  684. > In conclusion, a system that changes in an unpredictable manner,
  685. > that uses hard to track mechanisms of change, is a security
  686. > nightmare.
  687.  
  688. Yup... Ever tried MS Windows?... :-)
  689.  
  690. > Just as self modifying programs have been given a very
  691. > bad reputation for very good reasons, a viral based distribution
  692. > system deserves a similarly bad reputation.
  693.  
  694. Does it? Why? Because of the word "virus"? But they just don't use
  695. that word when selling you the package! They call it "Installs and
  696. Updates Hundreds of PCs on a Network in One Easy Step" (Symantec),
  697. "Completely Centralized Anti-Virus Strategy" (Central Point Software)
  698. or others some such...
  699.  
  700. >        The Jester-PGP Ver2 upon Request
  701.  
  702. Please consider this a request... :-)
  703.  
  704. Regards,
  705. Vesselin
  706. - --
  707. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  708. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  709. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  710. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  711.  
  712. ------------------------------
  713.  
  714. End of VIRUS-L Digest [Volume 5 Issue 207]
  715. ******************************************
  716.  
  717.  
  718.