VIRUS-L Digest Wednesday, 25 Apr 1990 Volume 3 : Issue 81 Today's Topics: Re: Writeable Executables ( in AS/400, /38 ) Re: Writeable Executables Re: Exposure in Formatter (VM/CMS) re: PCs v. Mainframes Virus information sought Stoned Virus and Clean-Up (PC) New Programs from McAfee (PC) Re: Writeable Executables WDEF-A on Current-Contents-on-Diskette (Mac) Re: Exposure in Formatter (IBM VM/CMS) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: 24 Apr 90 14:26:44 +0000 From: Reinhard Kirchner Subject: Re: Writeable Executables ( in AS/400, /38 ) WHMurray@DOCKMASTER.NCSC.MIL writes: > The original argument as to wether executables was between Howard Aiken > Indeed, the only widely used systems that I am aware of that do not > permit this are the IBM S/3X and AS/400. That they do not is a well > kept secret, even in IBM. The mechanisms required to enforce this, and > other data-type rules, include hiding all physical storage from the user > and application, as well as a fully qualified program name that includes > the version. > > While I have always championed Aiken, and, with Ihnat, am quick to The secret is not so big if there is a little understanding of the mechanisms in the AS/400-:) At first, there are no files on a AS/400, but merely objects in a very large storage ( addresslength is 48 bit, expandable to 64 ). To gain access to an object one needs a 'capability' with sufficient rights for this object. Executable objects are not accessible at all, only executable. I don't know how this is made exactly, but perhaps the compiler throws the write-capability away after compiling -;) The AS/400 executables are also not using a known instruction set, but an internal 'micro'-instruction set which is not known and which may change from modell to modell. Compilers generate an immediate code, which is published ( till now only for the /38 ), but extremely hard to understand ( I tried and failed -:( ), and this is then by a machine- instruction translated to the executable object. There are megabytes of microcode in a AS/400. In its protection mechanisms the AS/400 is shurely the most advanced machine ever sold, perhaps even built. The AS/400 seems to be an enhanced System /38 ( intermediate binaries of the /38 can be used on the AS/400 ), and, as far as I know, the /38 was an outcome of the 'Future System', which should be the successor of the /370, but was never announced because people would have bought Amdahls /370 insteed. The /36 is a outdated 16-Bit machine and has nothing in common with the /38 ( except '/3' ) ( oh, both use the same terminals etc ). R. Kirchner University of Kaiserslautern Dept. of Computer Science kirchner@informatik.uni-kl.de ------------------------------ Date: Mon, 23 Apr 90 21:14:00 -0400 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Re: Writeable Executables >But nowhere do you mention who was on what side. Could you do an >explainitory post? Sorry. I had not intended to be cryptic. I will be happy to elaborate. Howard Aiken was the director of MIT's computing laboratory, which now bears his name. John von Neumann was a Princeton physicist, for whom the von Neumann architecture is named. Von Neumann's most important contribution to computing was the observation that if one stored procedures and data in the same memory, then one could do arithmetic on the program. One would also be able to put off the allocation of storage across the two uses until the very last moment. Given the incredible cost of storage in the forties, that was seen by most as a truly brilliant concept. This concept, called stored program computing, was probably the single most important idea in the evolution of the modern computer. It was the idea, that more than any other, distinguished the computers of the fiftys from the calculating machines of the fortys. It gave the computer a significant economic boost. It also sewed the seeds for the modern virus. Aiken resisted the idea, partly because of the potential for the program to be corrupted, but also likely because he failed to think of it himself. Aiken's machines, like most others of his day, put data in one kind of storage and procedure in another. For example, data might be in "counters" or vacuum tube rings, where it could be easily modified, and procedure in punched paper or a control panel, on the assumption that it did not need to be modified. It seems strange now, but this organization persisted into the early sixties. For example, the IBM 305 RAMAC, one of the first two computers to employ disk storage, used the disk exclusively for data, and not for programs. The idea of storage allocated to program and more or less resistant to modification has never really died out. It persists in ROM BIOS, for example. The Toshiba 1000 SE notebook-size and the ATARI and Poqet pocket-book-sized computers all ship their operating system in ROM. In the case of the Toshiba, the operating system is MS-DOS. Even the IBM PC1 had the BASIC interpreter in ROM. Of course, in these implementations this is done, in part, to compensate for the absence of disk drives, or to use cheap ROM to add value, rather than to make the programs resistant to change, but it is a value nonetheless. Note the speculation and hoaxes regarding using such specialized stores as places to store viruses. Hope this clarifies a little. It is hard for me to always remember that you were not all there. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: Tue, 24 Apr 90 12:36:00 -0400 From: Lynn R Grant Subject: Re: Exposure in Formatter (VM/CMS) To clarify my report of the .sy exposure in Waterloo Script... Waterloo Script is a different product from IBM Script (or DCF or whatever). It comes from University of Waterloo, through their marketing arm, which I believe is called WATCOM. Waterloo Script takes almost the same input tags as IBM Script; they are close enough that if you are comfortable with one you will be comfortable with the other, but just enough different that a file that works with one probably won't quite work on the other. I couldn't find anything in the Waterloo doc about an option to suppress .sy tags, so I looked in the source. Sure enough, there is a SYON/SYOFF execution time parm. I has the less safe but also less disruptive default of SYON. Lynn Grant Consultant Computer Associates International, Inc. Chicago, Illinois DOCKMASTER.NCSC.MIL) ------------------------------ Date: 23 Apr 90 00:00:00 -0500 From: "David.M.Chess" Subject: re: PCs v. Mainframes Interesting discussion whilst I was on vacation! I'll reply to various notes at once (apologies if I get longwinded...). Bill Murray is certainly correct that I may not have listed all, or even the most important, cultural factors that have led to there being so many more viruses for small computers than for large ones. My main point is that cultural factors rather than technical ones (patterns of usage rather than the existence of security features, for example) are the correct explanation. I'd be very interested in any hard evidence that anyone has as to the relative importance of machine sharing, software sharing, and media sharing in the spread of viruses; lacking that, it's mainly just personal intuition. Arthur Gutowski says that systems programming is simply harder on mainframes than it is on micros (quite possibly true, although I think the fact that the knowledge is less widespread is more important than the possible fact that it's harder), and that security systems would get in the way. I rather disagree with the latter, of course: viruses don't have to get around security systems to spread; they spread by writing to objects that they are authorized to write to. (More details below.) Dave Ihnat says that any time one program has write access to another, there's an error in the way the system is set up: > Yes, that's an error. I can think of no case whatsoever that *requires* > any program to write to another *program* as a matter of course in the > day-to-day execution of that program. In all cases, alternative methods > may be employed which permit the executables themselves to remain > inviolate. and challenges everyone to contribute counterexample scenarios. Here are a few candidates: - A user or system administrator installs a new program - A user or system administrator installs a new version of an existing program - A backup program makes a backup copy of an executable file - A linker produces a new version of an executable from source - A program is written to magnetic media for transport to another computer - A program is sent to another computer via a communications link - A copy program is used to copy or move a program file - A text-editor is used to make changes to source code in an interpreted language (or any other language, for that matter) and so on. Every time any one of these events happens, there's a chance for a virus to spread, unless the system is first brought into a state in which every piece of code along the relevant execution paths is "trusted". Getting the system into a trusted state is (to say the least) non-trivial in every real live system that I know of! I agree that programs very rarely, or even never, have to be self-altering; but many programs by their very nature have to be other-altering (how would you like a copy utility that didn't work on anything but pure text files (and even that wouldn't do it)?). I'm very interested in "Iceman"s comments about targetted mainframe viruses. Do you have any concrete information that you can share with us, or is your statement based on confidential information, or personal intuition? As Bruce, Peter, and Ben (I think it was!) all pointed out, there have in fact been viruses and virus-like things in mainframe systems. Fred Cohen's "Computer Viruses; Theory and Experiments" describes a number of experiments conducted on real live multiuser systems that showed that simple-to-write viruses, not exploiting any bugs in the security systems, could spread widely and rapidly on a system. Now of course it's possible to say that that just shows that there were errors in how the security was set up, but I don't think a definition of "error" that covers 99% of the systems in actual use in the real world is very useful; if virus-protection on a mainframe requires security disciplines that no one in fact uses, and that no one would find easy enough to implement to be cost-effective, that's little or no comfort. If we can define a security discipline that is both useable and very effective against viruses, that'd be very nice! But I haven't seen one yet... DC ------------------------------ Date: Tue, 24 Apr 90 09:42:55 +0700 From: Subject: Virus information sought Hello Virus Experts! We (a group of people here at the University of Duesseldorf) try to cope with several viral infections on our computers (PC). We had "some problems" with several viruses on our business machines and also on our private ones. Since this was the first time our systems were infected, we were really surprised and lost a lot of data. You can't imagine how fast the several viruses spread to all uninfected systems and destroyed everything they could get even without any network ... (It's every time the same story ...) Now we try to get our own experiences with the several viruses and how to cope with the infections. We have established an isolated system where we are doing our work. So we are looking for an overwiev of all known viruses (i.e. how they react and get visible, what damage is resulting, which interrupt vectors are hooked, are there programs which can destroy some viruses, etc...). I think it is better to be informed about possible viral infections on the systems and to have experience in destroying viruses than waiting for the next virus and having no tools against it. Many thanks to Prof. Klaus Brunnstein at the University of Hamburg (W. Germany) from where I got a first overview about the most common viruses. Never the less, if we can get more information, we are very happy. On our systems at the University we solved the problem of getting infected on our PC's (for the student users) by a little trick: We put two hard disks (really two physical, not logical drives) in the machines and changed the keyboard key lock in that way that it now controls the writing electricity cables of one hard disk so that no writing operation can be done on this (bootable) hard disk. On the other hard disk you can do your writing and reading operations for data as usual. (The other advantage of this system is that our software (campus licenses ...) now can't be modified by any unallowed person). There's one last notice: We are trying to get as much information as possible about the several viruses (for PC's only, not Amigas or other). You may send us your information (any type) via e-mail directly to JOEST@DD0RUD81.BITNET or to the adress below or to the list. But as everybody will understand, --- WE DO NOT SEND NOR EXCHANGE ANY VIRUSES --- because we want to solve problems caused by viral infections and not to help spreading those viruses (and resulting problems) around! Please accept it. Thanks. Well, that's enough (for the moment). Any comments or suggestions can be sent to this list or directly by e-mail to our address (JOEST@DD0RUD81.BITNET). Thanks to everybody who wants to help us. Yours, Stephan Joest. The address is: Stephan Joest, Universitaet Duesseldorf, Universitaetsstr.1/19312, D - 4000 Duesseldorf 1, West Germany for BITNET users: JOEST@DD0RUD81.BITNET ------------------------------ Date: Tue, 24 Apr 90 16:11:10 -0700 From: Alan_J_Roberts@cup.portal.com Subject: Stoned Virus and Clean-Up (PC) The Stoned virus is one of the more troublesome viruses to remove from a hard disk because it takes up residence in the hard disk's partition table. Even a DOS Format won't get rid of it. Clean-Up successfully removes this virus, but John McAfee has posted the following warning about its use on Homebase: "If the Stoned virus has infected any of the older hard disks that require a software device driver in order to access them, ala' Priam, then do not use the Clean-Up program without first backing up any data on the disk that you wouldn't be comfortable losing. Clean-Up will certainly kill the virus on such drives, but it may also kill the partition table. This is not good. And there is no easy fix. It's amazing how many Priam drives are still spinning out there after 8 years of heavy use. If you're unsure whether your disk uses a non-standard device driver, then please contact us at 408 988 3832 prior to using Clean-Up." So far fewer than one system in a thousand has this problem, but it's one system in a thousand too many. Alan ------------------------------ Date: Tue, 24 Apr 90 15:39:16 -0700 From: Alan_J_Roberts@cup.portal.com Subject: New Programs from McAfee (PC) The following is a forward from John McAfee: ================================================================== We have made two changes to the SCAN shareware product line that I hope will improve the virus protection capabilities and respond to the numerous change requests we have received from the user base. The first is a re-design of SCANRES and (please bear with us) a name change from SCANRES to VSHIELD. The new VSHIELD contains all of the functionality of SCANRES, plus it is now able to prevent all known boot sector and partition table infections as well as all known file infections. This capability was added because of the increasing prevalence of boot sector viruses such as Stoned, Ping Pong, etc. SCANRES was able to identify such infections immediately after they occurred, but could not prevent them. VSHIELD prevents such infections from occurring, providing of course that VSHIELD is in memory. Thus, soft re-boots (Ctrl-Alt- Del's) will no longer transfer a boot virus infection providing VSHIELD has been loaded. If the system is powered down before re- booting from a floppy, then VSHIELD is no longer running and the infection can occur. In this case, VSHIELD, like SCANRES, will flag the infection immediately upon the next boot-up from the hard disk. Other changes include error level settings identical to SCAN, a de-install function, and improved reporting when an infected file or diskette is blocked from entering the system. These changes have been requested by users for some time, and we regret the delay in implementing them. Beta testing by a few dozen fearless people has uncovered no false alarms or other system hindrances from VSHIELD. The second change is an added new program designed specifically for software manufacturers, developers and distributors to protect their software products prior to distribution. The program -- FSHIELD -- attaches a small module to existing executable code that will monitor for infection similar to innoculation programs, but in addition it automatically removes the virus and repairs the host program if the host program becomes infected. Files shielded in this fashion cannot contract or pass an infection and cannot be damaged by a virus attachment. The shield module detects and removes known and unknown viruses, including "stealth"-type viruses, and adds approximately 2K to the size of the host program. Both of these new programs are ShareWare. VSHIELD is currently available for download on HomeBase - 408 988 4004. FSHIELD will be available for download May 1. John McAfee ------------------------------ Date: Tue, 24 Apr 90 13:45:20 +0000 From: peter@ficc.uu.net (Peter da Silva) Subject: Re: Writeable Executables What's an executable? Oh, something that the computer executes. You don't want programs to be able to write into executable files. Sorry, it'll never happen. I'm sure, in fact, that given a little time I could infect your AS400 (or whatever), at least with a REXX script (or equivalent). Yep. Command scripts. A fertile breeding ground for viruses. And how about Postscript files? You want to turn off write permission on all your fonts? - -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. / \ 'U` Have you hugged your wolf today? \_.--._/ v Disclaimer: People have opinions, organisations have policy. ------------------------------ Date: Tue, 24 Apr 90 20:21:00 -0400 From: Subject: WDEF-A on Current-Contents-on-Diskette (Mac) Relative to the reported infection of Life Sciences Issue 16 of Volume 33 (April 16, 1990), I spoke yesterday with a technical representative of the Institute for Scientific Information (ISI). They were profusely apologetic, and indicated that they found out that yes, indeed, this issue was infected with WDEF-A. They said that they would soon be notifying all recipients of this issue and sending them a replacement disk as well as Disinfectant 1.6 to decontaminate infected systems. However, as of today (April 24), I have not yet received these materials, nor have I received any notification at all from ISI that my Mac may be infected. I did receive issue 17 today, and it is clean (per Gatekeeper and Disinfectant 1.7). So, if you subscribe to CC-on-diskette for the Macintosh, please be advised that Issue 16 may be infected with WDEF-A. Mike Tyo TYO@MITWCCF (BITNET) ------------------------------ Date: Tue, 24 Apr 90 22:27:02 -0400 From: Doug Sewell Subject: Re: Exposure in Formatter (IBM VM/CMS) WHMurray@DOCKMASTER.NCSC.MIL says: >I cannot tell from the comment whether the reference is to a WATERLOO >formatter or a Waterloo implementation of the IBM formatter. If the >latter, then this may simply be a case of the installation changing >the setting to the "non-disruptive" setting. If the former, there >may be no control, or the user may simply be seeing an installation >setting. We've had Waterloo script (which has its roots in RUNOFF, and is nearly source-compatible with IBM's) for years, and have reinstalled it at least four times (upgrades). To my recollection, there is no way to turn this 'feature' off at install time, and the short test I just ran (a 1-line .sy cp m * hello) did what I expected - sent me a message, so if it is settable, the default is 'ON' ): I can just see scripting a document for PD VM software with a '.sy cp shutdown' or '.sy erase * * a1' imbedded in it, and then explaining that I was only printing documentation. Is nothing sacred anymore ? Seriously, though, I have a new release tape waiting to be installed. I'll check and see whether this option is suppressable. If so, I'll turn it off in 'profile script', and if not I'll be calling Watcom. Waterloo Script is shipped with source (surprising, since Watcom's OCO products are date and cpuid protected), so I could fix it there, but I shouldn't have to. Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 E-mail: DOUG@YSUB.BITNET, DOUG@YSUB.YSU.EDU >> Don't test for an error condition that you don't know how to handle. ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253