home *** CD-ROM | disk | FTP | other *** search
/ Play and Learn 2 / 19941.ZIP / 19941 / PUBE / VIR04023.TXT < prev    next >
Encoding:
Text File  |  1994-02-05  |  21.0 KB  |  505 lines

  1.  
  2.  
  3.            VIRUS-L Digest   Friday,  8 Feb 1991    Volume 4 : Issue 23
  4.  ******************************************************************************
  5.  
  6.  
  7. Today's Topics:
  8.  
  9. Antivirus-Plus review (PC)
  10. Virus questions (PC)
  11. Too much on infection checkers
  12. Reporter seeks help on story about a Mac virus (Mac)
  13. Boot sector self-check (PC)
  14. Alameda/Yale (PC)
  15.  
  16. VIRUS-L is a moderated, digested mail forum for discussing computer
  17. virus issues; comp.virus is a non-digested Usenet counterpart.
  18. Discussions are not limited to any one hardware/software platform -
  19. diversity is welcomed.  Contributions should be relevant, concise,
  20. polite, etc.  Please sign submissions with your real name.  Send
  21. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  22. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  23. anti-virus, documentation, and back-issue archives is distributed
  24. periodically on the list.  Administrative mail (comments, suggestions,
  25. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  26.  
  27.    Ken van Wyk
  28.  
  29. ---------------------------------------------------------------------------
  30.  
  31. Date:    Mon, 04 Feb 91 11:05:46 -0800
  32. From:    p1@arkham.wimsey.bc.ca (Rob Slade)
  33. Subject: Antivirus-Plus review (PC)
  34.  
  35.                                Comparison Review
  36.  
  37. Company and product:
  38.  
  39. Techmar Computer Products
  40. 97 - 77 Queens Blvd.
  41. Rego Park, NY   11374
  42. USA
  43. 718-997-6800
  44. Antivirus Plus (purported "AI vaccine")
  45.  
  46.  
  47. Summary:
  48.  
  49. Protection against major known viri and some viral type activites from
  50. new or unknown viri.  Easy setup with no requirement for user decisions,
  51. but strong possibility of interference with normal computer operations.
  52. If used, it is recommended that experienced viral specialists be
  53. available to handle infections identified.  Not recommended for systems
  54. with frequent changes in software or configuration.
  55.  
  56. Cost    $99.95 US
  57.  
  58. Rating (1-4, 1 = poor, 4 = very good)
  59.       "Friendliness"
  60.             Installation      2
  61.             Ease of use       4
  62.             Help systems      1
  63.       Compatibility           2
  64.       Company
  65.             Stability         3
  66.             Support           ?
  67.       Documentation           2
  68.       Hardware required       2
  69.       Performance             2
  70.       Availability            2
  71.       Local Support           1
  72.  
  73. General Description:
  74.  
  75. CURE is a manual scanning program with disinfection features.  IMMUNE2
  76. is a resident scanner that checks files as they are loaded, disks when
  77. accessed, and memory when the program is first loaded.  PREVENT1 is a
  78. resident vaccine program.
  79.  
  80. Antivirus-Plus will detect infections by currently common viri.  The
  81. promise of detection of unknown viri is possible, but not likely in the
  82. case of more advanced viral programs.
  83.  
  84. Recommended only for situations using the computer in fairly limited and
  85. standard fashion, where automated attendance is a primary concern.
  86.                   Comparison of features and specifications
  87.  
  88.  
  89.  
  90. User Friendliness
  91.  
  92. Installation
  93.  
  94. Antivirus-Plus appears to require installation from the A: drive onto a
  95. hard disk.  It is possible to install onto a foppy disk, and it is
  96. possible to install from a drive other than A:, but it will continue to
  97. request a "writeable" disk in A:.
  98.  
  99. The documentation states that removal from the hard drive requires
  100. "de-installation", but this does not appear to be the case.
  101.  
  102. Installation is almost completely automated.  Modification of
  103. AUTOEXEC.BAT is not sophisiticated, but did not cause problems in
  104. testing.
  105.  
  106. Ease of use
  107.  
  108. IMMUNE2 and PREVENT1 are automatic, background processes which operate
  109. without operator attention.  When the programs "identify" a process,
  110. they do not do so either by virus name, or by identity of infected
  111. program.  The user is requested (by IMMUNE2) to run CURE, but no
  112. parameters are given.  See also "Compatibility" regarding false alarms.
  113.  
  114. Help systems
  115.  
  116. None provided.
  117.  
  118. Compatibility
  119.  
  120. Both CURE and IMMUNE2 identify common and well known viri, although not
  121. always by the "standard" names.  Jerusalem-B is identified as "Black
  122. Friday #1", for example.  All Antivirus-Plus programs are fairly noisy
  123. about their detection of a virus, vis the message that appears when
  124. IMMUNE2 is invoked while a virus is present in memory:
  125.  
  126.   >                             +==========================+
  127.   >                             " Warning !!               "
  128.   >   Fri  1-18-1991 13:02:09.49"   You are using  an      "
  129.   >   A>antvirus\immune2        "   infected disk(ette).   "
  130.   >   !! A Virus is present in y"                          "
  131.   >   !! Removing the virus now " Use ANTI VIRUS "cure"    "
  132.   >   !! A Virus is present in y" program to remove virus. "
  133.   >   !! Removing the virus now "                          "
  134.   >   !! A Virus is present in y" Hit any key to continue  "
  135.   >   !! Removing the virus now +==========================+
  136.   >   !! A Virus is present in your computer memory !!
  137.   >   !! Removing the virus now !!
  138.   >   !! A Virus is present in your computer memory !!
  139.   >   !! Removing the virus now !!
  140.   >   !! A Virus is present in your computer memory !!
  141.   >   !! Removing the virus now !!
  142.   >   The ANTI-VIRUS immunity program is now resident.
  143.  
  144. The same window, without quite so much "background noise", appears when
  145. any disk, infected with a known boot sector virus, is accessed, even by
  146. a directory request.  It also appears when an infected program is run,
  147. and states that the program has been disinfected.  The program is *not*
  148. disinfected on disk, but the virus appears to be barred from memory.
  149. (Note that the virus in memory which triggered the display above was not
  150. removed from memory, but was rendered inactive.)
  151.  
  152. The PREVENT1 program, however, fairs rather worse.  It does not appear
  153. to prevent any change to the boot sector, and therefore it seems that
  154. new boot sector viri will be undetectable by the program, unless they
  155. are very crude.  This problem, however, is pale in comparison with the
  156. problems PREVENT1 will cause with normal, uninfected, programs.
  157.  
  158. If you use a program (such as a word processor) to delete or modify a
  159. program file, PREVENT1 will halt program execution.  This may not seem
  160. like a big deal: after all, how many people use (as I do) Word Perfect
  161. as a disk manager?  However, some programs, Word Perfect among them,
  162. make changes to the program itself when you change some part of the
  163. configuration, and PREVENT1 will stop this as well, telling you:
  164.  
  165.   >                                     Set-up Menu
  166.   >
  167.   >   0 - End Set-up and enter WP
  168.   >
  169.   >   1 - Set Directories or Drives for Dictionary and Thesa
  170.   >   2 - Set Initial Settings
  171.   >   3 - Set Screen and Beep Options
  172.   >   4 - Set Backup Options    +==========================+
  173.   >                             " Warning !!               "
  174.   >   Selection: 0              "  You have been running   "
  175.   >                             "  an infected program.    "
  176.   >   Press Cancel to ignore cha"                          "
  177.   >                             " PREVENT1 has removed the "
  178.   >                             "  memory infection !      "
  179.   >                             "                          "
  180.   >                             " Hit any key to continue  "
  181.   >                             +==========================+
  182.  
  183. It is, therefore, inadvisable to use Antivirus-Plus on a system which
  184. undergoes frequent changes in this manner.
  185.  
  186. PREVENT1 is not completely consistent here.  Word Perfect is halted when
  187. trying to delete a program file, PCTOOLS is not.  It is, therefore,
  188. quite possible that some viri may slip past this protection.
  189.  
  190.  
  191. Company Stability
  192.  
  193. Techmar is the distributor of Antivirus-Plus and other IRIS products in
  194. the United States.  Fink Enterprises, which distributes IRIS products in
  195. Canada, will not carry Antivirus-Plus.
  196.  
  197. Company Support
  198.  
  199. Help line support was not used in testing.  Techmar shipped very
  200. quickly, but did not properly identify the package, which created
  201. problems at the border.
  202.  
  203. Documentation
  204.  
  205. Documentation is provided solely on disk.  The directions are clear and
  206. readable, but very little information is provided beyond the most basic
  207. installation information.  Some information is the documentation is not
  208. consistent with program operation, but not to the point of preventing
  209. installation or operation.
  210.  
  211. Hardware Requirements
  212.  
  213. Documentation states hard disk required, but this can be avoided.  Disk
  214. "wants" to be installed from A: drive.
  215.  
  216. Performance
  217.  
  218. IMMUNE2 and CURE will identify many common viri.  They fail to identify
  219. the AIDS virus, which is interesting in that, while AIDS infections are
  220. not common, the virus source code is available and widely known to
  221. researchers.  (CURE was the first "scanning" program tested not that was
  222. not able to identify the virus.)
  223.  
  224. PREVENT1 will prevent some disk writes to program files, but allows
  225. others to pass, including the deletion of program files.  It apparently
  226. does not check any writes to disk boot sectors or "bad" sectors.
  227.  
  228. Local Support
  229.  
  230. None stated or found.
  231.  
  232. Support Requirements
  233.  
  234. Alarms will likely require intervention by experienced personnel.
  235.  
  236. copyright 1991 Robert M. Slade
  237.  
  238. Vancouver          p1@arkham.wimsey.bc.ca           _n_
  239. Insitute for       Robert_Slade@mtsg.sfu.ca          H
  240. Research into      (SUZY) INtegrity                 /
  241. User               Canada V7K 2G6                O=C\
  242. Security                            Radical Dude   | O- /\_
  243.                                              /-----+---/ \_\
  244.                                             / |    `  ||/
  245. "A ship in a harbour is safe, but that     /  ||`----'||
  246. is not what ships are built for."             ||      ||
  247.                      - John Parks             ``      ``
  248.  
  249. ------------------------------
  250.  
  251. Date:    Wed, 06 Feb 91 14:10:57 +0000
  252. From:    boone@athena.cs.uga.edu (Roggie Boone)
  253. Subject: Virus questions (PC)
  254.  
  255. I have 4 questions regarding computer viruses.  I am rather new to the
  256. study of compuer viruses and the texts that I have read have not answered
  257. these questions for me.
  258.  
  259. 1)  I have seen the SCAN software (MaAffee) scan a computer's memory for
  260.     viruses and noticed that it only scanned the base 640K of RAM.  Do
  261.     viruses typically not infect or use extended/expanded memory?  Are there
  262.     virus scanning packages that will scan the additional memory?  I raise
  263.     this question, because it seems I read somewhere that some computers
  264.     with certain memory management drivers may not erase the contents of
  265.     extended memory on a warm boot, and hence may not erase any virus that
  266.     may be sitting in extended memory. (My memory isn't too good on this
  267.     topic).
  268.  
  269. 2)  Are there anti-virus packages (for PC or any computer) that use
  270.     artificial intelligence techniques to protect the system, or is such
  271.     an effort overkill?
  272.  
  273. 3)  Not meaning to plant ideas, but I was talking with a facutly member
  274.     in the dept. where I work, and the question arose as to whether a virus
  275.     could be transmitted to an orbiting satellite and cause the same havoc
  276.     that viruses cause us PC users.  Is this possible?
  277.  
  278. 4)  I have also noticed that SCAN, for instance, scans basically the .EXE,
  279.     .COM, .SYS, .OVL files in a directory.  Do viruses not infect .TXT or
  280.     .DOC files or maybe C (Pascal, Basic) source code?
  281.  
  282. I hope these questions have not recently been asked (I'm a new subscriber
  283. to this group).  Thanks for any info about any or all of these questions.
  284.  
  285. Roggie Boone    (boone@athena.cs.uga.edu)
  286. Research Tech. III
  287. University of Georgia
  288.  
  289. ------------------------------
  290.  
  291. Date:    Mon, 04 Feb 91 08:21:56 -0500
  292. From:    padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson)
  293. Subject: Too much on infection checkers
  294.  
  295. >From:    "Nick FitzGerald" <CCTR132@csc.canterbury.ac.nz>
  296.  
  297. >If a virus such as STONED infected a machine with a cherry "All is OK"
  298. >message in the boot sector, you would continue to see this now
  299. >terribly misleading message after the STONED code loaded and passed
  300. >control to the original boot sector.
  301.  
  302. >If the "All is OK" boot sector did a check of the actual (physical)
  303. >boot sector then it wouldn't give an erroneous message if the disk was
  304. >infected with STONED or similar boot sector infectors, but it would
  305. >still give a misleading report if a stealth boot sector infector
  306. >struck, as the virus would intercept the attempt to read the boot
  307. >sector and return the contents of the original from its hiding place.
  308. >(This seems to be a lot of extra code to jam into a single sector...
  309.  
  310. Yes, it was but the following capabilities were able to be placed into 512
  311. bytes (with NONE left over though the ASCII and some of the "nice" could be
  312. reduced) - remember, this is in the partition table, not the boot sector:
  313.  
  314. 1) Validity check of disk access through BIOS
  315. 2) Self-Check of own code (every byte)
  316. 3) Validity check absolute sector 1 (every byte)
  317. 4) Validity check of real partition table (every byte)
  318. 5) Password control of disk access - unlimited length
  319. 6) Print Logo
  320. 7) Print error messages
  321. 8) Lock system on error
  322.  
  323. Following Boot:
  324.  
  325. 1) Prevent read or write to check code
  326. 2) Prevent write to partition table, hidden sectors, or first boot sector
  327. 3) Prevent low-level format to entire disk
  328.    (if a second physical disk is present, all also apply to it)
  329. 4) Display error message if any of the above occur
  330. 5) Provide verifyable direct access to disk services even if "stealth"
  331.    infection occurs.
  332. 6) Prevent DOS access to fixed disk(s) if booted from floppy.
  333.  
  334. This has been able to catch everything thrown at it so far (and my collection
  335. is pretty good).
  336.  
  337. It seemed that every step of the way, other possibilities opened up (this
  338. started out to be a simple password protection scheme) though I will admit
  339. that lasagna code (spagetti code is traceable) was necessary and it kind of
  340. pulls itself up by its bootstraps. Just to make things sillier, the whole
  341. thing was written using DEBUG since MASM or C did not provide enough control.
  342. ("What I did on my Christmas Vacation")
  343. - --------------------------------------------------------------------------
  344.  
  345. >[J.] Christian Kohler Keele university, csw76%keele.ac.uk@nsfnet-relay.ac.uk
  346. > Isn't it easy to build a
  347. >self-checker into a program ( as suggested WP has done )? I could
  348. >imagine that you just check the .exe when it is running, you could
  349. >play around with some XOR's to create a check. You could even put the
  350. >value in a seperate file, as long as your checking algorithm is
  351. >complexe enough.
  352.  
  353. Problem is that with the "stealth" viruses, the original, uninfected file is
  354. what is presented to the checker. Unless you KNOW you have a clean system,
  355. such checkers can be defeated by viruses already known. (for fun, infect
  356. a disk with the 4096 and then run McAfee's excellent SCAN with the /nomem
  357. switch (you don't do you? I use /m whenever in doubt which is often) set.
  358.  
  359.                                         Padgett
  360.  
  361.     (definately my own views - no-one else knows what I'm talking about)
  362.                 (well, maybe Chip Hyde or Andy Hopkins)
  363.  
  364. ------------------------------
  365.  
  366. Date:    Wed, 06 Feb 91 18:23:10 +0000
  367. From:    adamg@world.std.com (Adam M Gaffin)
  368. Subject: Reporter seeks help on story about a Mac virus (Mac)
  369.  
  370. Hi, all!
  371.  
  372. I'm a reporter at the Middlesex News in Framingham, Mass. The new
  373. governor here had some trouble getting his budget to the Legislature this
  374. week, allegedly because of a virus, and I'd be most grateful if somebody
  375. could help me out with a story.
  376.  
  377. Seems one of his aides was up late finishing the budget on his Mac II
  378. (as in 3 a.m.) for delivery to the Legislature that morning. He had just
  379. typed about 50 (!) pages of the document in MacWrite, when it refused to
  380. save the document. He eventually was able to retrieve an early version of
  381. the document, which he had filed under a different name, but those 50
  382. pages were gone.
  383.  
  384. When he ran Interferon 3.1 he got this messages: "Virus Type 003 on the
  385. TOPS network." The computer had been part of LAN in the Office of
  386. Administration and Finance but was taken off and moved to his office so
  387. he could work on the document (the governor's office actually uses an old
  388. Wang system, but since the guy was new and time was short, he figured
  389. he'd work with what he already knew).  The office is now busy checking
  390. all the other computers, of course, and the aide in question has been
  391. told to save his documents more often!
  392.  
  393. So, does anybody know what kind of virus this might be and how common
  394. it is? And is it true that Mac viruses are easier to write than PC
  395. ones (one of our PC people told me that; maybe she's biased :-) ). And,
  396. in the Dumb Question of the Week category: how might the virus have
  397. gotten into the network in the first place? I assume it would be somebody
  398. bringing an infected disk in from home (the LAN is not tied to any other
  399. network), but might there be other ways (short of the Dukakoids
  400. sabotaging the system, which I doubt, given they had no idea it was going
  401. to be used to write the budget, since they did all that on their Wangs).
  402.  
  403. Any help would be most appreciated! Thanks!
  404.  
  405. Adam Gaffin
  406. Middlesex News, Framingham, MA
  407. adamg@world.std.com
  408. Voice: (508) 626-3968
  409. Fred the Middlesex News Computer: (508) 872-8461
  410.  
  411. ------------------------------
  412.  
  413. Date:    05 Feb 91 10:29:26 -0500
  414. From:    Steve Albrecht <70033.1271@CompuServe.COM>
  415. Subject: Boot sector self-check (PC)
  416.  
  417. > From:    gt154c@prism.gatech.edu  (Gatliff, William A.)
  418.  
  419. > To help combat this, what would be the possibility of deliberately
  420. > infecting ones boot-sector with a piece of code that would display
  421. > some kind of 'ok' message if it hadn't been tampered with?
  422.  
  423. While waiting for the same type of self-check in the boot sector, we
  424. have developed a small program (so far only intended to protect
  425. ourselves against reinfection by the Stoned virus) which does the
  426. following:
  427.  
  428.    1.   Reads the partition table sector (absolute sector 1).
  429.  
  430.    2.   Compares the sector with a previously saved copy of absolute sector 1
  431.         (in a DOS file).
  432.  
  433.    3.   Writes (using Int 13h) the saved copy to absolute sector 1 in the event
  434.         of a discrepancy.
  435.  
  436.    4.   Immediately reboots the machine with a system reset (hard boot).
  437.  
  438. This program is placed in the AUTOEXEC.BAT file (this does lead to the
  439. possibility that the process can be disabled very easily).  A separate
  440. initialization program is used to save the "clean" copy of absolute
  441. sector 1 (necessary for step 2 above).  This file must be saved at a
  442. time when the sector is known to be clean.  We have used McAfee's SCAN
  443. and direct examination of the sector with a low-level sector editor to
  444. verify that absolute sector 1 is "clean".
  445.  
  446. The immediate reboot (step 4) is necessary because the Stoned virus is
  447. still in memory at this point, and a reboot will prevent the virus
  448. from rewriting itself to the partition table.
  449.  
  450. This process monitors and corrects problems in absolute sector 1 only.
  451. If a virus changes additional sectors, this process will restore the
  452. original code in the partition table, and the system should boot
  453. normally, if no changes have been made to the boot sector (logical
  454. sector 1).
  455.  
  456. This process is not as complex as programming a self-check into the
  457. code contained in the partition table sector, and is perhaps not as
  458. effective as a deterrent to partition table viruses in general.
  459. However, it works very effectively against the Stoned virus.  We have
  460. not had a chance to test it against other partition table viruses.
  461.  
  462. One caveat, though, is that this process will not work against a virus
  463. which somehow prevents the write operation in step 3 above.  Luckily,
  464. the Stoned virus does not interfere.
  465.  
  466. One additional benefit we have realized is that in the case of
  467. accidental corruption of the partition table, the saved copy can be
  468. found with a low-level sector editor, and restored to absolute sector
  469. 1.  We haven't had cause to use this benefit yet, but it is there if
  470. the need arises.
  471.  
  472. We will likely improve on this program (barring availability of a
  473. commercial alternative), but I share the idea for what it may be worth
  474. to any of you who have been plagued by pesty comments about
  475. legalisation.
  476.  
  477. Steve Albrecht
  478. 70033,1271@compuserve.com
  479.  
  480. ------------------------------
  481.  
  482. Date:    Wed, 06 Feb 91 24:45:00 -0800
  483. From:    Michael_Kessler.Hum@mailgate.bitnet
  484. Subject: Alameda/Yale (PC)
  485.  
  486. Someone just brought in 3 diskettes, 2 of which contained only text
  487. files, the last one contained an application.  None of them were boot
  488. diskettes (although they may have been originally and someone simply
  489. erased the command.com file).  F-Prot's (version 1.13) F-Disinf
  490. claimed that all three had the Alameda/Yale virus.  But when asked to
  491. clean the boot sector, I received that message that the virus could
  492. not be removed, no boot sector was found.  Copying the files to a new
  493. disk and reformatting the disks solved the problem. But is there any
  494. explanation for finding the virus in an infected boot sector that then
  495. cannot be found?
  496.  
  497. ------------------------------
  498.  
  499. End of VIRUS-L Digest [Volume 4 Issue 23]
  500. *****************************************
  501.  
  502.  
  503.  
  504.  
  505.