home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.73 < prev    next >
Text File  |  1995-01-03  |  22KB  |  513 lines

  1. VIRUS-L Digest   Tuesday, 10 Apr 1990    Volume 3 : Issue 73
  2.  
  3. Today's Topics:
  4.  
  5. Gatekeeper 1.1.1 & Scores (Mac)
  6. Disinfectant 1.7 and GateKeeper (Mac)
  7. Re: Universal Virus Detector
  8. Validate program corrupted?? (PC)
  9. Low Level Format (PC)
  10. Re: Validating Virus Software
  11. Re: FTP from SIMTEL20 to VM/CMS (Internet)
  12. What do I buy? (PC)
  13. re: Universal Virus Detector
  14. FTP and .hqx (Mac)
  15. Re: Virus in Text Files (Mac)
  16. Oops- wrong thing sent
  17. Virus info request (PC)
  18. Archive service at Heriot-Watt
  19. Re: Virus in Text Files
  20.  
  21. VIRUS-L is a moderated, digested mail forum for discussing computer
  22. virus issues; comp.virus is a non-digested Usenet counterpart.
  23. Discussions are not limited to any one hardware/software platform -
  24. diversity is welcomed.  Contributions should be relevant, concise,
  25. polite, etc.  Please sign submissions with your real name.  Send
  26. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  27. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  28. anti-virus, documentation, and back-issue archives is distributed
  29. periodically on the list.  Administrative mail (comments, suggestions,
  30. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  31.  
  32.    Ken van Wyk
  33.  
  34. ---------------------------------------------------------------------------
  35.  
  36. Date:    Mon, 09 Apr 90 10:30:00 -0400
  37. From:    Thank you matchline <S10891KH@SEMASSU.BITNET>
  38. Subject: Gatekeeper 1.1.1 & Scores (Mac)
  39.  
  40. The following is an excerpt of a letter sent to John Norstadt, Author of
  41. disinfectant and may be of interest to anyone who uses gatekeeper
  42. ____________________________________________________________________
  43.                                                            SMU,  9-APR-1990
  44.  
  45.     John, I'm sending this to you because I think it may be of interest.  I
  46. just downloaded gatekeeper 1.1.1 off the rice archives and was in the
  47. process of evaluating its performance against scores, nVir and WDEF.
  48. Immediately I found a problem.  When starting up an application already
  49. infected with scores (on a floppy) gatekeeper announced 3 times that the
  50. virus was attempting to infect the application and its attempt was 'vetoed'
  51. Great so far.  However, after that initial warnining I waited about 10
  52. minutes and then checked on the process of the attempted infection.  By
  53. that time, pyro had come on and nothing was any different BUT when I
  54. checked the system folder the notepad file and scrapbook files had the
  55. 'dogeared page' icon.  I ran disinfectant 1.6 and guess what the system was
  56. infected as well as the desktop, clipboard and scrapbook.
  57.     It seems that gatekeeper only partly protects from scores attacks.  And
  58. worse yet disinfectant had to be run twice to completely remove all bits
  59. and pieces of scores.
  60.  
  61.                                    - Zav
  62.  
  63. ------------------------------
  64.  
  65. Date:    Mon, 09 Apr 90 12:24:33 -0400
  66. From:    jln@acns.nwu.edu
  67. Subject: Disinfectant 1.7 and GateKeeper (Mac)
  68.  
  69. Disinfectant 1.7 requires GateKeeper privileges even when just scanning.
  70. Earlier versions only required privileges when repairing.  I wasn't aware of
  71. this until after I had released 1.7, or I would have mentioned it in the
  72. document.
  73.  
  74. The solution to this problem is to simply grant Disinfectant all six
  75. GateKeeper privileges.
  76.  
  77. John Norstad
  78. Academic Computing and Network Services
  79. Northwestern University
  80.  
  81. ------------------------------
  82.  
  83. Date:    09 Apr 90 13:45:20 +0000
  84. From:    rwallace@vax1.tcd.ie
  85. Subject: Re: Universal Virus Detector
  86.  
  87. jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
  88. > I am working with a colleague on defining a robust virus detection
  89. > utility.  The following is an extended abstract of a paper which
  90. > discusses an approach we are investigating.  The work was undertaken as
  91. > part of a research project sponsored by the National Aeronautics &
  92. > Space Administration at the Johnson Space Center.  Please look it over
  93. > and tell us (or Virus-L) what you think.
  94.  
  95. This is I think the fourth serious attempt on this newsgroup to propose a
  96. universal virus detector. Unfortunately like all the rest it won't work.
  97.  
  98.         (theoretical UVD discussion)
  99.  
  100. > So to put our theoretical UVD into practice, on, for example, an IBM
  101. > PC, we would do the following:
  102. >
  103. > a.  Begin by validating the integrity of the detector code.  This has
  104. >     been discussed above. [not included in abstract]
  105.  
  106. How? I haven't copied your entire posting in this followup because it was too
  107. long but I couldn't see any proposed method for validating the detector code.
  108. And an obvious way to defeat your mechanism is to overwrite the detector
  109. program with code that always says "OK".
  110.  
  111.         ...
  112.  
  113. > f.  In order to prevent a virus from attacking the CRC table, we will
  114. >     add a set of dynamic "State Vectors" for the machine, which define
  115. >     the run time environment for the detector.  This creates an
  116. >     unforgeable "fingerprint" of the detector as it exists in memory
  117. >     and can be prepended to each file prior to computing the CRC.
  118.  
  119. What do you mean? Another obvious way to defeat the detector is to recalculate
  120. CRCs for infected programs and put the new CRC value into the table. I don't
  121. see any way to prevent this other than storing the table offline (which would
  122. create what most users would consider unacceptable hassle).
  123.  
  124. Also your detector would detect most resident programs as well as multiuser
  125. systems and upgraded versions of the operating system as viruses because it
  126. checks the system call vectors.
  127.  
  128. "To summarize the summary of the summary: people are a problem"
  129. Russell Wallace, Trinity College, Dublin
  130. rwallace@vax1.tcd.ie
  131.  
  132.  
  133. ------------------------------
  134.  
  135. Date:    Mon, 09 Apr 90 15:13:00 -1100
  136. From:    <RMAP222@euclid.ucl.ac.uk>
  137. Subject: Validate program corrupted?? (PC)
  138.  
  139. I just received this message. It was posted on the RED-UG list as you can
  140. see. If you have any questions about the message please send them to the
  141. author of the original message.
  142.  
  143. Nino
  144.  
  145. *******************************************************************************
  146. *JANET:       n.margetic@uk.ac.ucl.euclid             | Nino Margetic         *
  147. *EARN/BITNET: n.margetic%euclid.ucl.ac.uk@UKACRL      | University College    *
  148. *INTERNET: n.margetic%euclid.ucl.ac.uk@cunyvm.cuny.edu| Dept. of Med. Physics *
  149. *UUCP:        n.margetic%euclid.ucl.ac.uk@ukc.uucp    | 11-20 Capper Street   *
  150. *Phone:       [+44 - 1 | 01 ] 380-9846                | London WC1E 6AJ       *
  151. *FAX:         [+44 - 1 | 01 ] 380-9577                | Great Britain         *
  152. *******************************************************************************
  153.  
  154.  
  155. - --------------- Original message follows -------------------------------
  156. Via:     UK.AC.RUTHERFORD.MAIL ;  Mon, 9 Apr 90 14:51 GMT
  157.          (V41 at UK.AC.UCL.EUCLID)
  158. Received:from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7403; Mon, 09
  159.          Apr 90 14:50:10 BS
  160. Received:by UKACRL (Mailer X1.25) id 7680; Mon, 09 Apr 90 14:49:57 BST
  161. Date:    Mon, 9 Apr 90 15:17
  162. Reply-To:Gunnar Radons <S46@EARN.DHDURZ1>
  163. Sender:  Red File Server Users Group <RED-UG@EARN.DB0FUB11>
  164. From:    Gunnar Radons <S46@EARN.DHDURZ1>
  165. Subject: virus alert
  166. To:      BSMTP <RMAP222@UK.AC.UCL.EUCLID>
  167.  
  168. Hello netlanders,
  169.  
  170. Another topic on viruses. The german computer-journal "DOS-Shareware"
  171. reported the following in it's No. 3 issue :
  172.  
  173. There is an infected version of SCANV58.zip. Actually the VALIIDATE
  174. program seems to be changed. The original VALIDATE should be a .COM
  175. file, while the corrupt is a .EXE with  46167 bytes (instead of 6485)
  176. The original SCAN.EXE should have the values: Size: 42977 bytes,
  177. Date: 2-15-1990, File Authentication:  Check Method 1: 2F16, Method 2:
  178. 1C57.
  179. This message is to be found on page 77 of the above journal.
  180.  
  181. Also there are to files  "NORTSTOP.ZIP" and "NORTSHOT.ZIP" which
  182. claim to be written by peter norton. Both contain a trojan which
  183. erases some files between christmas and new year. To identify those
  184. look in the .ZIP file for NORTSHOT.EXE and in the .EXE for the string
  185. "Norton Public". If you find those trojan please inform Tony McNamara
  186. from Norton computing (phone: US: 213/319-2076). The length of NORTSHOT
  187. is 38907 bytes and it's date is 02.01.89 (European format I suppose).
  188. This message is from page s6 of the above journal.
  189.  
  190. This message will be sent to RED-UG and games-l (Apr. 8. 1990).
  191.  
  192. Bye,
  193. Gunnar
  194.  
  195. :----------------------------------------------------------------------:
  196. :                                          ::                          :
  197. : Gunnar Radons                            :: Gunnar Radons            :
  198. : Astronomisches Recheninstitut Heidelberg :: s46@dhdurz1              :
  199. : Moenchhofstr. 12-14                      ::                          :
  200. : D-6900 Heidelberg                        :: (+49) 6221 405147        :
  201. :                                          ::                          :
  202. :------------------------------------------::--------------------------:
  203. :           Do you have the solution or are you the problem?           :
  204. :----------------------------------------------------------------------:
  205.  
  206.  
  207. ------------------------------
  208.  
  209. Date:    Mon, 09 Apr 90 15:59:02 -0000
  210. From:    LBA002@PRIME-A.TEES-POLY.AC.UK
  211. Subject: Low Level Format (PC)
  212.  
  213. Many thanks to all those who sent me messages about low-level formatting. I now
  214. have a very clear idea of what it does and when to use it.
  215. Great help (as usual) from the -LIST
  216. Rgds,
  217. Iain Noble
  218. Teesside Polytechnic Library (UK)
  219. - -----------------------------------------------------------------------------
  220. Iain Noble                                   |
  221. LBA002@pa.tp.ac.uk                           |  Post:  Main Site Library,
  222. JANET: LBA002@uk.ac.tp.pa                    |         Teesside Polytechnic,
  223. EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
  224. INTERNET: LBA002%pa.tp.ac.uk@cunyvm.cuny.edu |         Cleveland, UK, TS1 3BA
  225. UUCP: LBA002%tp-pa.ac.uk@ukc.uucp            |  Phone: +44 642 218121 x 4371
  226. - -----------------------------------------------------------------------------
  227.  
  228. ------------------------------
  229.  
  230. Date:    Mon, 09 Apr 90 09:52:07 -1000
  231. From:    Jim Wright <jwright@cfht.cfht.hawaii.edu>
  232. Subject: Re: Validating Virus Software
  233.  
  234. I am willing to start a new mothly posting, which includes validation
  235. information for various popular anti-viral software packages.  It need
  236. not be limited to ibmpc software.  Each author is free to choose their
  237. own favorite validation method.  Due to the nature of this, I will
  238. only accept information from the author, or from an authorized
  239. individual.  (Authorized by sending me a post card.)
  240.  
  241. I will not be able to keep up with this on my own.  Out here, ftp and
  242. modems are a bit expensive.  So I will rely on the authors to keep
  243. this up to date.
  244.  
  245. Anyone interested, just drop me a line.
  246.  
  247. Jim
  248.  
  249. ------------------------------
  250.  
  251. Date:    09 Apr 90 19:20:10 +0000
  252. From:    werner@cs.utexas.edu (Werner Uhrig)
  253. Subject: Re: FTP from SIMTEL20 to VM/CMS (Internet)
  254.  
  255. > In spite of several months of trying, I have still never successfully
  256. > obtained Disinfectant over the Internet.  I believe the problem
  257. > has something to do with 7 databit vs. 8 databit binary
  258.  
  259.           as was already exlained by the moderator, there is indeed a differenc
  260. \ce
  261.           when trying to retrieve a binary file from SIMTEL20.
  262.  
  263.           given that folks tend to have other (local) problems downloading
  264.           binaries also, I make both binaries *AND* hexed (7-bit ASCII) version
  265. \cs
  266.           of all the latest Macintosh anti-virals available for ANON-FTP on
  267.           RASCAL.ICS.UTEXAS.EDU in directory  "mac/virus-tools"
  268.  
  269. ------------------------------
  270.  
  271. Date:    Mon, 09 Apr 90 16:14:49 -0600
  272. From:    David Perales <DPERALES@TRINITY.BITNET>
  273. Subject: What do I buy? (PC)
  274.  
  275. We are in the market for a good solid product for dealing with the
  276. virus situation in the IBM world.  Hopefully something that will give
  277. us a good basis for cures, detection and possibly prevention - a good
  278. all-in-one package.  Any suggestions?
  279.  
  280.                                           Thanx,
  281.                                            David
  282.  
  283. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  284. David Perales, M.B.A., C.S.P.               BitNet:    DPERALES@TRINITY
  285. Micro Programmer Analyst                    telephony :(512)736-7401
  286. Trinity University Computing Center
  287. 715 Stadium Drive, Box 50
  288. San Antonio, Texas 78212
  289.  
  290. ------------------------------
  291.  
  292. Date:    09 Apr 90 00:00:00 -0500
  293. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  294. Subject: re: Universal Virus Detector
  295.  
  296. jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
  297. > If you have questions, or see a flaw in the process, please let us
  298. > know.  We are building a virus detector, which could be placed into the
  299. > public domain, that uses the techniques below to detect virus
  300. > infections.  Our initial tests have shown encouraging results. ...
  301.  
  302. These comments are based on the abstract only, not the paper
  303. (I'll eventually figure out how to FTP from here...).
  304.  
  305. Modification detectors seem like a promising way of detecting at
  306. least some "new" (not seen before) viruses.   The usual problems
  307. faced by a modification detector include:
  308.  
  309.  1) A virus that knows about the detector (or about a class
  310.     of them to which it belongs) might make changes that the
  311.     detector won't detect.
  312.  2) A similarly detector-aware virus might update the detector's
  313.     database to reflect the changes it makes when it infects.
  314.  3) A virus might (by luck or design) modify files in such a way
  315.     that the user, presented with a list of files that have
  316.     changed, will not notice anything wrong.
  317.  4) If the virus is active in the system when the detector runs,
  318.     it could lie to the detector about the state of the system.
  319.  
  320. A simple CRC approach runs into point (1): if lots of people start
  321. using your detector, and it always uses the same CRC polynomial,
  322. it's not all that hard for the virus to include code that patches
  323. infected objects so that the CRC is the same as it was before
  324. infection; a CRC isn't hard to invert.   My favorite solution to
  325. this is to allow the user to specify his own polynomial (through
  326. the use of a "key phrase" or whatever); other solutions also
  327. exist (crypto-based MDC's and such).  I gather from the abstract
  328. that the exact scheme used isn't fixed by the proposal; that's
  329. a reasonable approach.
  330.  
  331. I gather that your point (f)
  332. > f.  In order to prevent a virus from attacking the CRC table, we will
  333. >     add a set of dynamic "State Vectors" for the machine, which define
  334. >     the run time environment for the detector.  This creates an
  335. >     unforgeable "fingerprint" of the detector as it exists in memory
  336. >     and can be prepended to each file prior to computing the CRC.
  337.  
  338. is supposed to deal with my point (2), but I don't really
  339. understand it.  If it's possible for the detector to update the
  340. database (and it must be, when the user gets new pieces of
  341. software and so on), then it's possible for a virus to as well,
  342. if the database is ever r/w to the system while the virus is
  343. active.
  344.  
  345. (3) is one of the harder problems, I think; in some of the
  346. environments that are most important to protect (program
  347. development environments, for instance), many executables
  348. will be expected to change.   Helping the user figure out
  349. which changes are OK and which are not is something that
  350. needs considerable thinking about, I think.  Doing it
  351. perfectly is probably impossible (a good reason to avoid
  352. calling anything a "universal" virus detector...).
  353.  
  354. Most of the abstract seems to be devoted to (4); making sure
  355. the virus isn't lurking anywhere when the detector runs.
  356. This is the general computer-security problem of getting the
  357. system into a trusted state; I tend to think that the
  358. problem needs to be solved at the system level rather than
  359. the application level (that is, there should be a good
  360. wired-in procedure for getting the system into a trusted state,
  361. rather than making every security application program do
  362. it itself).   I doubt that any piece of software in DOS can
  363. really determine that the system is trustworthy; checking
  364. interrupt vectors doesn't tell you anything about the code
  365. they're pointing to, for instance.  Painful as it is, the
  366. only method I know of that I trust is booting cold from a
  367. trusted floppydisk.
  368.  
  369. Sounds like an interesting project, though, and I -will- try
  370. to get the full paper...
  371.  
  372. DC
  373.  
  374. ------------------------------
  375.  
  376. Date:    Mon, 09 Apr 90 18:09:12 -0400
  377. From:    Joe McMahon <XRJDM@SCFVM.BITNET>
  378. Subject: FTP and .hqx (Mac)
  379.  
  380. Since I run through vast amounts of sw on various servers about the net,
  381. and it always seems to work for me, try this:
  382.  
  383. 1) ftp to whereever.
  384. 2) GET the file. No binary, no translate, zilch.
  385. 3) Transfer it up with Kermit.
  386.  
  387. My feeling is that you may be trashing the file by insisting on
  388. transferring it as binary when it isn't. HQX format (as is used on the
  389. FTP servers I know of) is ASCII only, designed not to get trashed by
  390. character translations (e.g., EBCDIC to ASCII). Try not doing anything
  391. but the transfer, and I think you'll find this will work.
  392.  
  393.  --- Joe M.
  394.  
  395. ------------------------------
  396.  
  397. Date:    10 Apr 90 00:19:57 +0000
  398. From:    woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal)
  399. Subject: Re: Virus in Text Files (Mac)
  400.  
  401. Macintosh datafiles, as I understand them, have 2 parts, a resource
  402. fork and a data fork.  Anything in resource fork (so I've been told)
  403. can execute.  Does this imply that one could bury a virus in the
  404. resource fork of a data file?
  405.  
  406. I'm sure that this has been hashed over before.
  407. Cheers
  408. Woody
  409.  
  410. ------------------------------
  411.  
  412. Date:    10 Apr 90 01:35:25 +0000
  413. From:    rwillis@hubcap.clemson.edu (Richard "Crash" Willis)
  414. Subject: Oops- wrong thing sent
  415.  
  416. OOPS! Sorry guys, I sent the wrong file to a few people. Please ask
  417. again and I'll send the right information.  BTW- the paper itself is not
  418. yet avalible (although that wil change in a few days) however, the
  419. infomation I do have avalable consist of a description of Internet,
  420. Virus De-infection, a theory on a new type of virus prevention and
  421. several other papers.  Sorry again for the mess up.
  422. >* Sigh *< I'd better dig out my flame-proof underware for a few days
  423.  
  424. - -Richard rwillis@hubcap.clemson.edu
  425. "No matter how subtle the wizard, a dagger between the shoulderblades
  426. seriously cramps his style"
  427.  -Stephen Burst
  428.  
  429. ------------------------------
  430.  
  431. Date:    10 Apr 90 01:58:32 +0000
  432. From:    malv_ss@uhura.cc.rochester.edu (Max Avarez)
  433. Subject: Virus info request (PC)
  434.  
  435. Does anyone know of a virus that changes the size of PC files
  436. (usually .exe files) to 2048K?
  437.  
  438. Also, what is the best virus detection  program for the PC?
  439.  
  440. Thanks,
  441.  
  442. Max Alvarez (malv_ss@uhura.cc.rochester.edu)
  443. University of Rochester
  444.  
  445. ------------------------------
  446.  
  447. Date:    Tue, 10 Apr 90 10:29:19 -0000
  448. From:    David.J.Ferbrache <davidf@CS.HW.AC.UK>
  449. Subject: Archive service at Heriot-Watt
  450.  
  451. Just a quick note to apologise for disruption to the archive service at
  452. Heriot-Watt over the last month. The network core is due to change to a
  453. Sun system from an ageing Vax, in the meantime a re-organisation of archive
  454. service will take place.
  455.  
  456. Normal service for immediate processing of email will be restored by end May.
  457. The archive contents will be extended to include the following:
  458.  
  459. 1. General document archives (viruses)
  460. 2. PC, Mac, Amiga, Atari and Apple 2 anti-viral software
  461. 3. Archives of CERT, DDN SC and other advisories
  462. 4. Patches for BSD Unix releases
  463. 5. Risks digest backissues
  464. 6. Virus-l digest backissues
  465.  
  466. In addition I am considering a protocol for access to more sensitive materials
  467. including backissues of the Zardoz security digest, Phage mailing list
  468. (historical material from the Internet worm period), and other lists.
  469.  
  470. These will probably be available by restricted NIFTP.
  471.  
  472. Again apologies for the disruption.
  473.  
  474. - -----------------------------------------------------------------------------
  475. \c-
  476. Dave Ferbrache                            Internet   <davidf@cs.hw.ac.uk>
  477. Dept of computer science                  Janet      <davidf@uk.ac.hw.cs>
  478. Heriot-Watt University                    UUCP       ..!mcvax!hwcs!davidf
  479. 79 Grassmarket                            Telephone  +44 31-225-6465 ext 553
  480. Edinburgh, United Kingdom                 Facsimile  +44 31-220-4277
  481. EH1 2HJ                                   BIX/CIX    dferbrache
  482. - -----------------------------------------------------------------------------
  483. \c-
  484.  
  485. ------------------------------
  486.  
  487. Date:    Tue, 10 Apr 90 09:27:29 -0400
  488. From:    flaps@dgp.toronto.edu (Alan J Rosenthal)
  489. Subject: Re: Virus in Text Files
  490.  
  491. cdss!culliton@uunet.UU.NET (Tom Culliton) writes:
  492. >How many times has this question been answered?  If you can't execute the file
  493. >or run it via an interpreter it can't carry a virus.
  494.  
  495. A counterexample to this assertion is the wdef viruses on the macs.  They are
  496. carried in the Desktop file which is a data file describing the layout of the
  497. windows.
  498.  
  499. >If it's source code for a compiler or interpreter the danger is present that
  500. >it contains malicious instructions but visual inspection can quickly settle
  501. >that.
  502.  
  503. You're saying that you can quickly read the source code to an entire compiler
  504. and understand everything it does?  I find this extremely hard to believe.
  505.  
  506. ajr
  507.  
  508. ------------------------------
  509.  
  510. End of VIRUS-L Digest
  511. *********************
  512. Downloaded From P-80 International Information Systems 304-744-2253
  513.