RISKS-LIST: RISKS-FORUM Digest Saturday 25 November 1989 Volume 9 : Issue 48 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Check inquiry / binary search (anonymous) Re: Training programmers (Paul J. Mech) Telephone Overload (Jon von Zelowitz) Write protect tabs (via Peter Jones from Craig Finseth in VIRUS-L) High error rates (P.E.Smee) Policy vs. the Enabling Technology (Bill Murray) Computer Virus Catalog Index: November' 89 (Klaus Brunnstein) CERT_Tools_Announcement (Edward DeHart) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: Sat, 25 Nov 89 13:05:00 [x]ST From: "anonymous" Subject: Check inquiry / binary search (Mauney, RISKS-9.47) Jon Mauney's story about using check inquiries to determine the balance in an account rang a familiar bell. My mother once managed several apartment complexes. One month a deadbeat tenant gave her a $250 check which bounced. When the check was returned, my mother used the same method described by Mauney to determine that the account had a balance of $220. She then went to the bank, deposited $30 cash in the deadbeat's account, and cashed the $250 check. I've always wondered what the deadbeat's reaction was when he discovered what happened. ------------------------------ Date: 25 Nov 89 05:36:08 GMT From: paul@oucsace.UUCP Subject: Re: Training programmers (Ridgway, RISKS-9.47) A friend of mine, in part inspired by my sucess as a programmer, decided to enroll in a two quarter "Computer Programmer" course of study at a Columbus, OH, trade school. After a week, she had learned how to turn on an IBM PC clone without it exploding or chasing people around the room. By the end of the fourth week she had "learned Lotus." They then proceeded to the complexities of BASIC. In just a few short weeks, she "learned BASIC." She couldn't describe any but the simplest of algorithms and had no means of attack for simple programming problems, but she could tell me all the "command words" in the language. She dropped out before they got to the crowning achievement of the program, DBASE III. All through this time I was incredulous. These people expected to be programmers. They were told that "starting salery for some programmers is $35/hr." Yet they weren't even addressing fundemental algorithms, common approaches to problem solving, or anything more than a Jr. High level "Here is a word problem. Now solve it." I approached an instructor/administrator at the school with some of my reservations and was told that they were being taught "enough to get out into the workplace." What amazed me even more was that my knowledge of "real programming" far exceeded his, even though my schoolwork was in Physics, not CS. No, I would not hire a graduate of such a program. Neither it seems would much of Columbus. We had subsequent contact with four of the graduates of the program. Only one had been employed in "computer programming" within four months of graduation. He had worked for a week on a problem that was entirely too advanced for him, and been allowed to resign gracefully. (Two were working as cashiers, the fourth unemployed.) Paul J. Mech ------------------------------ Date: Fri, 24 Nov 89 15:19:21 PST From: vonzelow@adobe.com (Jon von Zelowitz) Subject: Telephone Overload I discovered that MCI (my default long-distance company) was having a bad day when I tried to call my folks on Thanksgiving afternoon. I tried four times in a row, and each time, instead of being connected (or getting a "sorry" recording), I was patched into other peoples' conversations. What a failure mode! After satisfying myself that MCI had a bug, I selected ATT (10288+number) and made my call. But most telephone users probably don't know how to do that (despite ATT's best efforts); in the US we have become accustomed to phones always working right. (I am not an employee or stockholder of MCI or ATT. MCI usually works fine.) ...sun!adobe!vonzelow vonzelow@adobe.com Jon von Zelowitz ------------------------------ Date: Fri, 17 Nov 89 15:46:28 EST From: Peter Jones Subject: Write protect tabs (from Craig Finseth in VIRUS-L) Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Subject: VIRUS-L Digest V2 #243 The following appeared in VIRUS-L digest. I think it definitely closes the question about circumventing write-protect tabs. I've underlined the important text. Peter Jones MAINT@UQAM (514)-987-3542 "Life's too short to try and fill up every minute of it" :-) ----------------------------Original message---------------------------- Date: Fri, 17 Nov 89 09:51:38 -0600 From: "Craig Finseth" Subject: Write protect tabs (was Re: CRC's) kichler@harris.cis.ksu.edu (Charles Kichler) writes: ... Do you _know_ your write-protect tab really works? [Ed. This question was discussed a few times on VIRUS-L/comp.virus; the consensus was (after reviewing schematic diagrams) that the write protect mechanism on PCs (and clones thereof) and Macs is implemented in hardware and is thus not circumventable without hardware modifications. Unless someone can produce a definitive, reproducable piece of code that can prove otherwise, lets all please consider this to be the case.] I would like to confirm the "Ed." tack-on for IBM PCs, clones, and Macs. However, early Apple ][s *did* implement this feature in software. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I don't know for sure, but believe that later (=current) Apple ][s, Ataris, and Amigas perform this function in hardware. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 ------------------------------ Date: Fri, 17 Nov 89 11:36:27 GMT From: "P.E.Smee" Subject: High error rates (RISKS-9.41) David desJardins mentions a set of figures I've heard before, to wit ... look at neutron-activation bomb detectors, to be installed in airports. They are said to have something like a 3% false positive rate. ... Let's say that it [rate of bags with bombs to bags without] is 1 in 30 million ... That corresponds to 1 million false positives for every true positive. *That* is a high rate of error. And our society has chosen to spend nearly a billion dollars on that system. I'd question whether a system with such a high rate of error will help, or whether it might not actually make things worse. If the operator knows (or works out from experience, as they certainly will even if they are not told) that out of every million bags which the system says need looked at by the bomb squad, only one actually contains anything suspicious, then it must be painfully tempting to say 'well, I'm in a hurry today, can probably let just this one through'. And of course since this will usually be 'right' in the sense that nothing untoward will happen, it will tend to be self-reinforcing carelessness. I can see where such a system might create a false sense of security based on 'gosh, new technology that can detect any form of explosive' while in fact increasing the chances of non-detection owing to the 'boy who cried wolf' syndrome. In short, while more research is almost certainly worthwhile, I don't believe that putting this system into service in its present state of development could be considered a responsible act. Probably win votes, though. Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!uunet!ukc!gdr.bath.ac.uk!exspes ------------------------------ Date: Mon, 20 Nov 89 22:32 EST From: WHMurray.Catwalk@DOCKMASTER.NCSC.MIL Subject: Policy vs. the Enabling Technology (Randall Davis, RISKS-9.45) >Right, and then we should discuss the POLICY, not the technology >that made it worth discussing. [...] Most of us seem to understand this intuitively; nonetheless, we consent to have the debate on the technology, rather than the policy. We continue this not at our peril, but at the risk of an orderly society. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: 21 Nov 89 17:37 GMT+0100 From: Klaus Brunnstein Subject: Computer Virus Catalog Index: November '89 The Computer Virus Catalog now classifies 45 viruses (AMIGA:24;MSDOS:15; Atari:6). Activities are undertaken to make the documents available via servers in different regions of the world; we hope that we can announce such servers in the next weeks. If you wish to receive the documents (see Index appended, with length of the documents given) sooner, please send a short request to the author. Klaus Brunnstein ======================================================================== == Computer Virus Catalog Index == ======================================================================== == Status: November 15, 1989 (Format 1.2) == == Classified: 15 MSDOS-Viruses (MSDOSVIR.A89) == == 24 AMIGA-Viruses (AMIGAVIR.A89) == == 6 Atari-Viruses (ATARIVIR.A89) == == Updates since last edition (July 31, 1989) marked: U (column 70)=U= == Additions since last edition (July 31, 1989) marked: + (column 70)=+= ======================================================================== == Document MSDOSVIR.A89 contains the classifications of the == == following viruses (1.138 Lines, 6.271 Words, 62 kBytes): == == == == 1) Autumn Leaves=Herbst="1704"=Cascade A Virus == == 2) "1701" = Cascade B = Autumn Leaves B = Herbst B Virus == == 3) Bouncing Ball = Italian = Ping Pong= Turin Virus =U= == 4) "Friday 13th" = South African Virus =+= == 5) GhostBalls Virus =+= == 6) Icelandic#1 = Disk Crunching = One-in-Ten Virus =U= == 7) Icelandic#2 Virus =+= == 8) Israeli = Jerusalem A Virus =U= == 9) MachoSoft Virus =+= == 10) Merritt = Alameda A = Yale Virus == == 11) Oropax = Music Virus == == 12) Saratoga Virus =+= == 13) SHOE-B v9.0 Virus == == 14) VACSINA Virus =+= == 15) Vienna = Austrian = "648" Virus =U= == == == Remark: The following 13 MS-DOS-Viruses are presently being classi-== == fied and will be published in the next edition (December 31,1989): == == .) Brain A = Pakistani A-Virus (Pakistani Virus Strain) == == .) Datacrime I = 1168 Virus (Datacrime Virus Strain) == == .) Datacrime II = 1280 Virus (Datacrime Virus Strain) == == .) Den Zuk Virus (Venezuela/Search Virus Strain) == == .) Lehigh Virus == == .) FuManchu Virus (Israeli Virus Strain) == == .) NewZeeland= Marijuana= Stoned Virus (NewZealand Virus Strain) == == .) Pentagon Virus == == .) SURIV 1.01,2.01,3.00 Viruses (Israeli Virus Strain) == == .) Traceback Virus == == .) 405 Virus == ======================================================================== == Document AMIGAVIR.A89 contains the classifications of the == == following 24 viruses (2.272 Lines, 9.421 Words, 106 kBytes): == == == == 1) AEK-Virus = Micro-Master Virus (SCA Virus Strain) =U= == 2) BGS 9-Virus =+= == 3) Byte Bandit Virus =U= == 4) Byte Bandit Plus Virus (Byte Bandit Virus Strain) =+= == 5) Byte Warrior#1 Virus = DASA-Virus (Byte Warrior Strain) =U= == 6) Disk Doctors Virus =U= == 7) Gaddafi-Virus =U= == 8) Gyros Virus =U= == 9) IRQ-Virus =U= == 10) LAMER (Exterminator) Virus =U= == 11) LSD Virus (SCA Virus Strain) =+= == 12) NORTH STAR I Antivirus-Virus (NORTH STAR Virus Strain) =U= == 13) NORTH STAR II Antivirus-Virus (NORTH STAR Virus Strain) =U= == 14) Obelisk Virus =U= == 15) Paramount Virus = Byte Warrior#2 Virus (Byte Warrior Strain) =U= == 16) Pentagon Antivirus-Virus =+= == 17) Revenge 1.2G Virus =+= == 18) SCA-Virus =U= == 19) System Z 3.0 Antivirus-Virus (System Z Virus Strain) =U= == 20) System Z 4.0 Antivirus-Virus (System Z Virus Strain) =U= == 21) System Z 5.0 Antivirus-Virus (System Z Virus Strain) =+= == 22) Timebomb 1.0 Virus =+= == 23) VKill 1.0 Virus = Camouflage Virus =U= == 24) WAFT-Virus =+= == == == Remark: the following 8 AMIGA-viruses are presently analysed, clas-= == sified and will be published in the next edition (12/31/1989): == == .) BUTONIC 1.1 Virus == == .) JOSHUA Virus == == .) LAMER EXTERMINATOR Virus 1.0, 2.0, 3.0 == == .) SYSTEM Z 5.1, 5.3 Virus == == .) WARHAWK Virus == ======================================================================== == Document ATARIVIR.A89 contains the classifications of the == == following 6 viruses (375 Lines, 2.045 Words, 21 kBytes): == == == == 1) ANTHRAX = Milzbrand Virus =+= == 2) c't Virus == == 3) Emil 1A Virus = "Virus 1A" == == 4) Emil 2A Virus = "Virus 2A" = mad Virus == == 5) Mouse (Inverter) Virus =U= == 6) Zimmermann-Virus == == == == Since last edition, ANTHRAX V. has been added. We have problems to == == get viruses, as many users wish to exchange their viruses (like == == stamps) against our's, which we generally refuse: the Virus Test == == Center's ethical standard says, that we do not spread viruses! == == Please send infected programs without preconditions. == ======================================================================== == For essential updates (marked "U="), we wish to thank D.Ferbrache,== == Y.Radai and F.Skulason for their continued help and support. == == Critical and constructive comments as well as additions are == == appreciated. Especially, descriptions of recently detected viruses = == will be of general interest. To receive the Virus Catalog Format, == == containing entry descriptions, please contact the above address. == ======================================================================== ======================================================================== == The Computer Virus Catalog may be copied free of charges provided == == that the source is properly mentioned at any time and location == == of reference. == ======================================================================== == Editor: Virus Test Center, Faculty for Informatics == == University of Hamburg == == Schlueterstr. 70, D2000 Hamburg 13, FR Germany == == Prof. Dr. Klaus Brunnstein, Simone Fischer-Huebner == == Tel: (040) 4123-4158 (KB), -4715 (SFH), -4162(Secr.) == == Email (EAN/BITNET): Brunnstein@RZ.Informatik.Uni-Hamburg.dbp.de == ======================================================================== == This document: 117 Lines, 701 Words, 9 kBytes == ======================================================================== ------------------------------ Date: Fri, 17 Nov 89 23:10:52 EST From: Edward DeHart Subject: CERT_Tools_Announcement The Computer Emergency Response Team Coordination Center (CERT/CC) has established a new Internet mailing list named CERT-TOOLS. The purpose of this new mailing list is to encourage the exchange of information on security tools and security techniques. The list should not be used for security problem reports. The CERT/CC has found that many sites have developed tools and techniques to improve the security of their systems (e.g. tools to assist users' selection of passwords that are difficult to guess, account management techniques, monitors that help detect unauthorized system access). Also, several tool developers have expressed an interest in sharing their work with others. We hope this mailing list will spawn new security tool development and allow individual sites to take advantage of existing work. The mailing list will not be moderated and the CERT/CC will not formally review, evaluate, or endorse the tools and techniques described. The decision to use the tools and techniques described is the responsibility of each user or organization and we encourage each organization to thoroughly evaluate new tools and techniques before installation or use. Membership is restricted to system programmers, system administrators and others with a legitimate interest in the development of computer security tools. If you would like to be considered for inclusion, please send mail to: cert-tools-request@cert.sei.cmu.edu You will receive confirmation mail when you have been placed on the list. We ask that the mailing list not be used for file transfers. If you have a tool or technique that you would like to share, please mail a description of the tool or technique to the mailing list and describe how others can acquire the tool or obtain additional information. The CERT/CC is planning to collect many of the tools and will make the archive available via anonymous ftp on the cert.sei.cmu.edu system. All mail intended to be redistributed should be mailed to: cert-tools@cert.sei.cmu.edu Please feel free to inform other colleagues interested in security tools and security techniques about this list. Also, please send comments, criticisms, and suggetions on this or any other CERT/CC activity to: cert@cert.sei.cmu.edu Thank you, Ed DeHart, Computer Emergency Response Team Email: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (answers 24 hours a day) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Affiliation: __________________________________________________________ Name (last, first, MI): _________________________ __________________ _ Title: ___________________________________________ Address:___________________________ Phone Numbers: ___________________________________ Work: ___/______________ ___________________________________ Home: ___/______________ FAX: ___/______________ City: ____________________________ Pager:___/______________ State: __ Zip: _____-____ Computer Room: Country:______________________ ___/______________ Email Address: ______________________________ Supervisor's Name: __________________________ Phone Number: Return form via email to cert-tools-request@cert.sei.cmu.edu ------------------------------ End of RISKS-FORUM Digest 9.48 ************************