home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1993 #2 / Image.iso / magazine / vl6_094.zip / VIRUSL6.094
Text File  |  1993-06-14  |  20KB  |  510 lines
  1. VIRUS-L Digest   Monday, 14 Jun 1993    Volume 6 : Issue 94
  2.  
  3. Today's Topics:
  4.  
  5. Re: about Digital Enterprises $5,000 challenge...
  6. DFN-CERT gopher
  7. Re: Virus as extortion
  8. Thompson Paper on UNIX Viruses (UNIX)
  9. Anti-Virus Techniques and direct Port Writes (PC)
  10. Flip atack again (PC)
  11. DOS 6 - on a PC with 2 harddisks (PC)
  12. viruscopy-protection (PC)
  13. Re: Cure against Tremor available? (PC)
  14. Change detection software (CVP)
  15. (Really short) Review of (really silly) VIRUSDIE for Atari
  16.  
  17. VIRUS-L is a moderated, digested mail forum for discussing computer
  18. virus issues; comp.virus is a gatewayed and non-digested USENET
  19. counterpart.  Discussions are not limited to any one hardware/software
  20. platform - diversity is welcomed.  Contributions should be relevant,
  21. concise, polite, etc.  (The complete set of posting guidelines is
  22. available by FTP on cert.org or upon request.)  Please sign submissions
  23. with your real name; anonymous postings will not be accepted.
  24. Information on accessing anti-virus, documentation, and back-issue
  25. archives is distributed periodically on the list.  A FAQ (Frequently
  26. Asked Questions) document and all of the back-issues are available by
  27. anonymous FTP on CERT.org (192.88.209.5).
  28.  
  29. Administrative mail (e.g., comments, suggestions, beer recipes)
  30. should be sent to me at: krvw@AGARNE.IMS.DISA.MIL.
  31.  
  32. All submissions should be sent to: VIRUS-L@Lehigh.edu.
  33.  
  34.    Ken van Wyk
  35.  
  36.  
  37. ----------------------------------------------------------------------
  38.  
  39. Date:    Fri, 11 Jun 93 14:10:39 -0400
  40. >From:    ejo@kaja.gi.alaska.edu (Eric J. Olson)
  41. Subject: Re: about Digital Enterprises $5,000 challenge...
  42.  
  43. hobbit@babyoil.ftp.com (*Hobbit*) writes:
  44.  
  45. >Taken from Prodigy.  Figures.
  46.  
  47. Actually this is a common sort of challenge and has been used for all
  48. sorts of things historically, from safes to codes to computers.
  49.  
  50. Eric Olson <ejo@kaja.gi.alaska.edu>
  51.  
  52. ------------------------------
  53.  
  54. Date:    Fri, 11 Jun 93 21:27:03 +0000
  55. >From:    jdc@selway.umt.edu (John-David Childs)
  56. Subject: DFN-CERT gopher
  57.  
  58. Forwarded from the NET-HAPPENINGS list (maybe Vesselin has already posted
  59. this by now :-) :
  60.  
  61. >Date: 10 Jun 93 11:30:55 GMT
  62. >From: hille@fbihh.informatik.uni-hamburg.de (Gunter Hille)
  63. >Subject: Announcing the DFN-CERT gopher server
  64. >Newsgroups: comp.infosystems.gopher
  65. >Organization: University of Hamburg, Germany
  66.  
  67.  
  68. The DFN-CERT is pleased to announce a new gopher server containing an archive
  69. of texts related to computer security. The majority of these texts was
  70. collected from different ftp servers and other archives.
  71.  
  72. The headlines are short descriptions of the contents and most of them show
  73. the approximate size in the headline, so browsing through the texts
  74. can be helpful. At the top level you can use the WAIS search engine
  75. to search for special keywords.
  76.  
  77. The address of the gopher server is:
  78.  
  79.     gopher.informatik.uni-hamburg.de   port 70
  80.  
  81. Please note that this gopher server is a mirror of our ftp-archive of
  82. security related literature:
  83.  
  84.     ftp.informatik.uni-hamburg.de/pub/security
  85.  
  86. If you find literature related to computer security not yet in this gopher,
  87. please send a note to:
  88.  
  89. dfncert@informatik.uni-hamburg.de
  90.  
  91.  
  92. - -- 
  93.                           John-David Childs
  94.                           Consultant, University of Montana CIS
  95.                           UM Student Health Service HEALTHLINE Gopher Admin
  96.                           jdc@selway.umt.edu, con_jdc@lewis.umt.edu
  97.  
  98. ------------------------------
  99.  
  100. Date:    11 Jun 93 23:14:22 -0500
  101. >From:    x92jinnah@gw.wmich.edu
  102. Subject: Re: Virus as extortion
  103.  
  104. wouter@stack.urc.tue.nl (Wouter Slegers) writes:
  105. > This may not be common for this group, but as this is about virusses...
  106. > A friend of mine who programs a up/download-protocol got a threath (sp?)
  107. > from Russia: Either he sold the program to them for $5 (normally $15) or
  108. > they would release a virus with his name in it (maybe even with the
  109. > protocol, I don't know for sure). He didn't comply and changed the
  110. > coding/protection of his program radically to make it more difficult to
  111. > hack/infect it. 
  112. > How do you feel about this? Can you give us advise as to how to handle this?
  113. > Do you have tips to prevent deliberate infections and hacks? (Although this
  114. > program is already quite protected with encryption e.g. ideas are always
  115. > welcome).
  116. > BTW: this is all on the PC-platform.
  117. > Wouter Slegers, 1st year CS at TUE (nl), wouter@stack.urc.tue.nl.
  118.  
  119.    I would suggest you keep the letter (or email) you received as
  120. proof, in case they really carry out the threat. Don't worry about
  121. having your name in a virus; some of the most famous virus-busters
  122. (including Bontchev and Frisk, I believe) have had their name inserted
  123. into a virus. It won't fool anyone because it's obvious no-one's that
  124. dumb to be associated with a virus. No author would put his name in to
  125. be traced.
  126.  
  127.    Perhaps you could arrange with the local authorities to plan some
  128. kind of "sting" operation to grab these guys and put them away. It's
  129. quite a clear case of extortion.
  130.  
  131. ------------------------------
  132.  
  133. Date:    Sun, 13 Jun 93 14:49:57 -0400
  134. >From:    SPIRIT@WILDWOOD.DEMON.CO.UK
  135. Subject: Thompson Paper on UNIX Viruses (UNIX)
  136.  
  137. I have been trying to locate a copy of the paper by J. David Thompson
  138. titled "Why UNIX is Immune to Computer Viruses".
  139.  
  140. It was discussed some time ago in this group.
  141.  
  142. Any suggestions as to how I can obtain a copy, in electronic or paper
  143. form, would be helpful. 
  144.  
  145. Regards, MikeH 
  146.  
  147. - --------------------------------------------------------------
  148. * Mike Horrell                   spirit@wildwood.demon.co.uk *
  149. *                                                            *
  150. * wildwood is not affiliated with any other demon.co.uk site *
  151.  
  152. ------------------------------
  153.  
  154. Date:    Fri, 11 Jun 93 09:42:18 -0400
  155. >From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  156. Subject: Anti-Virus Techniques and direct Port Writes (PC)
  157.  
  158. Inbar asks about QEMM "stealth" and it really is some very good code
  159. that doesn't always work. The premise is that the BIOS takes up RAM in
  160. the first meg that could be used for other programs. The 386 allows
  161. dynamic memory mapping so it is just a matter of having the right page
  162. mapped to segment F000h at the right time.
  163.  
  164. Now QEMM's mechanism requires that expanded memory (page frameing) be
  165. available before "stealth" will work and I do not need EMS so I find
  166. that the "stelth" gain is offset by the page frame loss so do not use
  167. it. However, there is no architectural requiremnt for a page frame
  168. when using "stealth" & I suspect that it is a drive loading issue.
  169.  
  170. Now, QEMM "stealth" relies on knowing *when* to swap memory. This relies
  171. on knowing when the BIOS is needed. The first and easiest to determine is
  172. the interrupt table. If an interrupt points to segment F000 then all that
  173. QEMM "stealth" needs to do is to redirect the interrupt to itself, and on
  174. call swap the BIOS in, and when done, swap it out again (actually not the
  175. most efficient mechanism but the easiest to impliment).
  176.  
  177. The hooker is when "something" already took away the interrupt so that when
  178. QEMM loads, the interrupt points to RAM rather than to ROM. Apparently,
  179. QEMM during installation "walks" such interrupts looking for a JMP FAR or
  180. CALL FAR to the BIOS. When it finds one, it replaces the vector with
  181. one to its own code that does the swap and files the original call (where
  182. my stuff got bothered).
  183.  
  184. One exercise for the student would be to examine how QEMM "stealth" would 
  185. handle an indexed CALL FAR / JMP FAR, self modifying code (oh no), a
  186. pre-stacked RETF (oy und veh) to the BIOS, or a double jump routine.
  187.  
  188. Inbar's INs and OUTs would be immune of course since these do not
  189. involve any code in segment F000h but the problem is still how to know
  190. *when* to do those INs and OUTs. For this reason the technique is
  191. useful for user- initiated actions such as data recovery and not much
  192. use by themselves to a virus writer 8*). In particular, heuristic
  193. scanners might find it a good idea to scan for INs and OUTs since few
  194. programs would have any to use them.
  195.  
  196.                         Warmly,
  197.                             Padgett
  198.  
  199. ------------------------------
  200.  
  201. Date:    Fri, 11 Jun 93 10:16:46 -0400
  202. >From:    SALVA@vm.cpd.ua.es
  203. Subject: Flip atack again (PC)
  204.  
  205. Hi, I have a 386 pc computer with 120 Mb of HD and 4Mb of MMemory.
  206. This compute r was infected by te Flip. The Flip was cleaned, but the
  207. 100 Mb was transform to 32 Mb (the fdisk detect 120 Mb), but DOS 5.0
  208. detect 32.  Any idea to recover the information above 32 mb thru 120?
  209. If this an old problem, please answer directly to me, not to the list.
  210. Thanks.
  211.      ____________________________________________________________
  212.     >                                                            <
  213.     |   Salvador P. Sanchez    Salva@ealiun11.bitnet             |
  214.     |   University of Alicante Salva@vm.cpd.ua.es                |
  215.     |   Spain                  Fax 34-6-5903464                  |
  216.     >____________________________________________________________<
  217.  
  218. ------------------------------
  219.  
  220. Date:    Sun, 13 Jun 93 06:53:50 -0400
  221. >From:    "Jorgen Olsen" <masjol@dou.ou.dk>
  222. Subject: DOS 6 - on a PC with 2 harddisks (PC)
  223.  
  224. Today many PC-users believe that the moment their PC runs into
  225. problems - they are infected by a Virus. So though this has nothing to
  226. do with an infection - the information might save you some time.
  227.  
  228. Background:
  229.     486/33DX clone, 8MB, DOS-6, 204 MB (IDE)-disk, expanded with another
  230.     disk (245MB) with the new big one as the primary (C:) disk - and the
  231.     old one as the secondary (D:). No fancy DOS-6 utilities installed,
  232.     as the version was installed for testing purposes.
  233.     However MEMMAKER had been run and provided me with another 3KB.
  234.  
  235. Problem(s):
  236.     a.    The weekly run of Norton Disk Doctor reported
  237.           'error in the CMOS-setup of D:',
  238.           and    i)   hang up the system,
  239.           or     ii)  aborted with the result that afterwards DOS
  240.                       refused to recognize the existence of D:,
  241.                  until a reboot was performed.
  242.     b.    my streamer software also refused to accept the existence of D:.
  243.           So suddenly backup of the disk (my DATA-DISK) was impossible
  244.           and regaining access demanded a reboot,
  245.     c.    trying to look at the configuration with FDISK (in display mode)
  246.           yielded - 'run time error rn305 (or something like that),
  247.           divide by zero'!! Cold Boot needed!
  248.     d.    CKSETUP (a program in the CHK-IT-package) - halted the system
  249.           (said it could not reload COMMAND.COM) when asked to look at D:!
  250.           Reboot!
  251.  
  252. Theories:
  253.     a.    something wrong with the CMOS-setup,
  254.     b.    timer problem - if the timer of the secondary had not
  255.           been disabled (it had!!),
  256.     c.    disk problem,
  257.     d.    others - BUT not an infection
  258.          (I am the guy who has the responsibility of the distribution
  259.           of the anti-virus software and that machine is loaded with
  260.           all the goodies that access to the INTERNET as well as money
  261.           can provide you with - everything properly licensed - if needed)!
  262.           (No DOS6 Anti-virus tools installed at the moment)!
  263.  
  264. So being out of the office on business a couple of days ago the tech team
  265. of the Center with first class system support took care of the backup
  266. and went in - if need be 'able and willing' to do what might have to be
  267. done - up (or rather down) to low level formatting!
  268.  
  269. The fact finding:
  270.     a.    By mistake they booted with a DOS-5 write protected diskette
  271.           - and then could not recreate the problems!
  272.     b.    Reboot for the installed DOS-6 enabled them!!
  273.     c.    BOOT from a DOS-6 (write protected safety-diskette) - no problems.
  274.  
  275. The solution:
  276.     The difference between the 'hard disk' boot and the diskette ditto
  277.     was in CONFIG.SYS and AUTOEXEC.BAT.
  278.  
  279.     MEMMAKER had added 'HIGHSCAN' to the EMM386-line in CONFIG.SYS -
  280.     removing that solved the problem!!
  281.  
  282. My Question:
  283.     The team fined me - for installing hazardous non-standard software on my
  284.     machine without being able to foresee the consequences and thus
  285.     wasting their time! - I have to finance the cake for our next general
  286.     meeting.
  287.  
  288.     NOW - where (and how) do I get my refund from MicroSoft??
  289.  
  290. Jorgen Olsen
  291.  
  292.  
  293.  
  294. ------------------------------
  295.  
  296. Date:    Mon, 14 Jun 93 02:16:24 -0400
  297. >From:    KARGRA@GBA930.ZAMG.AC.AT
  298. Subject: viruscopy-protection (PC)
  299.  
  300. Hi all,
  301. I just came across an interesting question for windows-users:
  302. If I have installed virstop or something similar, it should scan floppies
  303. before they are accessed from a DOS-prompt. Is this effective, if I access
  304. a floppy from WINDOWS-filemanager, too?
  305. This brings me to another idea for OS2 users: as programs like virstop may
  306. either not run at all (didn't try it) or will never know, that the floppy is
  307. accessed (by the nature of a mulitasking environment), the only way to set up
  308. some kind of protection would be to put the internal copy command to an externa
  309. l
  310. which could scan before copying. However, drag an drop with PM would fail
  311. again. :(
  312.  
  313. Greetings, Alfred
  314. ################################################################################
  315. Alfred Jilka             #This place intentionally left blank. This place inteti
  316. Geologic Survey, Austria #onally left blank. This place intentionally left blank
  317. KARGRA@GBA930.ZAMG.AC.AT #. This place intentionally left blank. This place inte
  318. ################################################################################
  319.  
  320. ------------------------------
  321.  
  322. Date:    Mon, 14 Jun 93 08:34:25 -0400
  323. >From:    al026@yfn.ysu.edu (Joe Norton)
  324. Subject: Re: Cure against Tremor available? (PC)
  325.  
  326. RH>I checked TBCLEAN against one tremor-infected file and it
  327. RH>cleaned it perfectly.  Since TBCLEAN uses something like a
  328. RH>soft-ICE to find the original codeentry I am sure that it
  329. RH> will clean all other files, too.
  330.  
  331.    I tried TBCLEAN v6.01 on a PC-Tools v6 or v7 COMPRESS.EXE
  332. that was infected with Tremor.  When cleaned it was left
  333. non-operational.  After attempting to clean 30-40 Tremor
  334. infected files I've found that it is sucessfull only about
  335. 50% of the time.  Maybe v6.02 is better...
  336.  
  337.                     Joe
  338.  
  339. ------------------------------
  340.  
  341. Date:    Fri, 11 Jun 93 13:24:39 -0400
  342. >From:    "Rob Slade" <roberts@decus.ca>
  343. Subject: Change detection software (CVP)
  344.  
  345. PRTAVSC.CVP   930522
  346.  
  347.                      Change detection software
  348.  
  349. Change detection software, also often referred to as "integrity"
  350. checking software, examines system and/or program files and
  351. configuration, stores the information, and compares it against the
  352. actual configuration at a later time.  Most of these programs
  353. perform a "checksum" or "cyclic redundancy check" (CRC) that will
  354. detect changes to a file even if the length is unchanged.  Some
  355. programs will even use sophisticated encryption techniques to
  356. generate a signature that is, if not absolutely "immune" to
  357. malicious attack, prohibitively "expensive", in processing terms,
  358. from the point of view of a virus.
  359.  
  360. A sufficiently advanced change detection system, which takes all
  361. factors including "system" areas of the disk and the computer memory
  362. into account, has the best chance of detecting "all current and
  363. future" viral strains.  However, change detection also has the
  364. highest probability of "false alarms" since it will not know whether
  365. a change is viral or valid.  (Additional thought put into the
  366. installation of change detection software will go a long way to
  367. reducing the level of false positive results.  As always with
  368. security systems, there is a trade-off between the "easy" and the
  369. "effective".)  Addition of "intelligent" analysis of the changes
  370. detected may assist with this failing.
  371.  
  372. There are three major shortcomings of change detection software. It
  373. provides no protection, but only notification after the fact of an
  374. infection.  It is, therefore, quite possible to install an infected
  375. program on your system and have it continue to infect other
  376. programs.  The subsequent infections will (or should) be detected,
  377. but the change detection software will not identify the original
  378. culprit.  (Deductive reasoning, along with the software's
  379. assistance, may, though.)  
  380.  
  381. Secondly, you must "inform" the software of any changes *you* make
  382. in the system, otherwise the change detection software will generate
  383. a false alarm.  This means having sufficient knowledge of the system
  384. to know *when* you are making changes.  Each invocation of SETVER,
  385. for example, changes the program file, whereas "setup" changes made
  386. to Word Perfect sometimes alter the program file and sometimes
  387. change an external data file.  
  388.  
  389. Thirdly, as with scanning software, change detection software may
  390. not "see" changes made, and "hidden", by "stealth" viri.  However,
  391. even with the most esoteric "stealth" technology a virus must change
  392. *something* within the system.  Therefore, sufficiently broadly
  393. based change detection is the best bet for absolute detection of all
  394. viral programs -- if you can put up with the false alarms.
  395.  
  396. copyright Robert M. Slade, 1993   PRTAVSC.CVP   930522
  397.  
  398. ==============                      
  399. Vancouver      ROBERTS@decus.ca    | "I finally realized why Windows is truly
  400. Institute for  Robert_Slade@sfu.ca |  multitasking.  I find myself keeping some
  401. Research into  rslade@cue.bc.ca    |  secondary task (like ... mail) handy so I
  402. User           p1@CyberStore.ca    |  can make good use of the time I spend 
  403. Security       Canada V7K 2G6      |  waiting for Windows."    -Steve Edelson
  404.  
  405.  
  406.  
  407. ------------------------------
  408.  
  409. Date:    Fri, 11 Jun 93 13:38:25 -0400
  410. >From:    "Rob Slade" <roberts@decus.ca>
  411. Subject: (Really short) Review of (really silly) VIRUSDIE for Atari
  412.  
  413. ATVIRDIE.RVW   930430
  414.  
  415.                                Comparison Review
  416.  
  417. Company and product:
  418.  
  419. VIRUSDIE, no contact info available
  420.  
  421. Summary: scanner (with "game" interface?)
  422.                               
  423.  
  424. Cost  Unknown
  425.  
  426. Rating (1-4, 1 = poor, 4 = very good)
  427.       "Friendliness"
  428.             Installation      
  429.             Ease of use       
  430.             Help systems      
  431.       Compatibility           
  432.       Company
  433.             Stability         
  434.             Support           
  435.       Documentation           
  436.       Hardware required       
  437.       Performance             
  438.       Availability            
  439.       Local Support           
  440.  
  441. General Description:
  442.  
  443.  
  444.  
  445.                   Comparison of features and specifications
  446.  
  447.  
  448.  
  449. User Friendliness
  450.  
  451. Installation
  452.  
  453. All files said to be needed are included in the distribution archive.
  454.  
  455. Ease of use
  456.  
  457. The "game" interface seems simple, but may unnecessarily complicate operation.
  458.  
  459. Help systems
  460.  
  461. None provided.
  462.  
  463. Compatibility
  464.  
  465. Must have low resolution monitor.  May corrupt certain disks.
  466.  
  467. Company Stability
  468.  
  469. Unknown.  Latest archive found dated December, 1989.
  470.  
  471. Company Support
  472.  
  473. Unknown.
  474.  
  475. Documentation
  476.  
  477. Extremely brief.  No contact info included.
  478.  
  479. System Requirements
  480.  
  481. Low resolution monitor.  Only standard Atari ST formatted disks.
  482.  
  483. Performance
  484.  
  485. Unknown.
  486.  
  487. Local Support
  488.  
  489. None provided.
  490.  
  491. Support Requirements
  492.  
  493. Unknown.
  494.  
  495. copyright Robert M. Slade, 1993   ATVIRDIE.RVW   930430
  496.  
  497. ==============
  498. Vancouver      ROBERTS@decus.ca         | "If you do buy a
  499. Institute for  Robert_Slade@sfu.ca      |  computer, don't
  500. Research into  rslade@cue.bc.ca         |  turn it on."
  501. User           p1@CyberStore.ca         | Richards' 2nd Law
  502. Security       Canada V7K 2G6           | of Data Security
  503.  
  504. ------------------------------
  505.  
  506. End of VIRUS-L Digest [Volume 6 Issue 94]
  507. *****************************************
  508.  
  509.