home *** CD-ROM | disk | FTP | other *** search
/ Compu-Fix / Compu-Fix.iso / pubnews / vir04025.txt < prev    next >
Text File  |  1993-03-01  |  23KB  |  494 lines

  1.  
  2.  
  3.            VIRUS-L Digest   Monday, 11 Feb 1991    Volume 4 : Issue 25
  4.  ******************************************************************************
  5.  
  6.  
  7. Today's Topics:
  8.  
  9. "Virus" story
  10. I need help !!! (PC)
  11. FPROT and F-XCHK (PC)
  12. Re: Virus questions (PC)
  13. re: VAX/VMS and Viruses
  14. New Leprosy signiture? (PC)
  15. Re: Virus questions (PC)
  16. Re: Alameda/Yale (PC)
  17.  
  18. VIRUS-L is a moderated, digested mail forum for discussing computer
  19. virus issues; comp.virus is a non-digested Usenet counterpart.
  20. Discussions are not limited to any one hardware/software platform -
  21. diversity is welcomed.  Contributions should be relevant, concise,
  22. polite, etc.  Please sign submissions with your real name.  Send
  23. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  24. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  25. anti-virus, documentation, and back-issue archives is distributed
  26. periodically on the list.  Administrative mail (comments, suggestions,
  27. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  28.  
  29.    Ken van Wyk
  30.  
  31. ---------------------------------------------------------------------------
  32.  
  33. Date:    Fri, 08 Feb 91 17:39:11 +0000
  34. From:    adamg@world.std.com (Adam M Gaffin)
  35. Subject: "Virus" story
  36.  
  37. Thanks to all who sent me e-mail on this. Here's the story that ran in
  38. the paper, but please read it with two caveats. I got Ilene Hoffman's
  39. first name wrong, and she did NOT say Mac hard drives are prone to
  40. mechanical failure (what she said was that Mac owners are less likely
  41. to do such things as run de-fragmentation programs and I, in my Stupid
  42. Reporter mode, tried to write something the average reader would
  43. understand).
  44.  
  45. Adam Gaffin
  46. Middlesex News, Framingham, MA
  47. adamg@world.std.com
  48. Voice: (508) 626-3968
  49. Fred the Middlesex News Computer: (508) 872-8461
  50.  
  51. Middlesex News, Framingham, Mass., 2/7/91
  52. Expert: Virus unlikely budget bug
  53.  
  54. By Adam Gaffin
  55. NEWS STAFF WRITER
  56.      BOSTON - State officials say a computer virus destroyed 50 pages
  57. of Gov. Weld's budget proposal earlier this week, but a computer
  58. consultant with experience in fighting the bugs says it sounds more
  59. like a case of inadequate maintenance than anything sinister.
  60.      Michael Sentance of Maynard, a legislative aide to Weld, had typed
  61. in 50 pages of the governor's proposed budget on a Macintosh computer
  62. when he tried saving the document to the machine's hard drive around 3
  63. a.m. on Monday - only a few hours before it was due to be submitted to
  64. the Legislature.
  65.      But instead of being saved, the document disappeared, according to
  66. Liz Lattimore, a Weld spokeswoman. Sentance was eventually able to
  67. retrieve an earlier draft, filed under a different name, minus the 50
  68. pages, she said.
  69.      When Sentance ran a program to check for the presence of viruses
  70. on the machine, it responded with a message indicating a ``type 003
  71. TOPS network'' virus, Lattimore said. TOPS is the name of the network
  72. used by the Executive Office of Administration and Finance to connect
  73. its Macintoshes.
  74.      Sentance had borrowed one of that office's computers because he
  75. was more familiar with Macs than with the older Wang system in the
  76. governor's suite, Lattimore said.
  77.      Viruses are small programs that can take control of a computer's
  78. operating system and destroy other programs and data, and can be spread
  79. through people unwittingly sharing ``infected'' programs or disks.
  80.      Lattimore said officials managed to transfer data from the ailing
  81. computer to another machine, adding that they are now checking all of
  82. Administration and Finance's Macintosh computers for possible
  83. infection.
  84.      But Eileen Hoffman of Needham, a Macintosh consultant, says what
  85. happened to Sentance sounds more like a hard-drive ``crash'' than a
  86. virus - something she said is potentially far more destructive.
  87.      A document that disappears when the user tries to save it onto the
  88. hard drive usually means there is something physically wrong with the
  89. computer's hard drive, not that it is under viral attack, Hoffman said.
  90.      Hoffman, who keeps three or four infected disks in a safe so that
  91. she can test new anti-viral software, said the software that runs TOPS
  92. networks is written in such a way that it can show up as a ``virus'' in
  93. programs that check for viruses. She said a ``Type 003'' virus is one
  94. of these phantom ``sneak'' viruses.
  95.      Hoffman said Macintosh users are often more lax about maintaining
  96. their computer's hard drives than users of IBM compatible machines,
  97. because Macintoshes are aimed at people who do not want to have
  98. anything to do with the hardware of their machines. The Macintoshes
  99. were installed during the Dukakis administration.
  100.      But even Mac hard drives require regular maintenance, she said.
  101. She said she often gets calls from clients who blame disappearing data
  102. or strange things on their screens on viruses, but that almost always
  103. the problem is caused by a mechanical hard-drive problem.
  104.      She added that the particular version of anti-viral software
  105. Sentance used is two years out of date. Since new viruses are created
  106. all the time, this means the software might not be able to detect one
  107. even if the machine were infected, she said.
  108.  
  109. ------------------------------
  110.  
  111. Date:    Fri, 08 Feb 91 18:12:00 +0000
  112. From:    cdbenaiah@trillium.uwaterloo.ca ()
  113. Subject: I need help !!! (PC)
  114.  
  115. Help!!!
  116.  
  117. I think I was savaged by a virus/trojan/nasty type of thing. My hard
  118. drive (120 MB PS/2 ESDI drive) has been savaged. It no longer is
  119. recognized at boot up. Apparently this virus thing or whatever wrote
  120. over the partition table. I ran fdisk and set up the original
  121. partition, and now it recognizes my hard drive, but when I try to read
  122. C: it says 'Invalid media type drive C'. I can run Norton Utilities in
  123. maintenance mode, and it will read the info on the disk, but otherwise
  124. I can't read it. When I run the technical information section of
  125. norton it says my hard drive is a 360K drive :-(.
  126.  
  127. What can I do? Am I toast forever, or is the data/directories
  128. recoverable?  I was running FRECOVER from norton before it bombed,
  129. will this help? Can Norton help? Do I need something else like MACE
  130. utilities (I have heard they can recover from this)? The way I see it
  131. is the nasty tried to write its boot sector over the hard drive, thus
  132. making it think it is a 360K floppy and just die. What are my chances
  133. of data recovery here? Can anyone recommend a program to help, or
  134. better yet, send me one???
  135.  
  136. All help appreciated! Please send mail right away - I need help quickly!!!
  137.  
  138. Thanks in advance...
  139.  
  140. ------------------------------
  141.  
  142. Date:    Fri, 08 Feb 91 08:55:30 -0800
  143. From:    p1@arkham.wimsey.bc.ca (Rob Slade)
  144. Subject: FPROT and F-XCHK (PC)
  145.  
  146. I received an emergency call yesterday from one of the members of
  147. INtegrity.  She had tried out a few of the FPROT programs, and found
  148. them easy enough to use that she decided to experiment with the other
  149. programs without reading the documentation....
  150.  
  151. ==<orks > INtegrity > GrapeVine > Virus protection > Slade, Robert - INte
  152. ======
  153.  
  154.   Subject: FPROT and F-XCHK
  155.  
  156.   From Danielle Trottier:
  157.  
  158.   I was glad I had downloaded the F-PROT programm until today...
  159.   but I have no fear, thanks to Robert Slade I am still glad I did
  160.  
  161.   I was playing around and decided to trust that each program of
  162.   F-PROT would guide me as how to use it so that way I wouldn't
  163.   have to read trought the entire litterature that came with it...
  164.  
  165.   So I used the F-XCHK command before using the F-XLOCK and
  166.   because of that, all .exe or .com (absolutely everything...
  167.   except for your basic DIR COPY TYPE commands) answered me back
  168.   with ACCESS DENIED...
  169.  
  170.   I 've learned my lesson I will definitely always read the
  171.   litterature that comes with the software from now on.
  172.  
  173.   =========
  174.  
  175.   Just to add a little to Danielle's posting:
  176.  
  177.   The documentation for FPROT does stated quite clearly what must
  178.   be done before F-XCHK is used.  It also warns that F-XCHK is
  179.   something that you may not be able to use on your system.
  180.  
  181.   Fortunately we were able to solve Danielle's problem quite
  182.   quickly, since she had not installed F-XCHK in the AUTOEXEC.BAT
  183.   file.  F-XCHK prevent any "non-F-XLOCKed" programs from running,
  184.   but rebooting removed F-XCHK from memory.
  185.  
  186.  
  187. Vancouver          p1@arkham.wimsey.bc.ca           _n_
  188. Insitute for       Robert_Slade@mtsg.sfu.ca          H
  189. Research into      (SUZY) INtegrity                 /
  190. User               Canada V7K 2G6                O=C\
  191. Security                            Radical Dude   | O- /\_
  192.                                              /-----+---/ \_\
  193.                                             / |    `  ||/
  194. "A ship in a harbour is safe, but that     /  ||`----'||
  195. is not what ships are built for."             ||      ||
  196.                      - John Parks             ``      ``
  197.  
  198. ------------------------------
  199.  
  200. Date:    09 Feb 91 05:34:50 +0000
  201. From:    ms@pogo.ai.mit.edu (Morgan Schweers)
  202. Subject: Re: Virus questions (PC)
  203.  
  204.  
  205. Greetings,
  206.     In regards to the question about viruses loading themselves
  207. high...  No viruses as yet have the capability to place themselves
  208. high in memory.  To understand why, look at it like this...  First you
  209. would need a memory manager.  You can't assume that every system you
  210. infect will have one, so you need to carry it around with you.  Then
  211. you need a load-high routine (much less difficult).  For Some Reason
  212. (tm) viruses don't successfully load high.  It may be due to the
  213. oft-used technique of determining their own location and modifying
  214. themselves thereby.  This may not be supported by the memory managers
  215. I've tested viruses under.  I just recieved a new environment, and
  216. will be testing to see if this is susceptible.
  217.  
  218.     If anyone has experience with a virus which successfully loaded
  219. high, I would *VERY* much like to know!
  220.  
  221.                                                   --  Morgan Schweers
  222.  
  223.    P.S.  No, viruses do not infect non-executable code on PC's.
  224.    P.P.S.  What sort of AI techniques were you thinking of?
  225.  
  226. ------------------------------
  227.  
  228. Date:    Sat, 09 Feb 91 10:07:16 -0400
  229. From:    Jerry Leichter <leichter@LRW.COM>
  230. Subject: re: VAX/VMS and Viruses
  231.  
  232. Bert Medley asks for information about virus protection software for
  233. VAX/VMS and Unix systems.  I'll leave it to others to speak about Unix
  234. - - though I suspect the answers will be pretty much the same - but the
  235. story in the VMS world appears to be as follows:
  236.  
  237.         - As far as I'm aware, no VMS viruses have been reported so far.
  238.                 That's not at all to say that they can't be, or even haven't
  239.                 been, written; it's just that if there are any, they have
  240.                 either not spread much, or (if you insist on the paranoid
  241.                 view) are so good that no one has detected them yet.
  242.  
  243.                 Note that most of the PC world's virus detectors are based
  244.                 on scanning for known viruses (of which so far hundreds are
  245.                 known).  Since there are no known VMS viruses, it's meaning-
  246.                 less to use a VMS virus scanner of this sort at this point.
  247.  
  248.         - The protection mechanisms available on VMS (or Unix) are much more
  249.                 sophisticated than those on PC's.  Again, this doesn't mean
  250.                 that viruses can't be written; it just means that they are
  251.                 harder to write, will likely be bigger - and will have to
  252.                 use more elaborate mechanisms to spread.
  253.  
  254.                 In particular:  "Boot sector"-like viruses - which gain con-
  255.                 trol during system boot - could only be inserted by software
  256.                 that managed to gain privileges.  Similarly, viruses that
  257.                 wished to take over system calls would first have to gain
  258.                 privileges.  On both Unix and VMS, this would be true even
  259.                 for a viral program trying to take over only calls made by
  260.                 programs run subsequently, in the same login session, by the
  261.                 same user.  This means that some of the other common kinds of
  262.                 PC anti-virals - the boot-sector checkers and, particularly,
  263.                 the disk-write-monitors, are also pretty pointless on VMS
  264.                 systems.
  265.  
  266.                 Actually, it even goes beyond that:  On VMS, it is possible
  267.                 to set alarms on files that will log messages if any attempt
  268.                 is made to modify them.  Turning the alarms off without set-
  269.                 ting off yet other alarms is quite difficult.  Alternatively,
  270.                 the VMS on-disk structure is very complex; while a privileged
  271.                 program COULD write directly to the physical disk, it would
  272.                 require a lot of code for it to write to a particular block
  273.                 of a particular file without help from the file system (which
  274.                 could raise an alarm).  Note that on any PARTICULAR system,
  275.                 one could determine ahead of time just what to write where;
  276.                 but that doesn't help a virus, which must be able to survive
  277.                 on its own.
  278.  
  279.         - On a VMS system with properly set up security, the most a virus
  280.                 could do is spread from one user's infected files, to other
  281.                 files he owns.  If a user made an infected program available
  282.                 for others to run, anyone running the program could likewise
  283.                 see his files infected.  However, unless an infected program
  284.                 were run by a privileged user, the virus could never gain
  285.                 privileges this way.  A good security policy INSISTS that
  286.                 privileged users run ONLY trusted software - a Trojan Horse
  287.                 run by a privileged user is at least as much of a threat as
  288.                 a virus, in practice probably much more so.
  289.  
  290.                 One way to think about this is that on a properly run system,
  291.                 each individual non-privileged user account acts like its own
  292.                 private PC and disk.  Infections can spread within a PC/disk,
  293.                 but can only move from one to another by sharing.  A privi-
  294.                 leged user is someone who gathers up all the private disks
  295.                 and perhaps looks at them on his machine.  If he isn't care-
  296.                 ful, he can serve as a vector and spread a virus far and wide.
  297.  
  298.         - It is simple on a VMS system to configure an account for an end-
  299.                 user which does not allow the end-user to create new execu-
  300.                 tables, only run executables TO WHICH HE DOES NOT HAVE WRITE
  301.                 ACCESS.  Such an account is immune to viruses:  Even if one
  302.                 of those executables came to be infected, the virus in it
  303.                 couldn't spread, as it couldn't write to any other execut-
  304.                 ables.  (Yes, we can get into all sorts of theoretical
  305.                 discussions about what constitutes an "executable" if there
  306.                 are things like macros and interpreters around - but nothing
  307.                 of this sort has been observed "in the field" as far as I
  308.                 know.)
  309.  
  310.         - The "infections" that have been reported on VMS systems have usually
  311.                 been network-related, and were not viruses in any real sense.
  312.                 (They were self-propagating command files that relied on
  313.                 the fact that, in a more innocent time, VMS systems usually
  314.                 allowed remote users to run small programs in a default
  315.                 account.)
  316.  
  317. In summary:  If someone tries to sell you a VMS anti-viral package AT THIS
  318. TIME, you should probably tell them to take a hike.  Better, put them on the
  319. spot:  Don't let them tell you in general terms what their package does,
  320. insist that they tell you IN DETAIL what risks they claim you face, what
  321. evidence they have that those risks are real, and how their product protects
  322. you from those risks in a way that the base system does not.
  323.  
  324.                                                         -- Jerry
  325.  
  326. ------------------------------
  327.  
  328. Date:    Sat, 09 Feb 91 16:06:46 -0500
  329. From:    jguo@cs.NYU.EDU (Jun Guo)
  330. Subject: New Leprosy signiture? (PC)
  331.  
  332. Hi,
  333.  
  334.    I downloaded the new signature file
  335. anonymous/pub/virus/pc/virus.new from beach.gal.utexas.edu. But then
  336. F-FCHK tell me Turbo Debugger 1.0 TD.OVL and Turbo C++ 1.0 TCLASSS.LIB
  337. was infected by Leprosy. Is the new signature appropreate?
  338.  
  339.     The new signature is:
  340. Leprosy     iHNjpjKmumoXO8rHxotuxiWmtHW5mK4bD51CMK4Em5tnCG
  341.  
  342.    When I use F-DISINF, it reported possible unknown virus infection.
  343. I use NEC MS-DOS 3.30 to get around the 32MB partition limit. But is
  344. there really some virus? The dump of the boot by F-BOOT:
  345.  
  346. F-BOOT    Shows the boot sector    Version 1.14A - Jan. '91
  347.  
  348. eb34 904e 4543 4953 332e 3300 0402 0100 0200 0219 aaf8
  349. 2b00 1100 0700 1100 0000 0000 0000 0004 0000 0000 0000
  350. 0000 0012 0000 0000 0100 fa33 c08e d0bc 007c 1607 bb78
  351. 0036 c537 1e56 1653 bf2b 7cb9 0b00 fcac 2680 3d00 7403
  352. 268a 05aa 8ac4 e2f1 061f 8947 02c7 072b 7cfb 8a16 fd7d
  353. cd13 7303 e980 00f6 0624 7c20 7405 c606 9004 54a0 107c
  354. 98f7 2616 7c03 060e 7ca3 3f7c a337 7cb8 2000 f726 117c
  355. 8b1e 0b7c 03c3 48f7 f303 0637 7ca3 3d7c e8cb 00a3 377c
  356. a13f 7ce8 c200 a33f 7cbb 0005 a13f 7ce8 7300 b001 e888
  357. 0072 198b fbb9 0b00 bee0 7df3 a675 0d8d 7f20 beeb 7db9
  358. 0b00 f3a6 7418 be87 7de8 4000 32e4 cd16 5e1f 8f04 8f44
  359. 02cd 19be cf7d ebeb b902 00bb 0007 a137 7ce8 2f00 b001
  360. e844 0072 e8ff 0637 7c81 c300 02e2 e98a 2e15 7c8a 16fd
  361. 7d8b 1e3d 7cea 0000 7000 ac0a c074 21b4 0eb3 ffcd 10eb
  362. f333 d2f7 3618 7cfe c288 163b 7c33 d2f7 361a 7c88 162a
  363. 7ca3 397c c351 b402 8b16 397c 0316 1e7c 8aea d0ce d0ce
  364. 80e6 c08a 0e3b 7c80 e13f 0ace 8a36 2a7c 8a16 fd7d cd13
  365. 59c3 8b16 0b7c b109 d3ea f7e2 0306 1c7c c30d 0a4e 6f6e
  366. 2d53 7973 7465 6d20 6469 736b 206f 7220 6469 736b 2065
  367. 7272 6f72 0d0a 5265 706c 6163 6520 616e 6420 7072 6573
  368. 7320 616e 7920 6b65 7920 7768 656e 2072 6561 6479 0d0a
  369. 000d 0a42 6f6f 7420 4661 696c 7572 650d 0a00 494f 2020
  370. 2020 2020 5359 534d 5344 4f53 2020 2053 5953 0000 0000
  371. 0000 0080 55aa
  372.  
  373.    And when I use F-SYSCHK, the process slows down considerably when
  374. it gets to Lehigh. Before that one, I can hardly tell which virus is
  375. currently checking on, but begin from Lehigh, it is much slower. Is
  376. that normal? Or does that suggest some problem?
  377.  
  378.    Thanks a lot.
  379.  
  380. Jun
  381.  
  382. ------------------------------
  383.  
  384. Date:    10 Feb 91 13:27:35 +0000
  385. From:    frisk@rhi.hi.is (Fridrik Skulason)
  386. Subject: Re: Virus questions (PC)
  387.  
  388. Roggie Boone wrote:
  389.  
  390. >I have 4 questions regarding computer viruses.
  391.  
  392. >1)  I have seen the SCAN software (MaAffee) scan a computer's memory for
  393. >    viruses and noticed that it only scanned the base 640K of RAM.  Do
  394. >    viruses typically not infect or use extended/expanded memory?
  395.  
  396. There are no viruses which use or infect extended/expanded memory.  A
  397. virus could theoretically place a part of itself there, but it would
  398. also have to change something in tke lowest 640K, in order to load and
  399. execute this code.
  400.  
  401. There is one virus, however, which locates itself between 640K and 1Meg.
  402.  
  403. >    Are there virus scanning packages that will scan the additional memory?
  404.  
  405. No - there is no need to do so (yet).
  406.  
  407. >    I raise this question, because it seems I read somewhere that some
  408. >    computers with certain memory management drivers may not erase the
  409. >    contents of extended memory on a warm boot, and hence may not erase any
  410. >    virus that may be sitting in extended memory. (My memory isn't too good
  411. >    on this topic).
  412.  
  413. So what?  The virus code would be "dead", as it could never be activated.
  414. Just having it in memory will not do any harm whatsoever, as it is not active.
  415.  
  416. >2)  Are there anti-virus packages (for PC or any computer) that use
  417. >    artificial intelligence techniques to protect the system, or is such
  418. >    an effort overkill?
  419.  
  420. Several packages claim to use AI methods - none do.  The closest thing to AI
  421. in anti-virus products are the sets of rules some packages use to search
  422. for previously unknown viruses.
  423.  
  424. >3)  Not meaning to plant ideas, but I was talking with a facutly member
  425. >    in the dept. where I work, and the question arose as to whether a virus
  426. >    could be transmitted to an orbiting satellite and cause the same havoc
  427. >    that viruses cause us PC users.  Is this possible?
  428.  
  429. A Trojan, yes - it could be sent to the satellite, just as any other
  430. software "update". A virus ?  Well, why bother making the program
  431. replicate inside the satellite, when a simple Trojan will do the job ?
  432.  
  433. >4)  I have also noticed that SCAN, for instance, scans basically the .EXE,
  434. >    .COM, .SYS, .OVL files in a directory.  Do viruses not infect .TXT or
  435. >    .DOC files or maybe C (Pascal, Basic) source code?
  436.  
  437. Known viruses may either:
  438.  
  439.                 infect EXE and/or COM files. (unconfirmed reports of
  440.                 SYS-infecting viruses)  The one or two BAT viruses are
  441.                 not a serious threat.
  442. or
  443.                 Infect any file which is loaded/executed by INT 21/4B.
  444.                 That is, programs and overlays.
  445.  
  446. The latter group typically includes COM/EXE/APP/OVL/OVR/OV1/BIN and a
  447. few other extensions. A file which cannot be executed/ loaded as
  448. overlay cannot be infected.
  449.  
  450. A virus could infect source or object code, but no such viruses exist.
  451. DOC and TXT files cannot be infected.
  452.  
  453. ------------------------------
  454.  
  455. Date:    10 Feb 91 13:35:47 +0000
  456. From:    frisk@rhi.hi.is (Fridrik Skulason)
  457. Subject: Re: Alameda/Yale (PC)
  458.  
  459. Michael_Kessler.Hum@mailgate.bitnet writes:
  460. >But when asked to clean the boot sector, I received that message that the
  461. >virus could not be removed, no boot sector was found.  Copying the files to
  462. >a new disk and reformatting the disks solved the problem. But is there any
  463. >explanation for finding the virus in an infected boot sector that then
  464. >cannot be found?
  465.  
  466. The diskettes are infected, all right - the problem is just that the
  467. original boot sector, (which is normally stored on track 39) cannot be
  468. found.
  469.  
  470. This could be because the diskettes did not contain a valid boot
  471. sector when they were infected - the disinfector could remove the
  472. virus, but when it attempts to locate a valid boot sector to replace
  473. it with, it fails.
  474.  
  475. Another possibility is that the diskettes were infected by a new
  476. variant of the virus, (which stores the boot sector elsewhere) but
  477. this cannot be determined as the diskettes were (unfortunately)
  478. formatted.
  479.  
  480. - -frisk
  481.  
  482. Fridrik Skulason      University of Iceland  |
  483. Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
  484. E-Mail: frisk@rhi.hi.is    Fax: 354-1-28801  |
  485.  
  486. ------------------------------
  487.  
  488. End of VIRUS-L Digest [Volume 4 Issue 25]
  489. *****************************************
  490.  
  491.  
  492.  
  493.  
  494.