home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 720.VIRUSL6.091 < prev    next >
Text File  |  1993-06-03  |  54KB  |  1,158 lines

  1. VIRUS-L Digest   Friday,  4 Jun 1993    Volume 6 : Issue 91
  2.  
  3. Today's Topics:
  4.  
  5. Re: Digital Enterprises $5,000 challenge! $$$ $$$
  6. Re: Digital Enterprises $5,000 challenge! $$$ $$$
  7. Re: Digital Enterprises $5,000 challenge! $$$ $$$
  8. Re: Digital Enterprises $5,000 challenge! $$$ $$$
  9. Use of cryptanalysis in virus-hunting.
  10. Virus as extortion
  11. Re: The Anti-Viral Software of MS-DOS 6.0 (PC)
  12. Re: Viruses that cost $$$ (PC)
  13. Re: CPAV updates? (PC)
  14. Re: Is "Untouchable" (V-ANALYST) Effective? (PC)
  15. Handle Redirection (MSDOS) (PC)
  16. Re: CPAV updates? (PC)
  17. Re: CPAV updates? (PC)
  18. Re: Is "Untouchable" (V-ANALYST) Effective (PC)
  19. Re: Redirection Difficulty (PC)
  20. Re: On the merits of VSUM (PC)
  21. Re: Corrections (CPAV) (PC)
  22. Re: Misidentification by F-Prot 2.08a (PC)
  23. Re: The Anti-Viral Software of MS-DOS 6 (PC)
  24. Re: Misidentification by F-Prot 2.08a (PC)
  25. Virus?? filename 'n' and content 'U---ntion' (PC)
  26. New anti-virus package available via ftp (PC)
  27.  
  28. VIRUS-L is a moderated, digested mail forum for discussing computer
  29. virus issues; comp.virus is a gatewayed and non-digested USENET
  30. counterpart.  Discussions are not limited to any one hardware/software
  31. platform - diversity is welcomed.  Contributions should be relevant,
  32. concise, polite, etc.  (The complete set of posting guidelines is
  33. available by FTP on cert.org or upon request.)  Please sign submissions
  34. with your real name; anonymous postings will not be accepted.
  35. Information on accessing anti-virus, documentation, and back-issue
  36. archives is distributed periodically on the list.  A FAQ (Frequently
  37. Asked Questions) document and all of the back-issues are available by
  38. anonymous FTP on CERT.org (192.88.209.5).
  39.  
  40. Administrative mail (e.g., comments, suggestions, beer recipes)
  41. should be sent to me at: krvw@AGARNE.IMS.DISA.MIL.
  42.  
  43. All submissions should be sent to: VIRUS-L@Lehigh.edu.
  44.  
  45.    Ken van Wyk
  46.  
  47. ----------------------------------------------------------------------
  48.  
  49. Date:    Thu, 03 Jun 93 11:27:00 -0400
  50. >From:    duck@nuustak.csir.co.za
  51. Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$
  52.  
  53. Thus spake miser@stein2.u.washington.edu (Robert Fulwell):
  54. >       The Gaithersburg, Md-based company says virus experts
  55. >    have tried unsuccessfully for more than 2 years to defeat
  56. >    its V-Card Anti-Virus System. It's inviting hackers to come
  57. >    to its headquarters through mid-July to try their hand at
  58. >    loading a true virus (Trojan horses and bombs don't count)
  59. >    onto the system. The computer must be rendered non-bootable
  60. >    and files must be non-recoverable while V-Card is operating.
  61. >       The company will reward the triumphant hacker with $5000.
  62.  
  63. This is ludicrous. Firstly, they're inciting others to write viruses
  64. (a crime in some countries); secondly, rendering a computer
  65. non-bootable is easy (a large hammer, a medium-sized brick, or a few
  66. decades, will probably do the job); thirdly, they're asking for a
  67. "true virus" whilst judging its "success" by its Trojan effects.
  68.  
  69. I thought people had stopped this sort of incitement.
  70.  
  71. Paul 
  72.  
  73.     /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
  74.     \  Paul Ducklin                         duck@nuustak.csir.co.za  /
  75.     /  CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa  \
  76.     \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  77.  
  78. ------------------------------
  79.  
  80. Date:    Thu, 03 Jun 93 11:46:28 -0400
  81. >From:    hubt@css.itd.umich.edu (-- Hubert Chen --)
  82. Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$
  83.  
  84. miser@stein2.u.washington.edu (Robert Fulwell) writes:
  85. >
  86. >    DIGITAL ENTERPRISES IS CHALLENGING COMPUTER HACKERS to
  87. >    defeat its anti-virus technology.
  88. >       The Gaithersburg, Md-based company says virus experts
  89. >    have tried unsuccessfully for more than 2 years to defeat
  90. >    its V-Card Anti-Virus System. It's inviting hackers to come
  91. >    to its headquarters through mid-July to try their hand at
  92. >    loading a true virus (Trojan horses and bombs don't count)
  93. >    onto the system. The computer must be rendered non-bootable
  94. >    and files must be non-recoverable while V-Card is operating.
  95. >       The company will reward the triumphant hacker with $5000.
  96.  
  97. They didn't specify what kind of machine this was did they? I assume it
  98. must be a DOS machine, but maybe not..
  99.  
  100. ObHack: Attempting to port netatalk to the NeXT.
  101. - -- 
  102. \\\\ hubt@umich.edu -- Hubert Chen -- pgp key on request or via finger ////
  103. Deep Thoughts by Jack Handey:
  104. If you saw two guys named Hambone and Flippy, which one would you
  105. think liked dolphins the most? I'd say Flippy, wouldn't you? You'd be
  106.  
  107. ------------------------------
  108.  
  109. Date:    Thu, 03 Jun 93 11:59:26 -0400
  110. >From:    vwelch@ncsa.uiuc.edu (Von Welch)
  111. Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$
  112.  
  113. miser@stein2.u.washington.edu (Robert Fulwell) writes:
  114. |> Here's an interesting offer a few people out there probably wouldn't mind
  115. |> cashing in:
  116. |> 
  117. |> <Taken straight from Prodigy (DON'T ask me what I was doing there :-)>
  118. |> 
  119. |> PRODIGY(R) interactive personal service         06/03/93         1:29 AM
  120. |> 
  121. |>     DIGITAL ENTERPRISES IS CHALLENGING COMPUTER HACKERS to
  122. |>     defeat its anti-virus technology.
  123. |>        The Gaithersburg, Md-based company says virus experts
  124. |>     have tried unsuccessfully for more than 2 years to defeat
  125. |>     its V-Card Anti-Virus System. It's inviting hackers to come
  126. |>     to its headquarters through mid-July to try their hand at
  127. |>     loading a true virus (Trojan horses and bombs don't count)
  128. |>     onto the system. The computer must be rendered non-bootable
  129. |>     and files must be non-recoverable while V-Card is operating.
  130. |>        The company will reward the triumphant hacker with $5000.
  131.  
  132.  The question that pops into my mind, is if their product is that good at
  133. impeding viruses, how many legitimate applications will it prohibit?
  134.  
  135. Von
  136.  
  137. - -- 
  138. Von Welch (vwelch@ncsa.uiuc.edu)    NCSA Networking Development Group
  139.  
  140.  "It is better to not post and appear stupid than to post and prove it."
  141.      - I speak only for myself and those who think exactly like me -
  142.  
  143. ------------------------------
  144.  
  145. Date:    Thu, 03 Jun 93 18:52:08 +0000
  146. >From:    bontchev@news.informatik.uni-hamburg.de (Vesselin Bontchev)
  147. Subject: Re: Digital Enterprises $5,000 challenge! $$$ $$$
  148.  
  149. Robert Fulwell (miser@stein2.u.washington.edu) writes:
  150.  
  151. > Here's an interesting offer a few people out there probably wouldn't mind
  152. > cashing in:
  153.  
  154. Yeah, yet another marketting trick... The challenge seems rather bogus
  155. to me; see below.
  156.  
  157. >        The Gaithersburg, Md-based company says virus experts
  158. >     have tried unsuccessfully for more than 2 years to defeat
  159. >     its V-Card Anti-Virus System.
  160.  
  161. Huh? Any virus experts out there who have spent the last 2 years of
  162. their life trying (unsuccessfully, of course) to break that famous
  163. V-Card? At least I have not even heard about it. My guess is that it
  164. is either breakable (at least in some streched conditions) or makes
  165. the computer it is installed on unusable.
  166.  
  167. > It's inviting hackers to come
  168. >     to its headquarters through mid-July to try their hand at
  169. >     loading a true virus (Trojan horses and bombs don't count)
  170. >     onto the system. The computer must be rendered non-bootable
  171. >     and files must be non-recoverable while V-Card is operating.
  172.  
  173. Funny, the card seems to protect from the damages; it doesn't seem to
  174. try to prevent the viruses from spreading - only from damaging files.
  175. Then, why are Trojan horses excluded? If it is possible to write a
  176. Trojan horse that would be able to bypass the protection provided by
  177. the card, it should be more than trivial to attach it to a simple
  178. virus, e.g. a Burger or a Vienna variant.
  179.  
  180. >        The company will reward the triumphant hacker with $5000.
  181.  
  182. I am not able to go there and try it, but here are some hints to those
  183. who decide to take the challenge:
  184.  
  185. 1) The conditions say that "files must be non-recoverable". They don't
  186. specify that the files must be those on the hard disk. In the same
  187. time, many hardware anti-virus cards don't offer any protection of the
  188. information on the floppies. Hint - use a virus that spreads only on
  189. floppies and causes damage only on the files that reside there.
  190.  
  191. 2) In order to make the computer non-bootable, one must damage one of
  192. the following: the CMOS, the MBR, the DBS, any of the two hidded DOS
  193. files, the command interpretter, any of the device drivers or
  194. INSTALLed programs from CONFIG.SYS, and of the programs started by
  195. AUTOEXEC.BAT. Chances are that the card protects the MBR and the DBS.
  196. If it is clever enough, it should also protect any executable file,
  197. but this is less likely. Even less likely is that it protects the
  198. CONFIG.SYS and AUTOEXEC.BAT files themselves - these files are often
  199. modified. The less likely thing to protect is the CMOS. Therefore, one
  200. could try to change the CMOS settings to indicate that there is no
  201. hard disk, or to change CONFIG.SYS or AUTOEXEC.BAT and make them
  202. execute a program that just loops infinitely and so on. It is possible
  203. that the card is made to protect all the above areas, but then it
  204. should make the computer pretty unusable...
  205.  
  206. 3) It is possible to change the logical contents of a file by just
  207. manipulating the FAT and/or the directory entries. However, a
  208. protection card cannot just deny access to those areas, because DOS
  209. itself is modifying them. Therefore, the card is either storing the
  210. "protected" files on some write-protected area (and keeps a list of
  211. the sectors write to which is forbidden), or attempts to determine
  212. whether the request to modify the FAT and/or the directory entry comes
  213. from DOS or not. Unfortunately, there is NO WAY this can be determined
  214. safely enough. A virus could patch part of the DOS kernel and call it;
  215. it could use device driver requests (like the Dir_II virus), and so
  216. on.
  217.  
  218. 4) There is a remote possibility that the card requires some kind of
  219. TSR program to be present - for instance to display messages, to
  220. request the Yes/No response from the user, and so on. In some cases,
  221. it is possible patch this program and make it always tell the card
  222. "everything's fine, just go on".
  223.  
  224. Unfortunately, selecting the right kind of attack depends on how
  225. exactly the card operates. Even a secure strategy might be compromised
  226. by a sloppy implementation. It is very possible that -none- of the
  227. currently existing viruses will be able to bypass the card. In the
  228. same time, however, it might be quite trivial to bypass it by using
  229. just a combination of the known techniques.
  230.  
  231. However, since the rules do not allow the usage of Trojan horses, the
  232. only way to demonstrate that it is possible to defeat the card will be
  233. to write a new virus. Therefore, the challenge is an incitement to
  234. create new viruses - something that I find particularly disgusting.
  235.  
  236. Regards,
  237. Vesselin
  238. - --
  239. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  240. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  241. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  242. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  243.  
  244. ------------------------------
  245.  
  246. Date:    Thu, 03 Jun 93 14:59:21 -0400
  247. >From:    jjsterre@acs.ucalgary.ca
  248. Subject: Use of cryptanalysis in virus-hunting.
  249.  
  250.     While reading this list, I was struck by the comment that Tremor
  251. had several million (or billion) permutations in its encryption scheme.
  252.  
  253.     I do not know too much about programming; but I know a bit about
  254. cryptanalysis by virtue of working at times in Signals history.  In 
  255. general, simple permutations (such as a polyalphabetic cipher with a
  256. random or self-modifying key - like the Enigma or Purple machines) are
  257. not difficult obstacles for computers.  Because all plaintext (in this
  258. case the virus code) has underlying patterns, the ciphertext has patterns,
  259. through which the original can be found.
  260.  
  261.     I wondered if cryptanalytic techniques were/would be useful in
  262. hunting the encrypted viruses.  I'm told that most viruses use a time-based
  263. key (therefore predicatble once you have any piece?) which is added in
  264. various ways to the virus code.  This sounds to me like the situation
  265. I described in the above paragraph.
  266.  
  267.     Thanks for your time.
  268.  
  269.         James Sterrett
  270.         jjsterre@acs.ucalgary.edu
  271.  
  272. ------------------------------
  273.  
  274. Date:    Fri, 04 Jun 93 05:26:18 -0400
  275. >From:    wouter@stack.urc.tue.nl (Wouter Slegers)
  276. Subject: Virus as extortion
  277.  
  278. This may not be common for this group, but as this is about virusses...
  279. A friend of mine who programs a up/download-protocol got a threath (sp?)
  280. from Russia: Either he sold the program to them for $5 (normally $15) or
  281. they would release a virus with his name in it (maybe even with the
  282. protocol, I don't know for sure). He didn't comply and changed the
  283. coding/protection of his program radically to make it more difficult to
  284. hack/infect it. 
  285. How do you feel about this? Can you give us advise as to how to handle this?
  286. Do you have tips to prevent deliberate infections and hacks? (Although this
  287. program is already quite protected with encryption e.g. ideas are always
  288. welcome).
  289.  
  290. Regards,
  291. Wouter
  292.  
  293. BTW: this is all on the PC-platform.
  294.  
  295. - --
  296. Wouter Slegers, 1st year CS at TUE (nl), wouter@stack.urc.tue.nl.
  297. Disclaimer: If the above sounds plausible, reread it several times!
  298. Religion and sex are powerplays*manipulate the people for the money they pay
  299. Selling skin, selling god* the numbers are the same on their creditcards!
  300.  
  301. ------------------------------
  302.  
  303. Date:    Thu, 03 Jun 93 11:27:25 -0400
  304. >From:    "Paul R. Coen" <PCOEN@DRUNIVAC.DREW.EDU>
  305. Subject: Re: The Anti-Viral Software of MS-DOS 6.0 (PC)
  306.  
  307. >  What is clear is that in this case F-PROT is complaining about what
  308. >*MSAV* has left in memory, not about VSAFE.  It is also clear that
  309. >F-PROT is giving a false positive.  The only question is: Which scan-
  310. >ner is at fault: MSAV or F-PROT?  If instead of running F-PROT (after
  311. >MSAV) I run SCAN, FINDVIRU, or UTSCAN, no message is output.  Since
  312. >the other three scanners disagree with F-PROT, the most likely answer
  313. >is that it is F-PROT which is at fault in this case.
  314.  
  315. That's a really unique way of looking at it.  What is probably happening
  316. is that F-PROT and MSAV happen to use the same string, or F-PROT uses
  317. a sub-string of what MSAV is using.  MSAV is leaving unencrypted strings
  318. in memory (like CPAV and Carmel Turbo A-V before it), and f-prot is
  319. going off.  I've seen versions of other scanners give false positives with CPAV
  320. or Turbo A-V.  What it comes down to is that because they leave strings in
  321. memory, the whole MSAV/CPAV/TAV line is ruining perfectly good search strings;
  322. at best, this is inconsiderate, at worst, it demonstrates a "screw you" 
  323. attitude which is unwelcome.
  324.  
  325. So basically, you're blaming F-Prot for not getting out of the way of
  326. a crummy, problem-causing product.  Sorry, but that's blaming the victim.
  327. F-Prot will probably get fixed, simply because people are going to make
  328. the same conclusion as you, only based on even less -- they'll just say
  329. "Gee, Microsoft is distributing this, so it can't stink.  Must be this
  330. other program's fault."  
  331.  
  332. - --
  333. Paul Coen, Drew University Academic Computing
  334.     pcoen@drunivac.drew.edu        pcoen@drunivac.bitnet
  335.  
  336. ------------------------------
  337.  
  338. Date:    Thu, 03 Jun 93 11:59:59 -0400
  339. >From:    Fabio Esquivel <FESQUIVE@ucrvm2.bitnet>
  340. Subject: Re: Viruses that cost $$$ (PC)
  341.  
  342. It's been several days ago since I sent my BURNER.COM program to
  343. Vesselin Bontchev, and still haven't heard any answer (positive or
  344. negative) about the results.
  345.  
  346. Vesselin:  Did Burner work?  Still testing?  No interest?
  347.  
  348. I just have curiousity in knowing if you are convinced that it is
  349. perfectly possible to destroy hardware by software...
  350.  
  351. ********* FOR Baudilio Gomez Qenk (Supervisor of Holguin.CU) ***********
  352. Baudilio, I've got your messages and I've sent six e-mails answering you,
  353. but all of them get back to my account with a subject of "undeliverable".
  354. I'll keep trying anyway.
  355.  
  356. ;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  357. Data SEGMENT PARA PUBLIC
  358.       name DB 'Fabio Esquivel Chacon'    ; That's me... 8^)
  359.        job DB 'Computer Science student' ; But I'll graduate soon
  360.       site DB 'University of Costa Rica' ;
  361.     bitnet DB 'fesquive@ucrvm2.bitnet'   ; Office hours, please.
  362.   internet DB 'fesquive@ucrvm2.ucr.cr'   ;
  363. Data ENDS
  364.  
  365. ------------------------------
  366.  
  367. Date:    Thu, 03 Jun 93 13:15:29 -0400
  368. >From:    Y. Radai <RADAI@vms.huji.ac.il>
  369. Subject: Re: CPAV updates? (PC)
  370.  
  371.   Alan Boon writes concerning CPAV:
  372. > With Bootsafe and Vsafe running, your system is well protected provided you
  373. > update the signature files. It offers a comprehensive protection system
  374. > that no other can match. Anyway, it wasn't the user interface that
  375. > attracted me but the protection level it offered.
  376.  
  377. The protection level attracted you??  I notice that you wrote this on
  378. 27 May.  There's an evaluation of MSAV/VSafe which appeared in
  379. VIRUS-L/comp.virus two days earlier (modesty prevents me from saying
  380. who the author is).  Almost everything written there holds for CPAV as
  381. well.  (Okay, since BootSafe comes with CPAV but not with MSAV, it has
  382. only 9.5 security holes instead of 10.)  Please read that evaluation
  383. and then let us know if you're still inclined to praise CPAV's level
  384. of protection.
  385.  
  386.                                      Y. Radai
  387.                                      Hebrew Univ. of Jerusalem, Israel
  388.                                      RADAI@HUJIVMS.BITNET
  389.                                      RADAI@VMS.HUJI.AC.IL
  390.  
  391. ------------------------------
  392.  
  393. Date:    Thu, 03 Jun 93 13:43:15 -0400
  394. >From:    Y. Radai <RADAI@vms.huji.ac.il>
  395. Subject: Re: Is "Untouchable" (V-ANALYST) Effective? (PC)
  396.  
  397.   Gabriel Schwartz writes:
  398. > Yes you might be right about the integrity checker of V-Analyst but most of
  399. > the users want to see scan results much more then integrity check.
  400.  
  401. Yes, that may be what they *want* to see ... but that doesn't make it
  402. the best way of evaluating a product.
  403.  
  404. > Altough integrity check is a very important path of an anti-virus package it
  405. > can't stand alone as the leading part.I'm lookin in the latest VSUM reports
  406. > and V-Analyst doesn't look very good there,
  407.  
  408. I agree that UTScan (that's obviously what you mean when you say
  409. "V-Analyst") is not the best scanner, although it has improved
  410. greatly in the past year or so.  However, when you mention the VSUM
  411. reports ("certifications"), you should realize that they're biased in
  412. two ways: (1) The VSUM test suite seems to be (by sheer coincidence,
  413. of course) very similar to McAfee's collection.  (2) VSUM uses the
  414. latest versions of some scanners but rather old versions of others.
  415. In particular, the April comparison used Ver. 25 of UTScan, even
  416. though Ver. 28 was already out!  It may not be easy to avoid bias (1),
  417. but there's not much excuse for comparisons which are unfair in the
  418. sense of (2).  The best we can do is to look at as many comparisons
  419. as possible which are based on the *latest* versions of *every*
  420. product.
  421.  
  422.                                      Y. Radai
  423.                                      Hebrew Univ. of Jerusalem, Israel
  424.                                      RADAI@HUJIVMS.BITNET
  425.                                      RADAI@VMS.HUJI.AC.IL
  426.  
  427. ------------------------------
  428.  
  429. Date:    Thu, 03 Jun 93 14:55:43 -0400
  430. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  431. Subject: Handle Redirection (MSDOS) (PC)
  432.  
  433. Subject: Redirection Difficulty (PC)
  434. >From:    Donald G Peters <Peters@DOCKMASTER.NCSC.MIL>
  435.  
  436. >I'm trying to investigate how programs trap I/O and redirect it. The
  437. >specific problem that I have is how does a program tell DOS to change
  438. >its interpretation of standard input or output (or the other three
  439. >standard handles for that matter). None of my books an DOS function
  440. >(documented or undocumented) describe how to do this.
  441.  
  442. Not sure just how virus related this is but since Ken posted the question,
  443. here goes:
  444.  
  445. For this I am gong to confine the discussion to screen display though
  446. most of the points have analogues for the keyboard as well.
  447.  
  448. There are three different means of writing to the screen though all wind up
  449. at the same place. The first entry point is at the DOS level such as
  450. via Int 21h Fn 9h (Output string). MSDOS massages this reguest and converts
  451. the request to be compatable with Int 10h, BIOS screen control (second
  452. entry point). Int 10h then massages the request into a direct write to the 
  453. screen buffer (third entry point).
  454.  
  455. Standard Input (handle 0), standard output (handle 1), and standard error
  456. (handle 2) only have meaning from the DOS level (Int 21h) and will not
  457. intercept either Int 10h access or direct buffer writes.
  458.  
  459. To intercept a handle, the normal method (though tricky) is to close
  460. the original handle and reopen it with direction to a different device.
  461. This has the problem of eliminating the screen display completely. Since
  462. screen display from DOS is lost, the only fallback on error is to reboot.
  463.  
  464. A second method would be to intercept the Int 10h calls, write the 
  465. character to a file and then pass the original call on to the BIOS. This
  466. would generate both a screen display and a hard copy (essentially what
  467. control_P does).
  468.  
  469. The third method is untrappable since there is nothing to trap, data is
  470. written directly to the screen buffers. The only thing that could be done 
  471. would be to periodically trap an image of the buffer data to a file.
  472.  
  473. As can be seen, the problem with handles is that redirection here has no
  474. effect on programs using low level functions. For this reason, handle
  475. redirection can be done, I doubt that it will do what you want.
  476.  
  477.                         Warmly,
  478.                             Padgett
  479.  
  480. ------------------------------
  481.  
  482. Date:    Thu, 03 Jun 93 19:23:05 +0000
  483. >From:    bontchev@news.informatik.uni-hamburg.de (Vesselin Bontchev)
  484. Subject: Re: CPAV updates? (PC)
  485.  
  486. A.M. Zanker (A.M.Zanker@newcastle.ac.uk) writes:
  487.  
  488. > Ha Ha! Yes, it has a nice user interface. It also detects the 50 or so
  489. > virii that are ever really seen outside virus testing labs etc. (according
  490. > to Alan Solomon).
  491.  
  492. I misses e.g., Tremor that recently was recently distributed to
  493. potentially 60,000 users all over Europe. Does it matter that it
  494. detects all those "50 or so" viruses, if it misses that single one
  495. that will attack your computer? Does it matter whether it detects even
  496. all viruses known to be "in the wild", if tomorrow a disgruntled
  497. employee of your company or just a malicious person can download an
  498. "extinct" virus from his favourite virus exchange BBS and use it to
  499. attack your system?
  500.  
  501. > It always seems to have a fairly low rating in P. Hoffman's
  502.  
  503. I usually tend to disagree with Mrs. Hoffman's results, but this time
  504. they agree surprisingly well with my own. MSAV that comes with MS-DOS
  505. 6.0 has a hit rate of approximately 62% when run my our virus
  506. collection. According to Mrs. Hoffman, it is 53% when run on -her-
  507. virus collection. The two numbers are pretty close to each other
  508. (regardless of the fact that they have been obtained on different
  509. virus collections) and both of them mean that the scanner is -bad-.
  510.  
  511. > certification tests, but then she seems to use the standard 1.4 version withou
  512. > any of the updates. 
  513.  
  514. Good point, you are right on this one. OK, I got the latest updates of
  515. CPAV 1.4, MSAV, and even CPAV 2.0-beta from Central Point Software.
  516. I'll test each one of them and will report the results later.
  517.  
  518. > Both DOS and Windows versions can also detect changes to "system" files 
  519. > (.exe, .com, .dll, .ov?, etc.) which seems to cover just about everything
  520. > one is likely to meet in everyday home use.
  521.  
  522. Funny, I don't know about any virus that can infect .DLL files...
  523. Strange, I don't see the .SYS, .BIN, .DRV, and .BAT files listed,
  524. although I do know several viruses that can infect such files.
  525.  
  526. But this is irrelevant. What is important is that your claim that the
  527. program is able to detect changes to any of those files is just plain
  528. wrong and misleading. The integrity checking system checks only the
  529. size/date/time/attributes and the first 64 bytes of those files. It is
  530. trivial to write a virus that does not change -any- of the above.
  531. Furthermore, it is possible to attack the integrity checker in about a
  532. dozen of other ways (described in my paper) and in most cases the
  533. attack will succeed.
  534.  
  535. Regards,
  536. Vesselin
  537. - --
  538. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  539. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  540. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  541. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  542.  
  543. ------------------------------
  544.  
  545. Date:    Thu, 03 Jun 93 19:06:48 +0000
  546. >From:    bontchev@news.informatik.uni-hamburg.de (Vesselin Bontchev)
  547. Subject: Re: CPAV updates? (PC)
  548.  
  549. Alan Boon (ee1ckb@sunlab1.bath.ac.uk) writes:
  550.  
  551. > With Bootsafe and Vsafe running, your system is well protected provided you
  552. > update the signature files.
  553.  
  554. Is it? Could you enlighten us -why- the system is well protected?
  555. Bootsafe is nothing more than a generic boot sector recovering program
  556. that can be easily defeated by a virus which is stealth enough (e.g.,
  557. Strange). VSafe is a combination of a resident scanner/integrity
  558. checker and a monitor. As it has been mentioned here several times, it
  559. is possible to disable or even to remove it completely from memory
  560. with just 3 instructions! Besides, the monitoring part of it is
  561. trivially bypassed by the modern tunnelling technology and the whole
  562. concept of the integrity system is implemented in such a sloppy way
  563. that it can be easily bypassed too. Add to that the fact that the
  564. off-line scanner is nothing exceptional. So, where is the "good
  565. protection" claimed by you? Maybe there is a special way to use the
  566. program that I don't know about - a way to really turn the protection
  567. on. If this is the case, please share this way with us.
  568.  
  569. > It offers a comprehensive protection system
  570. > that no other can match.
  571.  
  572. Could you please provide some evidence to support the above claim?
  573. Meanwhile, I'll provide some evidence to the countrary:
  574.  
  575. 1) Do you mean by "comprehensive" that the package combines scanning
  576. with monitoring and integrity checking? Then the claim that "no one
  577. can match" it is false - there are several other packages which
  578. provide the same combination.
  579.  
  580. 2) The scanner has a detection rate of approximately 60%, compared to
  581. 99% of Dr. Solomon's Anti-Virus ToolKit. Indeed, no one can match that
  582. - - in bad quality, that is.
  583.  
  584. 3) The scanner is significantly slower than most of the existing ones.
  585.  
  586. 4) The resident part can be disabled/removed/bypassed in a trivial
  587. way.
  588.  
  589. 5) The integrity checking part is extremely insecure and can be
  590. attacked successfully with almost any of the attacks described in my
  591. paper. Compared with e.g. Untouchable, the protection offered by the
  592. integrity checking capabilities of CPAV is just laughable.
  593.  
  594. 6) On the top of that, the checksums are kept in separate files in
  595. each directory that contains executable files. This tends to waste
  596. your disk space.
  597.  
  598. > Anyway, it wasn't the user interface that
  599. > attracted me but the protection level it offered.
  600.  
  601. What level of protection? How did you test/evaluate it? Could you
  602. please describe your test procedures?
  603.  
  604. Regards,
  605. Vesselin
  606. - --
  607. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  608. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  609. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  610. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  611.  
  612. ------------------------------
  613.  
  614. Date:    Thu, 03 Jun 93 19:31:56 +0000
  615. >From:    bontchev@news.informatik.uni-hamburg.de (Vesselin Bontchev)
  616. Subject: Re: Is "Untouchable" (V-ANALYST) Effective (PC)
  617.  
  618. Schwartz Gabriel (Schwartz_Gabriel@f101.n9721.z9.virnet.bad.se) writes:
  619.  
  620. > Yes you might be right about the integrity checker of V-Analyst but most of 
  621. > the users want to see scan results much more then integrity check.
  622.  
  623. This just means that those users must be educated about how to built
  624. an effective virus protection defense. The fact that they "want to
  625. see" something does not mean that this "something" will actually
  626. protect them. Unfortunately, it may well make them buy the product and
  627. get a false sense of security.
  628.  
  629. > Altough integrity check is a very important path of an anti-virus package it 
  630. > can't stand alone as the leading part.
  631.  
  632. Why not? Please, explain. IMNSHO, exactly the integrity checking must
  633. play the leading role. The only role of the scanner should be to make
  634. sure that the package is installed on a virus-free system and as a
  635. front-end line to prevent the well-known viruses from entering the
  636. system. (The integrity check will detect them as soon as they enter,
  637. but it is still better if they can be stopped even before that - if it
  638. can be achieved cheaply enough, of course.)
  639.  
  640. > I'm lookin in the latest VSUM reports 
  641. > and V-Analyst doesn't look very good there,  
  642.  
  643. This means just that:
  644.  
  645. 1) You are looking in the wrong place (VSUM).
  646.  
  647. 2) You have not noticed that Mrs. Hoffman has tested only the scanner 
  648. part of the product.
  649.  
  650. 3) Mrs. Hoffman has not tested the product properly.
  651.  
  652. 4) You do not realize that the quality of the scanner does not say
  653. anything about the quality of the virus protection provided by the
  654. product as a whole.
  655.  
  656. 5) The results apply only to an old version of the scanner.
  657.  
  658. Regards,
  659. Vesselin
  660. - --
  661. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  662. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  663. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  664. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  665.  
  666. ------------------------------
  667.  
  668. Date:    Thu, 03 Jun 93 20:11:23 +0000
  669. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  670. Subject: Re: Redirection Difficulty (PC)
  671.  
  672. Donald G Peters (Peters@DOCKMASTER.NCSC.MIL) writes:
  673.  
  674. > I'm trying to investigate how programs trap I/O and redirect it. The
  675. > specific problem that I have is how does a program tell DOS to change
  676. > its interpretation of standard input or output (or the other three
  677. > standard handles for that matter). None of my books an DOS function
  678. > (documented or undocumented) describe how to do this.
  679.  
  680. Easy. Open a file you want to redirect stdin to (INT 21h/AH=3Dh, AL -
  681. opening mode, DS:DX - pointer to the ASCIIZ name of the file). The
  682. handle of the new file is returned in AX. Then ForceDuplication of the
  683. file handle (INT 21h/AH=46h, BX - the handle that you got from the
  684. previous function, CX - the handle you want to duplicate - 0 for
  685. stdin, 1 for stdout, 2 for stderr, etc.). From this point on, any
  686. output to stdin by this or by any child process will be redirected to
  687. the newly opened file. The redirection of the other standard I/O files
  688. (stdout, stderr, stdprn, stdaux) is done in the same way. BTW, I don't
  689. see what all this has to do with computer viruses - maybe it's more
  690. appropriate for the comp.os.msdos.programmer newsgroup...
  691.  
  692. > Now please don't suggest EXEC('COMMAND.COM','/C pgm parameters >file') 
  693. > because no malicious software could get away with that. I don't need
  694. > to defend against such a weak attack; I want to defend against smart
  695. > attacks. How do they do it? (It is done by 4DOS at least.) All I want
  696. > to know is what do you do to have I/O redirected at the system call
  697. > level.
  698.  
  699. Attack? What attack? You certainly don't believe that it is "safe" to
  700. run viruses as child processes if you redirect the standard I/O?
  701.  
  702. Regards,
  703. Vesselin
  704. - --
  705. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  706. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  707. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  708. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  709.  
  710. ------------------------------
  711.  
  712. Date:    Thu, 03 Jun 93 20:44:39 +0000
  713. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  714. Subject: Re: On the merits of VSUM (PC)
  715.  
  716. Al Garcia (CMGARCIAAL@CRF.CUIS.EDU) writes:
  717.  
  718. > You recently gave some very constructive criticism of Patricia Hoffman's VSUM.
  719. > In contrast, McAfee's VIRLIST.TXT provides succinct descriptions of the genera
  720. > behavior you can expect from any particular virus on it.  One of these types o
  721.  
  722. Why "in contrast"? VIRLIST.TXT is full of errors too; it is just not
  723. so verbose as VSUM. The last time I checked (in version 102), it
  724. contained names of viruses never reported by the scanners, didn't
  725. contain the names of many viruses reported by the scanner, had
  726. spelling mistakes in the virus names, had errors in the virus
  727. properties and sometimes even in the infective lenght, and the "number
  728. of variants" field was completely unreliable.
  729.  
  730. > matter (again, it's succinct).  As you know, there are many different ways a
  731. > virus can install itelf in memory, which is reflected in VSUM.  Here's her 
  732.  
  733. [description deleted]
  734.  
  735. > Could you please provide some comments on the accuracy of VSUM in this one 
  736. > specific area of analysis? 
  737.  
  738. The description is not complete and detailled enough. A pretty
  739. complete list of the currently used method can be found in the
  740. description of the CARObase entry format, available from our ftp site.
  741. It has two drawbacks - first, it is also not perfect (we had some
  742. trouble to describe how the Strange virus installs itself in memory),
  743. and second, it is just a list, not a description (in order not to help
  744. the virus writers), so you'll have to figure yourself what each of the
  745. methods consists of.
  746.  
  747. Regarding how exact VSUM's analysis of the memory residency methods
  748. used by the viruses is - I don't know; haven't checked that in
  749. particular.
  750.  
  751. > by programs such as TBDRIVER/FILE, FLUSHOT, SECURE, etc.  For example, the
  752. > first two each have a problem detecting suspicious memory allocation and use,
  753.  
  754. It's not a problem to detect memory allocation - Padgett has a
  755. "six-bytes" method that can do this. Problem is, many viruses install
  756. themselves in memory without allocating memory... :-(
  757.  
  758. > past them.  SECURE, on the other hand, doesn't seem to bother alerting the
  759. > user when a program makes a TSR request (maybe it's supposed to, but it didn't
  760.  
  761. Which SECURE? Mark Washburn's? It has a permission bit in the program
  762. descriptions that tells whether they are allowed to remain resident.
  763. If you turn this bit off, you should get a warning.
  764.  
  765. > I don't have the viruses to verify any of this.  I only ran a few tests on th
  766. e
  767. > security programs to see if they'd be triggered under the conditions I would 
  768. > want them to be, above scenarios included.  Thanks.
  769.  
  770. Hm, that's a tricky one... For instance, VSafe (the resident anti-virus
  771. program that comes with MS-DOS 6.0) claims to be able to detect
  772. whether a program tries to remain resident. In reality, it even does
  773. not try to do so - instead it tries to determine whether after a
  774. program terminates some interrupts seem to have been hooked (no, not
  775. only in the interrupt vector table). This allows it to detect many of
  776. the attempts of the viruses to install themselves in memory.
  777.  
  778. Regards,
  779. Vesselin
  780. - --
  781. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  782. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  783. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  784. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  785.  
  786. ------------------------------
  787.  
  788. Date:    Thu, 03 Jun 93 20:53:52 +0000
  789. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  790. Subject: Re: Corrections (CPAV) (PC)
  791.  
  792. A. Padgett Peterson (padgett@tccslr.dnet.mmc.com) writes:
  793.  
  794. > >>According to Padgett, the updates can be used to upgrade also the
  795. > >>MS-DOS version of MSAV - the scanner that comes with MS-DOS 6.0.
  796.  
  797. > Not quite, the signature update for the DOS portion appears identical
  798. > (according to FC). The .DLLs (Windows portion) are the same exact size but 
  799. > are different - probably just logos/messages but haven't checked further.
  800.  
  801. Well, didn't I say the same - they can be used for the MS-DOS version
  802. of the product. Oh, I see, I didn't emphasize that they cannot be used
  803. to update the MS-Windows version of it. But this was because I had no
  804. information about that - the fact the the files are different, does
  805. not mean (although it might) that they cannot be used to update it.
  806.  
  807. > >Nope. The disabler -is- needed - as Yisrael pointed out, MSAV needs to
  808. > >turn VSAFE off before it begins to scan the disk. If you don't allow
  809.  
  810. > Exactly so though do not know why this should be necessary, all MSAV should
  811. > be doing is reading the disk (or will VSAFE decide that MSAV is a virus 8*).
  812.  
  813. You are right, of course, it is not necessary at all. But MSAV does
  814. need it. My guess is that because VSAFE also can scan files when they
  815. are opened, MSAV disables it, in order to make sure that no duplicate
  816. reports will occur (one from VSAFE and one from MSAV) when an infected
  817. file is scanned.
  818.  
  819. > Why ? Though I am equally incompetant legally it would seem that CP might 
  820. > copyright their signatures (and this is questionable, they would have to 
  821. > prove originality of the strings), what you have is a program that accepts
  822. > input. There are no legal restrictions to that input any more than Microsoft
  823. > can limit sales of Wallpaper .BMPs or Lotus can limit 1-2-3 templates. What 
  824. > we are dealing with is a *format* not a program and insofar as I have been 
  825. > able to ascertain the courts have taken a consistantly dim view on attempts 
  826. > to restrict these. 
  827.  
  828. As I said, I just don't know. I've heard that some companies are suing
  829. others just because of the "look alike" of the user interface of their
  830. software, so I thought that "using the same data format" could also
  831. provide a hook for the lawyers...
  832.  
  833. > SBO doesn't work for long.
  834.  
  835. Unfortunately, it often works in the negative way. That is, preventing
  836. the good guys from doing some useful work, while in the same time
  837. failing to prevent the bad guys to do something nasty...
  838.  
  839. Regards,
  840. Vesselin
  841. - --
  842. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  843. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  844. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  845. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  846.  
  847. ------------------------------
  848.  
  849. Date:    Thu, 03 Jun 93 17:01:13 -0400
  850. >From:    frisk@complex.is (Fridrik Skulason)
  851. Subject: Re: Misidentification by F-Prot 2.08a (PC)
  852.  
  853. The subject line is a bit misleading, as F-PROT did NOT mis-identify
  854. anything, as explained below.
  855.  
  856. >the machine would lock up, following booting.  F-Prot 2.08a identified the 
  857. >virus as a _Screaming Fist_ variant while McAfee's Scan program said that
  858. >it was a combination of a boot sector virus, [Genp], with the _Stickey_
  859. >[ML2] virus infecting the .com and .exe files.
  860.  
  861. The "combination" part is wrong - it is SCAN that is misidentifying the virus,
  862. seeing two viruses where you in fact have only one - probably the one which
  863. is called Screaming_Fist.Nu-Way.
  864.  
  865. There are several different viruses in the Screaming Fist family:
  866.  
  867.  CARO name                    F-PROT name                   SCAN 104 name
  868. Screaming_Fist.I            Screaming Fist (I)               Scream
  869. Screaming_Fist.II.838       Screaming Fist (II-A)            Scr-2
  870. Screaming_Fist.II.696       Screaming Fist (II-B)            Scream2
  871. Screaming_Fist.II.692       Screaming Fist (II-C)            Scream2
  872. Screaming_Fist.II.732       Screaming Fist (II-D)            Scream2
  873. Screaming_Fist.Nu-Way       New or modified variant of...    Sticky
  874. Screaming_Fist.Stranger     Screaming Fist (Stranger)        Scream2
  875.  
  876. >One other characteristic of the virus was that it wasn't terribly bright, 
  877. >in that one of the .com files that it infected was a DCL .COM file downloaded
  878. >from my VAX. (for the vaxophobic, it's an ascii text file, similar to a .bat).
  879.  
  880. >I was able to disinfect the [Genp] with complete success using Clean, and 
  881. >[ML2] with partial success.  Files that were for protected mode applications 
  882. >tended to be unrecoverable.  F-prot was unable to do either.
  883.  
  884. Well, unfortunately you happened to get infected with the only variant of
  885. Screaming Fist that F-PROT does not identify accurately, and therefore does
  886. not attempt to disinfect.  I will update the next version so it does handle
  887. this particular variant.  
  888.  
  889. - -frisk
  890. - -- 
  891. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  892. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  893.  
  894. ------------------------------
  895.  
  896. Date:    Thu, 03 Jun 93 21:00:24 +0000
  897. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  898. Subject: Re: The Anti-Viral Software of MS-DOS 6 (PC)
  899.  
  900. Y. Radai (RADAI@vms.huji.ac.il) writes:
  901.  
  902. > The experimental facts which I have found are this:  Without VSafe
  903. > loaded in memory either currently or since booting, I run first MSAV,
  904. > then F-PROT.  F-PROT outputs the message "The Telecom virus search
  905. > pattern has been found in memory."  Now how can VSAFE be the problem
  906. > when *it isn't even loaded in memory*???
  907.  
  908. Then the problem is also in MSAV, which doesn't bother to clean up
  909. after itself. And partly in F-Prot for not using a more intelligent
  910. approach to check the memory.
  911.  
  912. > It is also clear that
  913. > F-PROT is giving a false positive. 
  914.  
  915. A ghost positive, more exactly.
  916.  
  917. > The only question is: Which scan-
  918. > ner is at fault: MSAV or F-PROT? 
  919.  
  920. I would suggest - both. Unless if by chance MSAV does not leave the
  921. signature of the virus at a place where the real virus could have put
  922. it - in which case F-Prot does not have any guilt whatsoever. But I
  923. find this extrememly unlikely.
  924.  
  925. > If instead of running F-PROT (after
  926. > MSAV) I run SCAN, FINDVIRU, or UTSCAN, no message is output.  Since
  927.  
  928. Oh, this could mean anything. For instance, the above programs might
  929. be using a different scan string than MSAV.
  930.  
  931. > the other three scanners disagree with F-PROT, the most likely answer
  932. > is that it is F-PROT which is at fault in this case.
  933.  
  934. Nope.
  935.  
  936. >   Admittedly, the situation changes when VSAFE is loaded in extended
  937. > memory (in this case F-PROT complains that the Stoned pattern has been
  938. > found).  This time it may sound as if VSAFE is guilty.  But here
  939. > again, the other three scanners say nothing.  So I tend to think that
  940.  
  941. Again, the reason is that they are probably using a different scan
  942. string.
  943.  
  944. Regards,
  945. Vesselin
  946. - --
  947. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  948. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  949. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  950. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  951.  
  952. ------------------------------
  953.  
  954. Date:    Thu, 03 Jun 93 20:27:23 +0000
  955. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  956. Subject: Re: Misidentification by F-Prot 2.08a (PC)
  957.  
  958. System Manager, and VAX Gopher (farnold@wotan.duch.udel.edu) writes:
  959.  
  960. > the machine would lock up, following booting.  F-Prot 2.08a identified the 
  961. > virus as a _Screaming Fist_ variant, while McAfee's Scan program said that
  962. > it was a combination of a boot sector virus, [Genp], with the _Stickey_
  963. > [ML2] virus infecting the .com and .exe files.
  964.  
  965. It's not a "misidentification in F-Prot". Here is what has happened.
  966.  
  967. Your computer is infected with one particular virus, the standard CARO
  968. name of which is Screaming_Fist.Nu-Way. F-Prot 2.08a does not know
  969. this virus, but correctly determines that it is a variant of the
  970. Screaming_Fist family. (Actually, doesn't it say "New variant of" or
  971. something similar?) McAfee's SCAN 104 calls this virus "Sticky [ML2]"
  972. (not "Stickey"). I have no idea why they are using this name and they
  973. don't group the viruses into families anyway. The important thing is
  974. that both programs mean one and the same virus.
  975.  
  976. However, the problem is that the virus is multi-partite. It infects
  977. both files and MBRs. Neither of the programs knows about that, but
  978. SCAN has a pretty general "heuristic" scan string for simple boot
  979. sector viruses. The presence of this string lets it detect the
  980. infection in the MBR. Since the virus does not encrypt the original
  981. MBR, the generic boot sector remover in Clean is able to remove the
  982. MBR infection.
  983.  
  984. > I was able to disinfect the [Genp] with complete success using Clean, and 
  985. > [ML2] with partial success.  Files that were for protected mode applications 
  986. > tended to be unrecoverable.  F-prot was unable to do either.
  987.  
  988. The virus is unknown to F-Prot and F-Prot never tries to remove an
  989. unknown virus. According to the documentation of Clean 104, it is not
  990. able to disinfect the "Sticky [ML2]" virus. This explains why neither
  991. of the programs has been able to correctly remove the file infections.
  992. The boot sector infection has been removed by a different method
  993. (which does not need to identify the virus).
  994.  
  995. > Being as we've relied on periodic scanning with F-Prot here at the
  996. > university as the primary means of virus detection, how often does
  997. > this happen (misidentification, or identifying two viruses as a
  998. > third)?
  999.  
  1000. Unlike SCAN, F-Prot very rarely makes a misidentification. If it tells
  1001. you that a particular virus belongs to a particular family, then you
  1002. can be pretty sure that it is indeed so. F-Prot does not distinguish
  1003. between some closely related variants, but only if they can be
  1004. disinfected using one and the same algorithm. Therefore, F-Prot will
  1005. almost never "disinfect the wrong variant" (and thus damage the file).
  1006. However, there are viruses which F-Prot cannot remove or even detect,
  1007. regardless that it is pretty good on both of these tasks.
  1008.  
  1009. Regards,
  1010. Vesselin
  1011. - --
  1012. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1013. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1014. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1015. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1016.  
  1017. ------------------------------
  1018.  
  1019. Date:    Fri, 04 Jun 93 02:08:45 +0000
  1020. >From:    hui@apaturia.trl.OZ.AU (Alvaro Hui)
  1021. Subject: Virus?? filename 'n' and content 'U---ntion' (PC)
  1022.  
  1023. Hi,
  1024.  
  1025.     I am browsing my Hard disk this morning and find that there
  1026. are more than one file named 'n' with similar content:
  1027. "U---------*ntion*". The "-" could be very long and the "ntion" could
  1028. repeat.....
  1029.  
  1030.     I use scanv104 and found no suspicous files on my drives.
  1031.  
  1032. Any help??
  1033.  
  1034. Alvaro,
  1035. a.hui@trl.oz.au
  1036.  
  1037. - ------------------------------------------------------------------
  1038. Alvaro HUI
  1039. a.hui@trl.oz.au
  1040. Synchronous Network Research
  1041. TeleCom Research Labortaries Australia.
  1042. ==================================================================
  1043. 2M->VC12->TU12->TUG2->TUG3->VC4->STM-1(AU-4);
  1044. 140M->VC4->STM-1(AU-4)
  1045. ==================================================================
  1046.  
  1047. ------------------------------
  1048.  
  1049. Date:    Thu, 03 Jun 93 21:30:36 +0000
  1050. >From:    bontchev@rzsun2.informatik.uni-hamburg.de (Vesselin Bontchev)
  1051. Subject: New anti-virus package available via ftp (PC)
  1052.  
  1053. Hello, everybody!
  1054.  
  1055. I just made available on our anonymous ftp site the anti-virus package
  1056. AVP of the Russian anti-virus expert Eugene Kaspersky. The full
  1057. reference is
  1058.  
  1059. ftp.informatik.uni-hamburg.de:/pub/virus/progs/avp.zip
  1060.  
  1061. I obtained it directly from the author. The moderators of the major
  1062. IBM-PC anti-virus archive sites are encouraged to download the archive
  1063. and make it available on their sites. Beware - the archive is about
  1064. 1.2 Mb. The package is shareware; registration fee is $20.
  1065.  
  1066. Some preliminary analysis of the package.
  1067.  
  1068. It is an integrated system, providing off-line scanning, integrity
  1069. checking, monitoring, and some expert utilities (memory browsing,
  1070. interrupt tracing, etc.). It doesn't provide resident scanning (or at
  1071. least I couldn't figure out how to use it).
  1072.  
  1073. The off-line scanner is pretty good - its hit rate on our collection
  1074. of viruses is 95% (SCAN 104 - 92%, F-Prot - 98%). It uses a bit
  1075. unusual names for the viruses - they don't conform with any of the
  1076. currently used schemes, but in general it is possible to figure out
  1077. which virus is discovered. The name of the reported virus almost
  1078. always includes its infective lenght. The scanner does a "nearly
  1079. exact" identification - even of the encrypted and polymorphic viruses.
  1080. By "nearly exact" I mean that the viruses are decrypted and the first
  1081. part of their decrypted body is checksummed (not the whole decrypted
  1082. body). Unfortunately, the scanner does not detect the MtE-based
  1083. viruses reliably. It also does not detect at all the TPE-based viruses
  1084. and some other polymorphic viruses. In particular, it does not detect
  1085. Tremor at all.
  1086.  
  1087. The integrity checking system seems relatively weak and easy to attack
  1088. by the usual methods.
  1089.  
  1090. The monitoring part is very good, but as with all monitoring programs,
  1091. it is possible to bypass it, if you try really hard.
  1092.  
  1093. The memory browsing utilities are excellent and any hacker will
  1094. appreciate them. They allow any part of the conventional memory to be
  1095. disassembled, viewed as hex and or text, modified, searched, and so
  1096. on. The memory resident programs can be listed, the interrupts too, it
  1097. is possible even to trace an interrupt and see the disassembly of the
  1098. instruction flow of the programs that have hooked this interrupt.
  1099. Those tools are invaluable to the anti-virus researcher when s/he
  1100. wants to examine a possibly active virus in memory.
  1101.  
  1102. The program comes with an excellent help system, which describes each
  1103. of the viruses recognized by the program. The descriptions tend to be
  1104. a bit terse and technical but are mostly exact. One drawback - they
  1105. tend to abuse the phrase "very dangerous virus". Almost every virus is
  1106. classified as such.
  1107.  
  1108. A really nice touch is that for many viruses there is a demo of the
  1109. sound and/or video effects caused by the virus. The actual code from
  1110. the virus body is used for that purpose, so some demos might not work
  1111. on all type of displays (but the respective viruses won't be able to
  1112. show their effects either).
  1113.  
  1114. The archive contains also the "professional" version of the scanner.
  1115. The main difference with the "plain" version (which is also present)
  1116. is that the user is allowed to enter new virus descriptions. The virus
  1117. descriptions use a powerful database-like language, which is able to
  1118. describe how to detect and even remove several types of sophisticated
  1119. viruses - even of polymorphic ones. In the worst case, the user is
  1120. able even to link a function of his own (in C) that performs the
  1121. detection and removal. This program can have access to the utility
  1122. routines used by the scanner, so it does not have to "reinvent the
  1123. wheel".
  1124.  
  1125. A major drawback of the product is its documentaion. The description
  1126. of the way to enter new virus definitions is very terse and is useful
  1127. only to the professional who has considerable experience in
  1128. programming in C and dealing with viruses. In whole, the English
  1129. language of the documentation is far from perfect (and I am trying to
  1130. be polite, knowning that my own English is "far from perfect") and
  1131. certainly could use the help of a native English speaker.
  1132.  
  1133. As a conclusion, it's a good, professional package, it is useful, but
  1134. it also needs a lot of work and improvements.
  1135.  
  1136. Regards,
  1137. Vesselin
  1138.  
  1139. P.S. Please, send all questions about the package to the author; he is
  1140. available by e-mail. His e-mail address can be found in the package.
  1141.  
  1142. P.P.S. I am using the opportunity to transfer a request from the
  1143. author. If there are any VirNet users who also have access to
  1144. anonymous ftp, please download the package from our site and transfer
  1145. it to VirNet. I don't have access to VirNet myself, so I am not able
  1146. to do it. Thanks.
  1147. - --
  1148. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  1149. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  1150. < PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  1151. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  1152.  
  1153. ------------------------------
  1154.  
  1155. End of VIRUS-L Digest [Volume 6 Issue 91]
  1156. *****************************************
  1157.