University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from:

Previous Issue Index Next Issue Info Searching Submit Article

The Risks Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16, Issue 9

Weds 25 May 1994

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator


o Call Your OPERATER!
Martin Minow
o Bank goof creates millionaire
Andy Fuller
o Two risk-related articles from Edupage 5/24/94
Terry Alford
o Dell monitors too hot to handle
Mich Kabay
o Canada, The Internet, and the Homolka trial [anonymous]
o Risks of setting up awful puns
Aaron Barnhart
o Re: China Airlines A300 Crash
John Yesberg
o Re: Computer Crime on Wall Street
Mike Rosenberg
Marc Horowitz
o Cable / Closed Circuit TV Info Display Risks and 911
Bob Richardson
o Re: Logging on as root is easy!
Dan Franklin
o Re: UK ATM Spoof
Gary Preckshot
o Privacy Digests
o Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.


Martin Minow <>
Tue, 24 May 94 13:08:26 -0700
     From rec.humor.funny, but it belongs in Risks, too...
     In an effort to snag more long distance telephone calls (charged to a credit
     card or a third number), AT&T reserved the toll-free number 1-800-OPERATOR.
     Not to be outdone, and perhaps knowing the public better, MCI reserved the
     number 1-800-OPERATER and has been scooping up calls intended for its
     Walter C. Daugherity  Texas A&M University
       [So now we need legislation on Truth in Mispelings and Mistouchtonings? PGN] 

Bank goof creates millionaire

Andy Fuller < >
Wed, 25 May 94 08:57:43 EDT
     From the Tampa Tribune, Wednesday May 25, 1994
     Howard Jenkins was a multimillionaire for about a half a day.  About a week
     ago he lost his checkbook and called his bank to have a hold put on his
     account.  "When he went to make a deposit Fiday morning, he was told to check
     the automated teller machine outside to make sure the account was working."
     He made a small withdrawal and the receipt told him his account balance was
     $889437.93.  He went home and called the bank's automated telephone account
     inquiry system, and was informed that his balance was now more than $88
     million.  He went back to the bank and asked a teller for his balance, and was
     given an 8 digit number.  She asked if he had received "an inheritance or
     He withdrew $4 million in cashier's checks and cash, requiring a bank
     manager's signature on each check, and they "didn't bat an eye".  He returned
     later that day, accompanied by his lawyer, and returned the money.
     The bank attributes the erroneous balance to a computer error, probably linked
     to the hold transaction.
     Several things stand out to me:
     1) He was told to check an ATM to see if his account was working.  Whoever
     told him this should have been able to check directly using the bank's
     terminal.  The bank (and reasonably so) puts a great deal of trust in the
     2) The balance shown on the ATM receipt was different than that given him by
     the automated telephone information system and the teller.  Is this a user
     interface problem, or something more involved?
     3) The computer error is likely to be the fault of inadequate testing or a
     user interface inadequacy (calling up a deposit transaction instead of an
     account hold transaction).  Both topics have been discussed at length in this
     4) Nobody questioned this withdrawal or the large deposit.  The teller who
     checked his balance was the only one mentioned in the story that even noticed
     his windfall.  Proper software and human procedural checks would have caught
     this error.  If a pre-computer bank teller had been handed a deposit of this
     size, the bank manager would have been notified.  When the withdrawal was made,
     the manager would have known about the deposit and been confident that the
     request was legitimate.  Are similar human checks and balances included in
     modern banking computers?
     Andrew C. Fuller, E-Systems, ECI Division, St. Petersburg, FL   (813) 381-2000 x3194

two risk-related articles from Edupage 5/24/94

Terry Alford < >
25 May 1994 15:51:31 GMT
             A union claims that Library of Congress employees are exposed to
     potentially fatal crushing hazards caused by sliding mechanical bookshelves,
     and asserts in a lawsuit that the bookshelves have occasionally started up
     unexpectedly, undeterred by safety sensors.  The government insists the
     bookshelves have experienced "only three or four failures," none of which
     resulted in employee injury. (BNA Occupational Safety & Health Reporter
     5/18/94 p.1787)
             Information technology visionary George Gilder calls Michael Milken a
     risk-taker, "who was willing to plunge $2 billion into a company with $100
     million in assets and $200 million in revenues. He had a great eye and really
     did it brilliantly. The people who prosecuted him did not understand what he
     was doing at all. It was mysterious to them and he was making too much money
     to be legal [laughs]." (Upside, June 94, p.55)

Dell monitors too hot to handle

"Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM>
25 May 94 07:45:30 EDT
     Dell has issued a recall of 63,000 monitors after receiving 32 reports of
     overheating or fires starting. The problem monitors bear the number DL-1460NI
     on the back.
         Owners of the monitors with that number should call 1-800-913-3355 to set
     up free pickup and repair.
         Arrangements also can be made through Dell forums on CompuServe and
     America Online or by dialing Dell Computer Corp.'s bulletin board at
     512-728-3589. Dell will ship packing materials to owners of the monitors, who
     then will send them by Airborne Express to the company for repair within three
     to five working days.
     Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn
         [Watch out for The Foamer in the Dell.  PGN]

Canada, The Internet, and the Homolka trial

Fri, 20 May 1994 22:00:16 -0400 (EDT)
     As reported in Toronto's EYE Newspaper [] (similar to New York's
     Village Voice) dated 19 May 1994:
     The London Ontario detachment of the Ontario Provincial Police have begun a
     campaign of harassment against local University Internet users who are
     attempting to use the net to gain information on the Karla Homolka trial. A
     University of Western Ontario (London) student had his Internet account frozen
     by the university computer staff when requested by the Police. The reason for
     this lay in the student's name being left on the text of a FAQ of the details
     of the trial. Another student in Toronto had Faxed this material (which had
     been Emailed to him) to the Toronto media, and the offices of the Premier of
     Ontario and the Attorney-General as an act of provocation against the Ban (his
     regular anonymous forwarding site was not working). The problem was that he
     had forgotten to remove the other persons name and account number from the
     original E-mail that was sent out.
         The police action against the student's account was done without a
     warrant, and also involved the questioning of the student at the local police
     station. Likewise the students home computer was searched without a warrant by
     using the threat of criminal charges. The Student's computer account was
     reinstated, but he was required to turn over all incoming Email to the police
     under the threat of criminal charges if he did not cooperate. A list of about
     50 people who had received Homolka FAQ's were passed on to the police.  The
     important part of this entire situation is that no one, including the Ontario
     Attorney-General office is certain that the ban applies to the Internet. The
     ban states that details of the trial cannot be published in the print media
     but there is no ban on possession of information. There is no mention of the
     Internet, nor the use of computer systems in the ban.  Further, there is no
     official investigation of the Internet on the part of the Ontario Provincial
     Police, except for this one detachment.
        One of the questions raised is the ethics of the University of Western
     Ontario's computer department. Their cooperation with the police was based on
     a fear of having their computer equipment confiscated (similar to the case of
     the University of Cambridge in England). If the situation had taken place with
     in the library system of the university, it would not have been tolerated by
     the library staff due to the long held tradition in that profession of the
     defence of freedom of speech. If the Internet is to remain open this set of
     values will have to become part of the professional commitment of the MIS
     staff of universities as well.

Risks of setting up awful puns

Aaron Barnhart < >
Wed, 18 May 94 13:12 CDT
     If Schindler Elevator gets a black eye as a result of the Toronto 
     controversy, at least they have an ace in the hole.
       They can just change their name to Schindler's Lifts.
         [Remarkably, this was also suggested in various contexts by
             Mark Bartelt <>,
    (Spencer Roedder),
    (Jim Cook),
    (Harley Davis).
         I am absolutely delighted that I am not carrying the 
         entire burden of elevating the level of discourse.  PGN]

Re: China Airlines A300 Crash (Stalzer, RISKS-16.05)

John Yesberg < >
Fri, 20 May 1994 10:14:31 --9-30
     > ... This is a serious kind of failure, if an automatic system designed to
     > prevent a problem makes it worse, it should do nothing at all!
     This is probably true for conventional aircraft. For fly-by-wire aircraft,
     however, the computer systems can never "do nothing".
     I understand that the main computer system (in, e.g. A320) has six (approx)
     flight modes, and that it responds slightly differently to manual inputs
     depending on which mode it is in.  Pilots are required to understand the
     differences between the modes.  I imagine that, in non-emergency situations,
     the pilot would not need to worry about these differences: the aircraft would
     respond "intuitively" to command inputs.  In very unusual situations, the
     required inputs to the machine may be counterintuitive.  This can probably be
     overcome in two ways:
     (i)  Give the flight computer more modes to be in, so that it could behave
          "properly" or "intuitively" in the various situations.
     (ii) Give the pilots enough simulator training so that the intuition takes into
          account the mode that the aircraft is in.
     In critical manoevres, like landing and go-around, pilot confusion is to be
     avoided at all costs.
     John Yesberg (

Re: Computer Crime on Wall Street (RISKS-16.08)

Mike Rosenberg < >
Wed, 18 May 1994 14:48:51 -0400
     re: joe jett's alleded fraud:
     > It seems to me that this manipulation could only have been accomplished 
     > through extensive computer manipulation by Jett and possibly by others.
     I believe this is incorrect. 
     It probably happened because the accounting system did not handle the trade
     properly. i would guess that no outright manipulation of data or code was
     necessary. also, his gross strips position was probably growing larger and
     larger as time went on. this should have raised some red flags.
     mike rosenberg

Re: Computer Crime on Wall Street

Marc Horowitz <marc@MIT.EDU>
Sat, 21 May 94 16:45:30 EDT
     >> 76 total accidents, 3513 fatalities.  (How do you have *1* mid-air? 
     >> They must be counting accidents, not aircraft involved.)
     Although you are probably right, this is not impossible.  Several months ago,
     several people were killed in a small airplane over Massachusetts when it
     collided with a skydiver (who survived with a broken leg).  One plane, midair

Cable / Closed Circuit TV Info Display Risks and 911

Bob Richardson <bob@CSOS.ORST.EDU>
Tue, 17 May 1994 14:41:55 -0700 (PDT)
     John Gersh writes regarding an information channel display that showed an
     incorrect floor number during a fire alarm.  Other contributors have written
     regarding cable-TV channels reporting "Software Failure" for hours or days
     on-end.  As a manufacturer of such equipment for the Cable Television
     Industry, I hope I can provide some insight.
     A very common computer used in systems for broadcast applications is the
     Amiga.  This is because of it's relatively low cost for this application, as
     well as the fact that it generates clean video at standard NTSC/PAL rates. On
     older versions of the operating system, if a program crashed severely (the
     Amiga OS does not provide memory protection or resource tracking, yet is fully
     multitasking), a flashing red "guru" message would appear, requiring an
     acknowledgement from the user to reboot the machine.  Unfortunately, due to
     the nature of cable transmission, these machines are usually located in very
     remote sites.  Of course, many cable companies are too lax in even monitoring
     for crashed displays.  Under newer versions of the OS, this problem is solved
     in that after a timeout (usually 30 seconds), these requesters go away and the
     reboot proceeds normally.  Since the Amiga isn't a very widely supported or
     understood platform, most of these cable operators do not upgrade to newer
     OS's, and some machines cannot legally be upgraded (physically they can, but
     since ROMs are not available from Amiga, you have to make a copy of the OS and
     install it on the hard drive of the machine, which is technically illegal.)
     Our solution for our customers was to create a "watchdog" program that would
     reboot the machine in the event that our main task failed in any way. We then
     discovered something interesting: Most of the crashes occurring were not a
     result of our program (or our competitors), but of line spikes and brownouts
     trashing the machine.  We now insist that our customers at least purchase a
     line conditioner or a UPS as a result.
     One contributor to this list asked what cable companies will do now that
     Commodore is out of business, regarding replacement parts.  For quite some
     time now, it has been quite difficult to obtain support from Commodore anyway,
     so my company as well as others have been acquiring spare parts from used
     machines.  One should note, however, that Commodore's death is being
     exaggerated on the net, and that there is indeed a buyer, but specifics have
     not been made public at this time.
     An interesting incident reported to me by a customer: During the March, 1993
     earthquake in Klamath Falls, Oregon, cable service was not interrupted. The
     911 emergency center was being swamped with calls, many of them for
     non-life-threatening situations.  They called the cable company and requested
     that a message be posted on the air to tell people with minor emergencies to
     use an alternate number to reach the 911 center.  Unfortunately, the number
     provided to the cable company was incorrect, and was for the main 911 center's
     outgoing lines (non-emergency). The administrative office was then swamped
     with calls, and could not obtain and outgoing line to call the cable company
     and tell them to change the number.  As a result, the 911 center wants modem
     access to our software so that they can alter displays themselves. (I don't
     see how that could have prevented this particular situation.)  We are
     currently evaluating how best to achieve this.  There are several liability
     issues that open up when you allow third parties access to your airwaves.  Not
     to mention the fact that while our software is password-protected at this
     time, anyone with a password also has access to the billing and setup
     functions.  We now have to segment our security further so that outsiders can
     not mess with private or operation-critical information.
     Bob Richardson, Product Development Supervisor, Sound Concepts / MagicBox
     (503) 752-5542

Re: Logging on as root is easy!

Dan Franklin < >
Wed, 18 May 94 14:40:16 -0400
     I am somewhat skeptical of the apparent failure in security described by
     <> in RISKS-16.08.  I have been in the situation eddy
     describes many times, and the "NFS server ..." message always appeared AFTER I
     typed the password, if the password prompt appeared at all (sometimes it did
     not).  In fact since the code in question queries you for the password and
     then waits to collect it, it is difficult to imagine what it could be doing in
     between those two operations that would involve NFS access.
     Also, if the included transcript is literally accurate
      eddy@eddy> su
      NFS server not responding still trying
     then, since the "Password:" prompt does not end in a newline, eddy must
     have at least typed a newline before getting the "NFS server ..." message,
     and the possibility that the entire password was typed before that newline
     cannot be ignored; after all, until that much-loathed message appeared,
     eddy was presumably expecting to "su" as usual so as to be able to unmount
     the soon-to-disappear filesystems.
     Of course, this is computer software, so I'm not saying it's impossible! 
     But I'd like to see it duplicated before I believe it.  Unfortunately
     eddy's message did not give the UNIX version involved in this scenario, so
     I cannot do it here.
     The _real_ risk is that once you've entered the password, you've got a
     nascent superuser shell that anyone can type at once the server comes back
     up.  Yet one hardly wants to stick around and guard it...  In a university
     environment, this seems risky indeed.
             Dan Franklin

Re: Logging on as root is easy! (Franklin, RISKS-16.09)

eddy <>
Thu, 19 May 94 13:35:12 BST
     > The _real_ risk ... superuser shell that anyone ... In a university
     Interesting point.  The risks of leaving the terminal unattended aren't the 
     usual ones for a university; this is a lockable office which I share with folk 
     that I trust not to abuse a root shell and who would have locked the office if 
     they'd gone out in my absence -- ie, we don't get random undergraduates 
     wondering in in our absence -- but I hadn't typed the password, so this 
     wouldn't have been a problem (except that I'd feel shy of letting random UG's
     get at _my_ account, of course; which is one of our reasons for locking the 
     > ... if ... literally accurate ... possibility ... cannot be ignored ...
     The transcript is literally accurate; I copied the text from the command-tool 
     to the mail window by raw cut-and-paste.  I had not typed anything at the 
     password prompt when the NFS server message came up; what I did type (a tenth 
     of a second later -- thus before I'd noticed the message) was only the first 
     three letters of the password and I soon removed those with ^U because they 
     were being echoed !  I followed that with a return and several ^Cs (a strategy 
     which doesn't trick su normally -- the first experiment I tried on discovering 
     what had happened) so that nothing should sensibly have been able to go wrong.
     > ... after all ... eddy was ... expecting to "su" [so as] to unmount ...
     Dead right there; but, as I say, I noticed what was happening _before_ I'd
     typed the whole password.
     > I am somewhat skeptical ...
     And all Dan's reasons for skepticism (which I respect as such given that he
     only has the information third hand) are exactly the reasons for my horror
     upon discovering that I'd managed to become root without having typed the
     magic words.
     > I'd like to see it duplicated before I believe it. ... UNIX version ...
     Yes, duplication under controlled conditions is the only way to confirm.  The
     machine I'm running on is a Sun SPARCclassic running SunOS 4.1.3.
         [A similar correspondence occurred between 
   (Caveh Jalali) and Eddy,
         but it is not included here because of the overlap.  PGN]

Re: UK ATM Spoof

"Gary Preckshot" <>
19 May 1994 11:22:34 U
                            Subject:                               Time:10:57 AM
       OFFICE MEMO          Re: UK ATM Spoof                       Date:5/19/94
     Date: 19 May 1994
     Subject: Re: UK ATM Spoof
     >.....copies the one-time response from the card's LCD into the keypad).  
     >The ATM or banking network validates the response and continues the 
     >transactions.  Results of setting up a spoof on a stolen ATM: zero.]
     Surely this is an example of the risk of becoming too enamoured of your own
     ideas.  Regardless of the elaborate scheme proposed, all the fake ATM machine
     needs to do is look like it is responding correctly, and the user will enter
     his or her PIN.  The issue isn't validation, it's getting information out of
     the user by deceit, and anything that fools the user will work.  Only other
     information, not available easily either to the user or to the credit card
     thief, will fill this security hole.
     Instead, there probably has to be a piece of information possessed by the
     "smart" card which cannot be obtained without correct authorization.  Only an
     ATM hooked up correctly to the bank could obtain the passwords to unlock the
     card, which then provides some internal code unrelated either to the PIN or to
     the card account number.  However, this raises other issues, such as how could
     you use such a card for phone charges?  Or how could charges be validated at
     the point of sale?  Somehow the same challenge/response would have to occur at
     Macy's as it does at the ATM, or what good would the internal validation code
     do?  Thus, the challenge would be available for analysis on the general
     telecommunications system, and a significant communications burden would be
     placed on the system due to wide spread usage.  Somehow, I don't think it's
     quite so simple.

Privacy Digests

18 May 94
     Periodically I will remind you of TWO useful digests related to privacy, both
     of which are siphoning off some of the material that would otherwise appear in
     RISKS, but which should be read by those of you vitally interested in privacy
     problems.  RISKS will continue to carry general discussions in which risks to
     privacy are a concern.
     * The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein.  He manages it as
       a rather selectively moderated digest, somewhat akin to RISKS; it spans the
       full range of both technological and non-technological privacy-related issues
       (with an emphasis on the former).  For information regarding the PRIVACY
       Forum, please send the exact line:
     information privacy
       as the BODY of a message to ""; you will receive
       a response from an automated listserv system.  To submit contributions,
       send to "".
     * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
       run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
       comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
       forum, and was established to provide a forum for discussion on the
       effect of technology on privacy.  All too often technology is way ahead of
       the law and society as it presents us with new devices and applications.
       Technology can enhance and detract from privacy.  Submissions should go to and administrative requests to
     There is clearly much potential for overlap between the two digests, although
     contributions tend not to appear in both places.  If you are very short of time
     and can scan only one, you might want to try the former.  If you are interested
     in ongoing detailed discussions, try the latter.  Otherwise, it may well be
     appropriate for you to read both, depending on the strength of your interests
     and time available.

Previous Issue Index Next Issue Info Searching Submit Article

Report problems with the web pages to
This page was copied from:
Last modification on 1999-06-15
by Michael Blume