home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.10 < prev    next >
Text File  |  1995-01-03  |  13KB  |  272 lines

  1. VIRUS-L Digest            Wednesday, 11 Jan 1989        Volume 2 : Issue 10
  2.  
  3. Today's Topics:
  4. oops, editorial typo
  5. "False Sense of Security"
  6. PC Boot sequencez
  7. Boot sequence (PC)
  8. Request for information
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date: Tue, 10 Jan 89 16:47:37 est
  13. From: ubu!luken@lehi3b15.csee.lehigh.edu
  14. Subject: oops, editorial typo
  15.  
  16. From my own editorial comment:
  17. > I suppose the appropriate caveat here is that we have to take *any*
  18. > report of a virus until it can be verified.
  19.  
  20. Oops, saw this just as the digest was leaving my screen for the
  21. LISTSERV...  That was *supposed* to say that we have to take any
  22. report of a virus with a grain of salt until it can be verified.
  23.                   ^^^^^^^^^^^^^^^^^^^^
  24. The point being - don't trust a virus report until you've gotten
  25. verification from a reputable source.  E-mail, in general, may not be
  26. a reputable source.  It's important to follow up a virus report via
  27. some other form of media, like a phonecall to the author of the
  28. report.
  29.  
  30. Apologies for the typo, I got a bit carried away with the editor...
  31.  
  32. Ken
  33.  
  34. ------------------------------
  35.  
  36. Date:  Tue, 10 Jan 89 21:41 EST
  37. From:  WHMurray@DOCKMASTER.ARPA
  38. Subject:  "False Sense of Security"
  39.  
  40. Y. Radai writes:
  41.  
  42. >  I don't agree that such programs provide very little protection.  I
  43. >think that the viruses (and worms and Trojans) against which they do
  44. >afford protection (they may be "amateurish" but they're not
  45. >necessarily benign!) are still in the majority (at least among those
  46. >viruses which have become widespread).  And I think that it is well
  47. >worth protecting oneself against them, even if more sophisticated
  48. >viruses exist as well and will become more prevalent in the future.
  49.  
  50. I think that another useful distinction can be made here.  I suggest
  51. that such software, to the extent that it makes the machine on which
  52. it exists different from the population at large, goes a long way to
  53. making that machine immune to viruses.  It is less effective in
  54. protecting it against Trojan Horse attacks which are specifically
  55. aimed at it.
  56.  
  57. Viruses exploit the similarities among systems.  Its success is
  58. independent of its ability to infect any particular machine.  Indeed
  59. it is naive to anticipate viruses that can account for any and all
  60. arbitrary differences among machines.  To quote a famous hacker "why
  61. would anyone do that?"
  62.  
  63. One of the problems with viruses is that they can be successful even
  64. in a population in which many of the targets are partially, or even
  65. totally, immune.  (Note that the Internet Worm was extremely
  66. successful, and very disruptive, in a population in which the majority
  67. of the machines were not suited to it.  It was also disruptive to
  68. machines in which it could not execute.  It interfered with their
  69. normal traffic and it sent them attack traffic.  Nonetheless, the
  70. vulnerability to viruses arises, in part, because there exists a large
  71. population of similar machines.  In a world in which no two machines
  72. had any predictable similarity, then, while we might still have Trojan
  73. Horses, we would have no viruses.
  74.  
  75. [Flame on.]
  76.  
  77. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
  78. 2000 National City Center Cleveland, Ohio 44114
  79. 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
  80.  
  81. ------------------------------
  82.  
  83. Date:         Tue, 10 Jan 1989 22:01 CST
  84. From:         John Ladwig <JLADWIG@UMINN1.BITNET>
  85. Subject:      PC Boot sequence
  86.  
  87. An anecdote regarding messages returned when booting non-system
  88. diskettes.
  89.  
  90. In "Brain and the boot sequence (PC)" (VIRUS-L v2 #5), Dimitri
  91. Vulis writes:
  92.  
  93. [The boot process...]
  94. > reads in the beginning of the directory and checks that
  95. > the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS
  96. > and MSDOS.SYS (for generic MS-DOS). If they are not, it displays (via
  97. > INT 10) the message: `Non-system disk or disk error, replace, strike
  98. > any key when ready', waits for a keystroke and does INT 19 again. Of
  99. > course, it's trivial to replace this message by anything you like,
  100. > including a German one, and ROM BIOS has nothing to do with this.
  101.  
  102. Diskettes formatted using the SideKick Plus 'File Manager'
  103. display the following message if the are booted without being
  104. SYSed:
  105.  
  106.        Hand crafted by the SideKick Plus File Manager
  107.  
  108.        Gavaskar, Bradman, Grace, Compton, Richards, Khan,
  109.        Knott, Hadlee, Trueman, Lillee, and Holding.
  110.  
  111.        Remove the disk from the drive and press any key
  112.        to restart the system.
  113.  
  114. The text is found in the boot sector, starting at offset 52 (decimal).
  115. The text "SKDOS1.0" appears at offset 4.
  116.  
  117. I must say that I was a bit surprised when I discovered this by
  118. accident.  (Goes to show that you should read the manual thoroughly
  119. :-))
  120.  
  121. ------------------------------
  122.  
  123. Date:     Wed, 11 Jan 89 01:05 EST
  124. From:     Dimitri Vulis <DLV@CUNYVMS1.BITNET>
  125. Subject:  Boot sequence (PC)
  126.  
  127. (Please excuse the long quotes)
  128.  
  129. >  The other point:  In V2 #5, Dimitri wrote:
  130. >>       ... it reads in the beginning of the directory and checks that
  131. >>and MSDOS.SYS (for generic MS-DOS). ....
  132. >>If these files are there, it reads (using INT 13) the first one (DOS
  133. >>low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually
  134. >>at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS.
  135. >  The clause "it reads ... the first one [i.e. IBMBIO.COM or IO.SYS]
  136. >into memory" is not quite accurate.  It seems that what actually
  137. >happens is that the disk bootstrap routine loads a certain number of
  138. >sectors, starting from the beginning of the data area, into RAM, under
  139. >the *assumption* that these contain IBMBIO.COM/IO.SYS.  Depending on
  140. >the implementation, it may also do the same with the following sectors
  141. >on the assumption that they contain IBMDOS.COM/MSDOS.SYS, or else the
  142. >former program may load the latter.  But if the disk has been tampered
  143. >with, it is not necessarily these two files which will get loaded.
  144. >                                           Y. Radai
  145.  
  146. I stand by what I said. The SYS command does a lot of elaborate
  147. checking to make sure that IBMBIO.COM fits contigiously into the first
  148. data sectors on disk. FORMAT/S just writes the file into the first
  149. data sectors. The boot code has to make certain assumptions---there's
  150. not enough room for the logic to read the FAT and compute the
  151. sector/track for each cluster to simulate a file call.  So, it assumes
  152. that if the disk has IBMBIO.COM and IBMDOS.COM as the first files in
  153. the directory, (and finding that takes room too) and if they are
  154. hidden/system, then the code assumes that the disk is OK and
  155. IBMBIO.COM is indeed in the first data sectors. It computes the
  156. sector/track for these sectors and (ordinarily) reads in the file
  157. using INT 13 (note the wording).  Certainly, one can mess around with
  158. a disk and create one that won't boot, because IBMBIO.SYS is not at
  159. the beginnig. This would require some (a little) conscious effort and
  160. cannot easily be done with just FORMAT/S or SYS. I was describing a
  161. successful boot, in which the file is read into memory.
  162.  
  163. Regarding the other point (Trojan-protection software):
  164.  
  165. That's a matter of opinion. FSP 1.4 is the only such program that I'm
  166. familiar with that is marginally acceptable to me. The previous
  167. versions of it did more harm than good. Most other programs of this
  168. type (that intersept INT 13 and report suspicious activity) are
  169. useless. What good is a program that indiscriminately reports _every_
  170. disk access? It is unconscienable(sp?) that some crooks charge money
  171. for such programs and use cheap scare tactics to induce dumb ignorant
  172. people to pay for them. By the way, I don't even use FSP 1.4, and
  173. here's the reason: some time ago (years) I called Ross Greenberg's
  174. BBS, and there was a message from him saying that over 50% of uploads
  175. to his board turn out to be Trojans. I'm not implying that the guy is
  176. unstable, but I'd rather see the source code for a program that
  177. intercepts disk access and can potentially do very nasty things
  178. (remember NOTROJ?).
  179.  
  180. Also, by the way, last semester I wrote a short (COM file) virus for
  181. my cryptography class that _infected_ FSP 1.4.
  182.  
  183. >  The only argument which Dimitri gives for his statement is that one
  184. >might be lulled into using less discretion in deciding what to run on
  185. >his machine.  Now I would understand this argument in a situation
  186. >where anti-viral software is sold to naive customers under the false
  187. >pretense that it will prevent all types of infection.  But are we so
  188. >naive?  To give the impression, as Dimitri does, that it is worse to
  189. >use such software than not to use it, is certainly not correct in
  190. >general.  He doesn't explain just what his notion of discretion
  191. >consists of, but whatever it may be, why can't we use *both*
  192. >anti-viral software *and* discretion ....??
  193.  
  194. What do I mean by discretion? Well, I don't download software from
  195. BBS's anymore (too bad), I back up everything I've done at the end of
  196. the day (have been for many years), and I don't have stuff (executable
  197. and other) online that I don't need. I don't happen to use a
  198. floppy-based machine, but if I did, I'd make sure I reboot from a
  199. write-protected floppy I can trust.
  200.  
  201. If you look at the ads in US computer magazines, that's exactly what's
  202. said/implied: 1) _everyone_ needs such programs, 2) they offer 100%
  203. protection.  I'm willing to believe that Israeli users are smarter
  204. than American users. In this country even complete idiots (pardon my
  205. French) use PCs---just read some of the recent messages in this very
  206. digest. When you place a very stupid and ignorant individual in front
  207. of a PC without giving him/her adequate instruction, you open a
  208. Pandora's box of problems, one of which is this Virus/Trojan thing.
  209. How many of your users can say whether this is true or false (for an
  210. IBM PC; Mac is something else yet):
  211.  
  212. (1) Virus software can override write-protect tabs
  213.  
  214. (2) Viruses can spread via e-mail messages
  215.  
  216. (3) Viruses are the most common type of Trojan horse programs
  217.  
  218. (4) A virus can spread from a PC to VAX or VM and vice versa
  219.  
  220. Such a misinformed individual will typically pay some gonef $$$ for a
  221. piece of code that TSRs and checks for INT 13 functions `write',
  222. `format', `format fancy', `format fancy with twist', etc, without
  223. analysing where they came from; it will produce too much output and
  224. s/he will habitually turn it off; nevertheless, s/he will feel fully
  225. protected and will promiscuously load all kinds of suspect software
  226. and will never take a backup. (We have, by the way, a gay fellow, a
  227. good mathematician, who does not believe that AIDS is caused by a
  228. virus, or, for that matter, is spread sexually; and he's still alive!)
  229.  
  230. ------------------------------
  231.  
  232. Date:    Wed, 11 Jan 89 02:32:12 EST
  233. From: <Xc60039@PORTLAND.BITNET> (Douglas Howell)
  234. Subject: Request for information
  235.  
  236.   Hello.  I am wondering if any of you might be able to help
  237. me.  I'm doing a study on viruses and would like to get any
  238. information available on them.  Particularly I would like to
  239. ask anyone who has a virus which has been disected with
  240. accompaning documentation to send it to me. I am new to this
  241. list so I have not had much time to read through past issues
  242. yet.  I shall do that when classes resume.
  243.     Could anyone explain to me how to construct a virus.
  244. Just the basics will do nicely.  I'll gladly accept any
  245. information that is sent to me no matter it's length.  I'll
  246. also be needing information on how to deactivate the
  247. 'common' virus.
  248.     I realize that this is a lot to ask, but I'm hoping that
  249. many of you will respond and help me out.
  250. I wish to state right here and now that I am not requesting a
  251. living or active virus or trojan horse.  This is my third
  252. revision and yet the clarity of my request still remains in
  253. question.  I relize the severity of what I ask for, and for
  254. all intensions I see no harm in it.  Please contact me directly
  255. if there are any questions.
  256.  
  257.                     Douglas Howell
  258.                     (xc60039@Portland)
  259.  
  260. [Ed. Doug has revised this message a few times, and each time I sent
  261. it back because he was requesting a copy of a virus; something which I
  262. will not promote here on VIRUS-L.  I believe that it is a bad idea to
  263. send copies of viruses to others, particularly when requested only via
  264. e-mail.  I trust that anyone responding to such a request will
  265. exercise due caution.]
  266.  
  267. ------------------------------
  268.  
  269. End of VIRUS-L Digest
  270. *********************
  271. Downloaded From P-80 International Information Systems 304-744-2253
  272.