risks@CSL.SRI.COM (RISKS Forum) (11/26/89)
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.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>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 <MAINT@UQAM.bitnet>
Subject: Write protect tabs (from Craig Finseth in VIRUS-L)
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1.bitnet>
From: "The Moderator Kenneth R. van Wyk" <krvw@SEI.CMU.EDU>
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" <fin%uf.msc.umn.edu@vma.cc.cmu.edu>
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" <Smee@bristol.ac.uk>
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 <brunnstein@rz.informatik.uni-hamburg.dbp.de>
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 <ecd@cert.sei.cmu.edu>
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
************************