home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.83 < prev    next >
Text File  |  1995-01-03  |  23KB  |  506 lines
  1.  
  2. VIRUS-L Digest   Monday, 30 Apr 1990    Volume 3 : Issue 83
  3.  
  4. Today's Topics:
  5.  
  6. re: Write-access to Executables
  7. re: *really* fail-safe virus protection?
  8. Re: New Virus? (PC)
  9. re: *really* fail-safe virus protection
  10. RE: Virus protection for OS in ROM
  11. Mainframe viruses
  12. Re: Possible virus? (Mac)
  13. New files to MIBSRV (PC)
  14. virus-l reply
  15. Public Domain/Shareware Anti-Virus Tools for IBM PC
  16. Re: Update to Memo on Computer Viruses in Commercial Products
  17. 1704 Version B (PC)
  18. Re: *really* fail-safe virus protection
  19.  
  20. VIRUS-L is a moderated, digested mail forum for discussing computer
  21. virus issues; comp.virus is a non-digested Usenet counterpart.
  22. Discussions are not limited to any one hardware/software platform -
  23. diversity is welcomed.  Contributions should be relevant, concise,
  24. polite, etc.  Please sign submissions with your real name.  Send
  25. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  26. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  27. anti-virus, documentation, and back-issue archives is distributed
  28. periodically on the list.  Administrative mail (comments, suggestions,
  29. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  30.  
  31.    Ken van Wyk
  32.  
  33. ---------------------------------------------------------------------------
  34.  
  35. Date:    27 Apr 90 00:00:00 -0500
  36. From:    "David.M.Chess" <CHESS@YKTVMV.BITNET>
  37. Subject: re: Write-access to Executables
  38.  
  39. "Pete Lucas" <PJML%ibma.nerc-wallingford.ac.uk@NSFnet-Relay.AC.UK>:
  40.  
  41. >                      It seems to me that *no* executables should be
  42. > 'writable' by *any* program under normal circumstances.!.!   ...
  43. > Now when you make a change to the source, you recompile and re-link,
  44. > and if you know what you are doing, *ERASE AND RECREATE* the executable
  45. > module.
  46.  
  47. Isn't the power to erase-and-recreate functionally the same as the
  48. power to alter?  If something has munged an executable by reading it
  49. in, erasing it, and re-creating it, the relevant consequences will
  50. be just the same as if it had directly patched it on disk, yesno?
  51. Are there operating systems that allow you to mark files as subject
  52. to erase-and-recreate, but not subject to zap-in-place?  (That's
  53. just a curiousity question; a virus can happily use either method.)
  54.  
  55. The power to erase-X-and-then-rename-Y-to-X is another functional
  56. equivalent to bytewise write access...
  57.  
  58. DC
  59.  
  60. ------------------------------
  61.  
  62. Date:    27 Apr 90 00:00:00 -0500
  63. From:    "David.M.Chess" <CHESS@YKTVMV.BITNET>
  64. Subject: re: *really* fail-safe virus protection?
  65.  
  66. hobbit@pyrite.rutgers.edu (*Hobbit*):
  67. > Finally someone else comes up with the *correct* solution! ...
  68. > Simply opening this line prevents any writes to the hard drive. ...
  69. > Comments upon how this scheme could fail for any *one-time* run of
  70. > infected software are solicited.
  71.  
  72. Well, a virus that infected the software while it was on someone
  73. else's machine could decide to go off (because of the date or
  74. whatever) and mess with your data files (which can't be readonly, in
  75. general?).  But it's quite true that a virus can't spread to your
  76. programs if they're all on a readonly medium whenever the virus has a
  77. chance to be in control.
  78.  
  79. Why are only one-time runs interesting, though?   Most software gets run
  80. more than once.   If you really do power down the machine before ever
  81. flipping the write-protect switch off, and only run utterly trusted
  82. software in that state, you're quite safe.   Utterly trusted software
  83. is hard to come by, though!   *8)   If a virus ever gets to run while
  84. the switch is off, or is ever still around in memory or whatever while
  85. the switch is off, you're no longer protected.   No amount of testing
  86. can reliably determine that a program deserves to be utterly trusted;
  87. viruses can spread as rarely as they like (the original carrier of the
  88. DataCrime had a month or so's delay before it started spreading).
  89.  
  90. This isn't to say that a write-prot switch for the hard disk is a
  91. bad idea; if I got along better with hardware, I'd put one in myself.
  92. But I'd suggest using it along with other anti-virus measures
  93. (scanners, modification detectors, backups, etc), and not relying on it
  94. exclusively.  I don't think it's *the* solution to the problem...
  95.  
  96. DC
  97.  
  98. P.S. The ultimate solution is of course John McAfee's "spackle".
  99.      But it's difficult to get much actual use out of a
  100.      properly-spackled computer, unless you have a door you want
  101.      held open...
  102.  
  103. ------------------------------
  104.  
  105. Date:    27 Apr 90 17:33:09 +0000
  106. From:    medici@elbereth.rutgers.edu (Mark Medici)
  107. Subject: Re: New Virus? (PC)
  108.  
  109. Did anyone think of checking for a batch file called 123.BAT on this
  110. system?  Or looking around on the disk with Norton Utilities (or some
  111. such) to try and locate the file that contained some of the text that
  112. was displayed.
  113.  
  114. This sounds more like a the type of non-damaging pranks I've played
  115. (and have had played on me) than a a virus/worm/Trojan-horse.
  116. Unfortunately, since the disk was wiped, we will probably never know.
  117.  
  118. - ----------------------------------------------------------------------------
  119. Mark Medici/SysProg3 * Rutgers University/CCIS * medici@elbereth.rutgers.edu
  120. - ----------------------------------------------------------------------------
  121.  
  122. ------------------------------
  123.  
  124. Date:    Fri, 27 Apr 90 10:45:10 -0700
  125. From:    teda!RATVAX.DNET!ROBERTS@decwrl.dec.com (George Roberts)
  126. Subject: re: *really* fail-safe virus protection
  127.  
  128. > I.e. the write gate.  This is an active-low line from the controller to
  129. > the hard drive which when disabled "floats" high.  Simply opening this
  130. > line prevents any writes to the hard drive.  I believe it's pin 6 of the
  131.  
  132. WARNING!  Although TTL logic floats high when open, it can (and often
  133. will) go low for a few microseconds (due to cross talk on the chip?).
  134. I've been burned a few times when I thought some signal would float
  135. high. I highly recommend that you use a pullup resistor to +5V (if you
  136. don't already have one).  The value of the resistor would depend on
  137. the drive strength of the chip on the other side of the switch.  5000
  138. ohms will work for most cases: chips with an IOL MIN of 1 mA or more.
  139.  
  140. I would hate to see the write signal go low even for just a micro second
  141. when the head is over some random part of my disk!  It may only happen
  142. on rare occasions, such as when someone turns on a heavy appliance on
  143. the same circuit.  It may only affect 1 bit (or none).
  144.  
  145.                                        - George Roberts
  146.                                        ...teda!ratvax.dnet!roberts
  147.  
  148. ------------------------------
  149.  
  150. Date:    Fri, 27 Apr 90 16:27:39 -0400
  151. From:    Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET>
  152. Subject: RE: Virus protection for OS in ROM
  153.  
  154. >With the entire OS in ROM, there is no
  155. >>longer a need for executable code the the partition/boot record
  156. >>...
  157. >What do you do for minor updates or patches, though? --a chip swap would
  158. >be frighteningto joe_user for every minor updgrade/bug fix though.  There
  159. >has been some talk in the past about moving the standard libraries and
  160. >handlers into ROM.  Maybe in 1.5 :)
  161.  
  162. >Stephen Okay
  163.  
  164. Well, back to my origional misconception about Amigas and using EPROMs.
  165. Even though they don't (yet), how much more of an undertaking, and how
  166. much would it boost the cost, to start incorporating EPROMs into future
  167. hardware for OS.  We have the technology, why not start using it?
  168.  
  169. EPROMs, with an external switch, Could enable you to install a new
  170. versions/updates/bug fixes without a major kinipshin by owners.  Again,
  171. this makes the assumption that the distribution diskettes are clean.
  172. Another limitation would be the amount of writes you were able to do
  173. before frying the EPROM chip; I dont know hardware that well, so I have
  174. no idea what a reasonable estimate would be.
  175.  
  176. Amiga appears to have its act together more than most PC/compatibles and
  177. Macs in that at least the low-level boot is done in ROM.  Hopefully they
  178. will implement standard libs/handlers in the same way.  What about interrupt
  179. vectors too?  I dont personally see any reason for modifying standard OS
  180. interrupts (except with version updates); reserved/user programmable vectors,
  181. if needed, can still be implemented the old way. Hmmmmmmmmmm
  182.  
  183. Art
  184. -
  185.  -==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==
  186. \c-
  187.   /=====\   Arthur J. Gutowski, System Programmer
  188.  :  o o  :  MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center
  189.  :       :  5925 Woodward; Detroit MI  48202; PH#: (313) 577-0718
  190.  : ----- :  Bitnet: AGUTOWS@WAYNEST1   Internet: AGUTOWS@WAYNEST1.BITNET
  191.   \=====/     Disclaimer:  I think, therefore I am...(maybe).
  192.  Have a day.
  193.  
  194. ------------------------------
  195.  
  196. Date:    Fri, 27 Apr 90 16:44:46 -0400
  197. From:    Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET>
  198. Subject: Mainframe viruses
  199.  
  200. David Chess:
  201. >...viruses don't have to get around security systems to spread; they
  202. >spread by writing to objects that they are authorized to write to.
  203.  
  204. Let me restate my point:  properly implemented and audited security
  205. systems tend to *restrict* the spread of viruses.  I'll concede that
  206. security systems alone don't do the trick; you have to have people
  207. who use the mainframe system educated on how to protect themselves
  208. from being tromped on by others.  This, of course, does not prevent
  209. them from stepping on themselves, but if they cannot write to another
  210. persons (or the systems) object libraries, he cannot spread the virus
  211. to someone else, can he?  Mainframes use something that most pc-type
  212. architectures dont--protected memory.
  213.  
  214. When a task enters the system under MVS or VM, the OS sets up an
  215. address space bounded in memory for that task (batch job, TSO user,
  216. etc.)  That address space cannot be modified by other address spaces
  217. nor can it modify other address spaces (except for normal operator
  218. commands like display, cancel, etc).  Forget security subsystems for
  219. the moment, this is supported solely by the OS.  Under this type of
  220. system, there is *no way* for a normal address space, regardless of
  221. whether he is a "super-user", security id, or whatever, to even
  222. address outside of his own address space.  The system maintains a set
  223. of page tables, and all of your addressable storage is maintained
  224. through these tables.  They can only be modified through the system.
  225. If you need more memory, the system grabs more (if available), and
  226. sets up another pagetable entry for you.  When your task terminates,
  227. the system deletes all of your entries, and returns all your memory to
  228. the free memory pool.  None of this can be accessed directly by the
  229. user, period.  There is no way for viral code to get control of system
  230. functions in this way.  Now there are some special utilities out there
  231. that run under the OS that allow you to view or modify global storage
  232. areas, but these should be (and are at our installation) monitored for
  233. such activity.  The only other way to introduce viral code into the
  234. system is to have system programmer abilities and access to make
  235. changes to the system load libraries.  Not an easy task.  Now, as Dave
  236. and others have pointed out, this type of knowledge is limited
  237. comparative to PCs, and the casual hacker is discouraged from such
  238. targets.  Those that do have the ability and would be using it for
  239. dastardly ends, once caught would find themselves without the second
  240. necessary element--access.
  241.  
  242. With regard to file copying, copy utility programs aren't
  243. other-modifying in the sense that I get from your posting, Dave.  As
  244. far as a copy utility is concerned, all you're copying is pure text.
  245. A copy program don't know the difference between data and object, it
  246. just copies bytes from file1 to file2.  When invoked, it makes a call
  247. to the system to allocate file2, then it writes.  When it's done, both
  248. files are closed, and the program terminates.  Now on a PC,
  249. object/data distinctions are easy (*.COM, *.EXE vs. *.DAT, *.DBF).  On
  250. MVS and the like, that distinction doesn't exist.  The only time the
  251. system knows the difference between the two is when it's told to
  252. EXECute a file.  If it's not object or macro or script langauage,
  253. you'll know almost immediately.  VM is different from MVS in that the
  254. MODULE and EXEC filetypes still exist to make things easy for you.
  255. Now, you could copy a program that contains a virus to another file,
  256. but again, whether you you infect someone else in this manner depends
  257. on what accesses are granted through your security subsystem.
  258.  
  259. Again, mail viruses are a different story altogether.  And I agree
  260. with the many recent postings about script viruses being a "fertile
  261. breeding ground".  But whether that breeding ground exists beyond the
  262. single user is dependent on the file sharing (e.g., through mailings)
  263. between users (a Christmas tree, neat, huh?) and accesses granted
  264. throughout the system.
  265.  
  266. >Intersting discussion whilst I was on vacation!
  267.  
  268. I agree, let's keep it going.
  269.  
  270.  Arthur J. Gutowski, System Programmer
  271.  MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center
  272.  5925 Woodward; Detroit MI  48202; PH#: (313) 577-0718
  273.  Bitnet: AGUTOWS@WAYNEST1   Internet: AGUTOWS@WAYNEST1.BITNET
  274.  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  275.  "He's learning to match the feat of the Old World Man
  276.   He's learning to catch the heat of the Third World Man
  277.   He's a New World Man"
  278.  
  279. ------------------------------
  280.  
  281. Date:    Fri, 27 Apr 90 22:10:56 -0400
  282. From:    Yary Richard Phillip Hluchan <yh0a+@andrew.cmu.edu>
  283. Subject: Re: Possible virus? (Mac)
  284.  
  285. I hope this answer doesn't insult your intelligence, but if you're
  286. using a system (or control panel) more than a year old you've got the
  287. problem.  There was one setting of the keyboard- fastest repeat rate,
  288. shortest delay until repeat, I think- that would take any keypress and
  289. repeat it for as long at is was held down.  That plus a sticky key
  290. could do it.
  291.  
  292. Course I could be wrong.
  293.  
  294. ------------------------------
  295.  
  296. Date:    Sat, 28 Apr 90 13:32:35 -0500
  297. From:    James Ford <JFORD1@UA1VM.BITNET>
  298. Subject: New files to MIBSRV (PC)
  299.  
  300. The following files have been downloaded directly from Homebase BBS on
  301. 4/27/90 at 8:00pm (April 27).  These file have not been re-zipped in any
  302. way, just downloaded, transfered to a floppy, and uploaded to the RT.
  303.  
  304. The files they replace will remain on the server for approximately one
  305. week, in case requests for them are pending at BITFTP@PUCC.
  306.  
  307.  
  308. At MIBSRV.MIB.ENG.UA.EDU (130.160.20.80) in pub/ibm-antivirus
  309. - ------------------------------------------------------------------------
  310. CLEANP62.ZIP   46990  CLEAN-UP V62 Virus removal program.     (04-25-90)
  311. SCANV62.ZIP    45680  VIRUSCAN System Scanner V62.            (04-25-90)
  312. VSHLD62.ZIP    33323  VSHIELD Infection Prevention TSR Prog.  (04-25-90)
  313. FSHLD12.ZIP    34693  FILE SHIELD - For Software Developers.  (04-27-90)
  314. NETSCN62.ZIP   34654  NETSCAN Network Version V62             (04-25-90)
  315. VSUM9004.ZIP   35857  Virus Information Summary Listing       (04-18-90)
  316.  
  317. - ----------
  318. The man who has accomplished all that he thinks worthwhile has begun to die.
  319. - ----------
  320. James Ford -  JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU
  321.               THE University of Alabama (in Tuscaloosa, Alabama  USA)
  322.  
  323. ------------------------------
  324.  
  325. Date:    Sat, 28 Apr 90 12:22:56 -0500
  326. From:    haley@sm-logdis1-aflc.af.mil (TSgt William Haley)
  327. Subject: virus-l reply
  328.  
  329. The new PC Virus that Don Kazem writes about in Vol 3 Issue 82 is a
  330. prank/panic/trick program that will put the message on then proceed to
  331. act as if it is formating all hard drives in the affected system.  To
  332. the best of my knowledge it does no harm to anything except the
  333. onwer's peace of mind and general condition of his/her heart for a
  334. brief period of time.  I have a copy of the program if anyone is
  335. interested in obtaining same.  Please contact me directly and not thru
  336. this list.  Below is Kazem's message less the screen shot:
  337.  
  338.  
  339. >From:    Don Kazem <DKAZEM@NAS.BITNET>
  340.  
  341. I received a call today from one of the local chain food stores about
  342. what could be a new virus. Since they have no connection to the
  343. network, I offered to post this.
  344.  
  345. A user was running Lotus (by invoking 123.exe), and after a file
  346. retrieve, the virus was triggered. The following message was
  347. displayed: (The spelling errors are the same as they appeared).
  348.  
  349. (edited out)
  350.  
  351. After a while, the words "JUST KIDDING" appeared, and everything went
  352. back to normal. Although, it appeared as though there was no damage,
  353. they ran Wipedisk, and installed everything from the original disks.
  354.  
  355. They ran SCAN61 both before and after reinstalling the software, and
  356. SCAN did not find anything.
  357.  
  358. The have a backup of the hard disk, before they ran Wipedisk, and are
  359. willing to forward copies of their executables to researchers (lawyers
  360. permitting).
  361.  
  362. Has anyone heard of this?
  363.  
  364. Don Kazem
  365. National Academy of Sciences
  366. DKAZEM@NAS.BITNET
  367. -
  368.  ------------------------------------------------------------------------------
  369. \c-
  370. W. Rusty Haley, TSgt, USAF           | This space reserved for future info.   |
  371. 2852 Security Police Squadron/SPPC   |                                        |
  372. McClellan AFB, Sacramento, CA. 95652 |                                        |
  373. INTERNET:haley@sm-logdis1-aflc.af.mil|                                        |
  374. USS:haley@smdis01.arpa               |                                        |
  375. ALLIN1: HALEY.RU                     |                                        |
  376. AUTOVON:633-5523 COMM:916-643-5523   |                                        |
  377. -
  378.  ------------------------------------------------------------------------------
  379. \c-
  380.  
  381. ------------------------------
  382.  
  383. Date:    30 Apr 90 01:13:47 +0000
  384. From:    jay@axiom.maths.uq.OZ.AU (Joseph Young)
  385. Subject: Public Domain/Shareware Anti-Virus Tools for IBM PC
  386.  
  387. I have a couple of questions about Public Domain or Shareware anti-
  388. virus software.
  389.  
  390. 1. I'm confused about the John McAfee product line ... is it share-
  391.    ware or not? As you can see, I'm from an Australian University and
  392.    we are interested in using SCANRES (/VSHIELD) on an institution-
  393.    wide basis.
  394.  
  395.    Information we have received from McAfee Associates,
  396.    suggests we need to buy a site/ corporate licence costing $5,925
  397.    (US) for say 500 copies (that's about $7,400 to us down under).
  398.  
  399.    A recent posting forwarded by Alan Roberts from John McAfee talks
  400.    about 'changes to the SCAN shareware product line'.
  401.  
  402.    So, do we need a SCANRES license or is it shareware, am I
  403.    talking about two sets of different products or is the price
  404.    above the actual shareware price or what? If we need a
  405.    license, are we talking a site license or corporate license for
  406.    a multi-campus educational institution?
  407.  
  408. 2. Are there any other public domain/ shareware products similar to
  409.    SCANRES/ VSHIELD we should look at?
  410.  
  411. 3. Finally, we're running Novell PC networks. What virus
  412.    protection software are people using in this area?
  413.  
  414.    Again, McAfee Associates have NETSCAN for $2,000 (flat fee)
  415.    according to their product listing. Can anyone help with more
  416.    information about this? Do you need to buy a copy of NETSCAN for
  417.    each network you want to protect?
  418.  
  419.    Are there any other anti-virus tools we should be looking at
  420.    for Novell PC networks?
  421.  
  422. Any information at all on any of the above would be greatly
  423. appreciated. If there is enough interest, I'd be only too happy
  424. to summarise for the net.
  425.  
  426. Joseph Young, Queensland, Australia.
  427. E-Mail: jay@axiom.maths.uq.oz.au
  428.  
  429. ------------------------------
  430.  
  431. Date:    30 Apr 90 03:33:19 +0000
  432. From:    woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal)
  433. Subject: Re: Update to Memo on Computer Viruses in Commercial Products
  434.  
  435. Gimme a break.  No wonder our fine government is so screwed up.  This
  436. is one of the worst cases that I have seen of complicating a written
  437. communication.  Simplify this stuff.  Certainly you can eleminate most
  438. of the jargon.
  439.  
  440. There have been reports of commercial packages infected with viruses.
  441. Below is a partial list of them.  There are legitimate uses and needs
  442. for public domain and shareware.  Should be Army start random spot
  443. checking for these?
  444.  
  445. The above 4 sentences are the gist of the message, and the entire
  446. message other than the list could be done in 1 clear paragraph, rather
  447. than "missions"...etc et.
  448.  
  449. Cheers
  450. Woody
  451.  
  452. ------------------------------
  453.  
  454. Date:    Mon, 30 Apr 90 09:53:57 -0500
  455. From:    Ghost <UZR50F@DBNRHRZ1.BITNET>
  456. Subject: 1704 Version B (PC)
  457.  
  458. Hi out there,
  459.  
  460. we found the 1704 virus version B at RHRZ Bonn, Germany. We got it
  461. from a person who learned SPSS PC+ in our pool. The infection software
  462. was MIPS.COM, a program what shows the speed of the computer. He give
  463. it to the course leader and he give it round in our computing center.
  464. Because of the age of the virus i didn't found any comments to it. The
  465. infection was 10 month ago, and we didn't know it. Some machines,
  466. where public domain software was tested, were clean. They are clean
  467. yet. I tried McAfee's CLEANP61 to kill the virus out of the software
  468. packages without destroying them, but the software didn't run. I
  469. think, i make an error, but i there is somebody else, whop know this
  470. problem, please describe it.
  471.  
  472. So long
  473.  
  474. Thomas Friedrich
  475. RHRZ Bonn, Germany
  476. (UZR50F@DBNRHRZ1.BITNET)
  477.  
  478. ------------------------------
  479.  
  480. Date:    30 Apr 90 10:15:43 +0000
  481. From:    berg@cip-s01.informatik.rwth-aachen.de (Solitair)
  482. Subject: Re: *really* fail-safe virus protection
  483.  
  484. hobbit@pyrite.rutgers.edu (*Hobbit*) writes:
  485. >   ... changed the keyboard key lock in that way that it now
  486. >   controls the writing electricity cables of one hard disk so that no
  487. >   writing operation can be done on this (bootable) hard disk.
  488. ...
  489. >If you install a switch, the
  490. >extra wiring should probably be made as short as possible to avoid timing
  491. >problems.
  492.  
  493. Well, actually the wire needn't be so very short for a ST506 cable.
  494. The specs say the total cable length may be 3m (=10 ft), and you don't
  495. have to worry about EMI (electro magnetic interference) because the
  496. actual write gate signal doesn't carry such high frequencies.
  497. - --
  498. Sincerely,                         | berg@cip-s01.informatik.rwth-aachen.de
  499.            Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg
  500.  
  501. ------------------------------
  502.  
  503. End of VIRUS-L Digest
  504. *********************
  505. Downloaded From P-80 International Information Systems 304-744-2253
  506.