VIRUS-L Digest Friday, 6 Jan 1989 Volume 2 : Issue 5 Today's Topics: Right to Purge Mail Re: Disks Drive protection -gimme a break re: copy protected disketts Getting Mac Anti-viral Files Clarificaton/More on the Father Christmas Worm (VAX/VMS) Brain and the boot sequence (PC) Re: creating government standards for software --------------------------------------------------------------------------- Date: Thu, 5 Jan 89 08:42 EST From: WHMurray@DOCKMASTER.ARPA Subject: Right to Purge Mail S. H. asks: "Which takes priority, the rights of the individuals receiving these virus files or the responsibility of systems managers for securing their systems against anwanted [sic] viri [sic]?" I think that the question, as stated, is loaded. Try "Is the responsibility of the system manager to ensure that the majority of the population receives the majority of its mail superior to his responsibility to see that an individual receives a particular mailing?" William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Thu, 5 Jan 1989 08:55:01 EDT From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> Subject: Re: Disks Drive protection -gimme a break >From: >I would like to suggest the formation of another list... >... Readers: What do you think? Not much. Personally, I *much* prefer having information available quickly from a centralized location, not spread over Gxx-knows-how-many separate lists. >- -David Richardson ******************************************************************************* * A CONFIDENTIAL COMMUNICATION FROM THE VIRTUAL DESK OF: * ******************************************************************************* ............................................................................... |W. K. "Bill" Gorman "Do Foust Hall # 5 | |PROFS System Administrator SOMETHING, Computer Services | |Central Michigan University even if it's Mt. Pleasant, MI 48858 | |34AEJ7D@CMUVM.BITNET wrong!" (517) 774-3183 | |_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_| |Disclaimer: These opinions are guaranteed against defects in materials and | |workmanship for a period not to exceed transmission time. | |.............................................................................| ------------------------------ Date: Thu, 05 Jan 89 12:32:40 CST From: DON STRUBE Subject: re: copy protected disketts I joined this list last week and have tried to come up-to-speed on the conversations on this list by reading old digests. I agree that the copy protection thing has been beat to death and there still seems to be a difference of opinion among the 'experts' writting to this list. Since everything changes so fast in the world of computing I am sure the correct response today will be incorrect next week anyway so lets drop it and move forward. ------------------------------ Date: Thu, 05 Jan 89 17:02:04 EST From: Joe McMahon Subject: Getting Mac Anti-viral Files Would the person who sent me mail asking about the anti-virals here at SCFVM please send me another message? Your message was misaddressed, and forwarded to me by the postmaster without a reply-to field. Thanks. To all who are not concerned, sorry. - --- Joe M. ------------------------------ Date: 5-JAN-1989 19:38:09.58 From: Subject: Clarificaton/More on the Father Christmas Worm (VAX/VMS) Comments: BSMTP envelope created by ENVELOPE.COM version T1.0 Greetings, What I found disturbing about the recent outbreak of "Father Christmas" worm (a.k.a. HI.COM) was that some of the techniques used in the "Internet worm" were duplicated in HI.COM. One point where HI.COM looked like the "Internet worm" was causing the source program to "disappear". This was accomplished by copying the entire program into a DCL symbol array and then deleting the disk copy of the program. The program continued to execute since it had been loaded and running already, and when it wanted to propagate to another node it just dumped the symbol array. The result was that you could not observe (by using SHOW DEVICE/FILES) what the command procedure was even though it was executing. This made getting a copy of the procedure and deciphering it difficult. A second "lookalike" feature is that it moved through the network very rapidly, and thus attracted attention quickly. Infection attempts were hitting my machine on the order of 3 or 4 tries every 5 minutes. We run a homebrew network alarm package called NETINFO which told us the type of attempt, and where it was coming from. After the 8th file transfer attempt in as many minutes I got curious and started looking. If the program hadn't been so voracious, it might not have had attracted so much attention on the beginning of a holiday weekend. Anyhow, I am a new subscriber to VIRUS-L and I saw a few bits and pieces in the digest (8901A) that ought to be "fleshed out". Networks affected by the worm: Any DECnet network directly connected to SPAN (The NASA Space Physics Analysis Network) or HEPnet (DOE - High Energy Physics Network) was subject to infection. I have not heard of any infections in THEnet, CCnet or Easynet at this time. The method of transmission was by DECnet on VMS systems only. The process name used by the worm was "MAIL_178DC". This was intended to disguise the worm as a DECnet mail delivery process. However, the worm did not connect to another DECnet mail delivery process on a remote node. Instead it connected to FAL, which is the file transfer process. This information is available from the command MCR NCP SHOW KNOWN LINKS and is one way to distinguish the worm from a real MAIL transfer process. The short term fix that was proposed here at NASA/GSFC was to disable the DECnet object that runs command procedures on remote nodes. This object is known as TASK or Object number 0. Currently, it appears that the best long term fix without seriously limiting DECnet functionality is to use a separate FAL (File transfer) account. A model FAL account can be found in the VAX/VMS Guide To System Security. Another proposed improvement would be to stop using the default account/password of DECNET/DECNET for network default-access accounts. Finally, the worm needed to run AUTHORIZE, which is system utility that users (both local and remote) should be prevented from using. Brian Lev who provided some of the information in the messages from Steve Goldstein (goldstein@nsipo.nasa.gov) works for the Advanced Data Flow Technology Office (Not CSDR) at NASA/Goddard Space Flight Center. He can be contacted at LEV@DFTBIT.BITNET or LEV@DFTNIC.GSFC.NASA.GOV. His counterpart at CSDR who snagged the copy of the worm posted to VIRUS-L was me (John McMahon), I can be contacted at FASTEDDY@DFTBIT.BITNET or FASTEDDY@DFTNIC.GSFC.NASA.GOV. Since I will be giving a talk on the "Father Christmas" worm on Friday the 13th (ominous, isn't it), I would be interested in any information on it that hasn't already been shipped through VIRUS-L. I am especially interested in any proposed fixes that haven't been mentioned, and also details on how widespread the worm was. Thank you very much, and Happy New Year! John "Fast-Eddie" McMahon ST Systems Corporation Advanced Data Flow Technology Office - Code 630.4 Formerly COBE Science Data Room - Code 401.1 NASA Goddard Space Flight Center, Greenbelt, Maryland 20771 Bitnet: FASTEDDY@DFTBIT (old: FASTEDDY@IAFBIT) Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV Span: SDCDCL::FASTEDDY (Node 6.9) ------------------------------ Date: Thu, 5 Jan 89 22:43 EST From: Dimitri Vulis Subject: Brain and the boot sequence (PC) There seems to be some confusion concerning which part of boot logic lives in ROM BIOS and which in the boot record (aka IPL record). Indeed, the boot sequence (aka IPL sequence) is non-trivial on a PC. Here's the story (valid for most IBM compatible BIOSes): When the machine is reset (turned on, ctl-alt-del pressed, reset pin tweaked, etc), the control passes to certain model-dependent ROM BIOS routine that tests and resets various attachments (serial ports, parallel ports, video card, etc); resets all interrupt vectors to ROM routines; and also scans memory space for other valid ROMs, and if they are found, calls an initialization procedure in each such ROM (following a convention). Finally, it invokes INT 19. (Note that INT 19 can only be invoked safely if you are certain that all interrupts point to ROM. Don't issue it after you load some OS code that redirects _any_ vector. This interrupt is for BIOS use only.) Now, if your machine has ROM on a hard disk controller, or a network adapter, then it would intercept INT 19, and I'll deal with this shortly. Similarly, if you have an EGA adapter, its ROM intercepts INT 10 (video), etc. Suppose now, you are booting a plain vanilla PC, with no hard disk or network card, from a floppy; this is the configuration most susceptible to a boot sector virus. (On an IBM PC, the code for such vanilla INT 19 routine is on page 5-49.) _All_the_code_does_is issue INT 13 to read in a single sector from the A-disk (sector 1, track 0, side 0) into memory location 0:7C00 and jump there. If it fails after a few re-tries (e.g. no disk in drive A:) it goes into cassette BASIC. Compatibles with no BASIC in ROM behave differently; some try ad infinitum, some halt. NOTE: the message `Non-system disk' does not originate here yet! I'll refer to the code just read as the `OS boot record'. If you have a separate hard disk ROM (this is slightly different on `newer' machines, where hard disk BIOS is part of the `regular' BIOS), it intercepts INT 19 (as well as INT 13 to interpret hard disk calls), and when it's finally issued, it first tries to read from the floppy (just like vanilla) and if that fails, it tries to read a `BIOS boot record' from the hard disk (sector 1, track 0, head 0). If that too fails (and it should not) it halts, or goes to BASIC, as above; if it succeeds, it jumps to the BIOS boot record. The latter contains the so-called `partition table', useful if you want to share the disk between DOS and Unix, say, as well as some executable code to interpret the table, find the `active' partition, read the OS boot record from the first sector of that partition into 0:7c00 and jump there. (This sector, by the way, is an ideal place for a worm, and I've seen bad ones there.) If you have a network adopter, then INT 19 does a `remote boot' and the OS boot sector is read from a different machine on the network. We will ignore this case, since the remote device is hopefully read-only and no virus can spread that way. So, we've reached the stage when the OS boot sector is in memory at 0:7C00 and we start executing it. _If_ the boot record is the vanilla MS/PC-DOS boot record, then the code does the following (trivially speaking): it read in the beginning of the directory and checks that the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS and MSDOS.SYS (for generic MS-DOS). If they are not, it displays (via INT 10) the message: `Non-system disk or disk error, replace, strike any key when ready', waits for a keystroke and does INT 19 again. Of course, it's trivial to replace this message by anything you like, including a German one, and ROM BIOS has nothing to do with this. If these files are there, it reads (using INT 13) the first one (DOS low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS. The reason for all the arithmetic is that the boot record is the same on different devices, so some logic is needed to compute the position of IBMBIO.COM and the directory using the BPB table, also contained in the boot record, that gives the number of sectors per track, etc. (INT 13 is pretty low-level, that's why this logic is needed.) There are two ways the OS boot record normally gets (over)written: by FORMAT command, and by SYS command. That's why many (commercial) distribution (floppy) disks come with a boot record that does not even check for IBMDOS.COM, but says immediately something like `This is XYZ software, if you want to make this disk bootable, use the SYS command, now insert your DOS disk and strike any key.' This is a valid thing to do, because if you SYS'd, the original boot record would be replaced by the DOS one. Suppose now that you are booting from a Brain-infected disk (not necessarily having IBMBIO.COM and IBMDOS.COM!). (The following description is approximate and may vary with version.) The very first thing the `shoe record' does is read in the additional sectors, masked as `bad sectors' (since all this logic would not fit in a single sector) into high memory. and jumps there. It then decrements the word in low memory that's set by the BIOS diagnostics routine to the amount of RAM available to DOS, so DOS won't attempt to touch that memory. It intercepts INT 13 (disk access) and replaces it by a code that infects floppies whenever they are accessed via INT 13. (`Infecting' involves marking sectors as bad in FAT, and writing a copy of the virus code from high memory to those sectors, as well as to the boot sector.) _But_ this only works with the (most common) 5.25" DS/DD disks, not enough logic is there to handle other formats. Only after that it passes the control to the original boot sector code. The latter attempts to find IBMBIO.COM and if it fails, it displays a message and waits for a keystroke, as above. But INT 13 is intercepted now! So, if you insert a bare (sans tab) DOS disk into A: and press _any_ key, INT 19 will not change any interrupts, and will attempt to read the boot sector via INT 13, infecting the new disk in the process. (Here INT 19 does not halt the machine because DOS does not know about the piece of RAM where the virus code is, so it does not overwrite it.) If, however, you press ctl-alt-del, then the BIOS will go through the whole diagnostics again and reset the vectors, disabling the virus. (Virus code still sits in high RAM, but it never gains control, and is overwritten by DOS shortly.) To summarise, a failed boot from a non-bootable Brain-infected disk will load the virus into memory and the machine will infect other disks until the machine is properly reset. - ----------------------------------------------------------------------------- Also: after I've delivered the final kick to the write-protect issue, I got a long, rude, obnoxious, illiterate flame from one person whose postings I quoted. Most of that trash is not worth quoting, but he makes one valid point: >(Hence the confusion, since I happen to beleive in the authanticity of >messeges posted in the disgest). Fascinating. An ignorant (not necessarily stupid) person makes a statement that makes no sense. A stupid and ignorant person (quoted above) picks it up, takes it seriously, and bothers his systems people. This digest is highly authoritative; with this authority comes responsibility. (I've said this before, so I should stop here.) - -Dimitri [Ed. I agree with your comments about the digest and all. One problem, though, who should be the one(s) to verify the authenticity of messages sent to the digest? Should I? That would become a full-time job in itself, and I already have a full-time job which takes up more than enough of my time. Do we have any volunteers? I feel that the best solution is to ask people submitting messages to try to verify their own messages within reason, and for readers to be able to reply to messages that they feel are incorrect. After all, isn't that one of the reasons for having a _discussion_ forum? Comments and/or suggestions anyone? I'm *very* open to suggestions here.] ------------------------------ Date: Thu, 5 Jan 89 21:58 EST From: "Joseph M. Beckman" Subject: Re: creating government standards for software I must second WHM's comments on the inadvisability of creating government standards for software. If anyone believes this is a good thing, please forward me the consensus view of the community of what those standards should be. Anyway, I think the more traditional way the "government" may play in these matters is thru judicial actions against the manufacturers. Personally, I am all for private citizen's using their ability to influence the market thru their actions (refusing to buy manufacturer "x"'s software) to promote such "standards." Joseph ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253