[1031] in RISKS Forum
RISKS DIGEST 16.09
daemon@ATHENA.MIT.EDU (RISKS Forum)
Wed May 25 12:18:01 1994
From: RISKS Forum <risks@csl.sri.com>
Date: Wed, 25 May 94 9:06:01 PDT
Reply-To: risks@csl.sri.com
To: RISKS-LIST:;@csl.sri.com
RISKS-LIST: RISKS-FORUM Digest Weds 25 May 1994 Volume 16 : Issue 09
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for information on RISKS (comp.risks) *****
Contents:
Call Your OPERATER! (Martin Minow)
Bank goof creates millionaire (Andy Fuller)
Two risk-related articles from Edupage 5/24/94 (Terry Alford)
Dell monitors too hot to handle (Mich Kabay)
Canada, The Internet, and the Homolka trial [anonymous]
Risks of setting up awful puns (Aaron Barnhart)
Re: China Airlines A300 Crash (John Yesberg)
Re: Computer Crime on Wall Street (Mike Rosenberg, Marc Horowitz)
Cable / Closed Circuit TV Info Display Risks and 911 (Bob Richardson)
Re: Logging on as root is easy! (Dan Franklin, Eddy)
Re: UK ATM Spoof (Gary Preckshot)
Privacy Digests (reminder)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Tue, 24 May 94 13:08:26 -0700
From: Martin Minow <minow@apple.com>
Subject: Call Your OPERATER!
From rec.humor.funny, but it belongs in Risks, too...
(True)
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
arch-rival.
Walter C. Daugherity Texas A&M University daugher@cs.tamu.edu
[So now we need legislation on Truth in Mispelings and Mistouchtonings? PGN]
------------------------------
Date: Wed, 25 May 94 08:57:43 EDT
From: acfa@callisto.eci-esyst.com (Andy Fuller)
Subject: Bank goof creates millionaire
>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
something".
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
computer.
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
forum.
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
acfa@callisto.eci-esyst.com (813) 381-2000 x3194 72417.612@CompuServe.com
------------------------------
Date: 25 May 1994 15:51:31 GMT
From: talford@mitre.org (Terry Alford)
Subject: two risk-related articles from Edupage 5/24/94
ATTENTION LIBRARIANS -- FATAL BOOKSHELVES
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)
RISK-TAKING
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)
------------------------------
Date: 25 May 94 07:45:30 EDT
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM>
Subject: Dell monitors too hot to handle
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]
------------------------------
Date: Fri, 20 May 1994 22:00:16 -0400 (EDT)
From: [anonymous]
Subject: Canada, The Internet, and the Homolka trial
As reported in Toronto's EYE Newspaper [eye@io.org] (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.
------------------------------
Date: Wed, 18 May 94 13:12 CDT
From: barnhart@mcs.com (Aaron Barnhart)
Subject: Risks of setting up awful puns
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 <sysmark@chipmunk.cita.utoronto.ca>,
roedder@netcom.com (Spencer Roedder),
jcook@epoch.com (Jim Cook),
davis@ilog.ilog.fr (Harley Davis).
I am absolutely delighted that I am not carrying the
entire burden of elevating the level of discourse. PGN]
------------------------------
Date: Fri, 20 May 1994 10:14:31 --9-30
From: jdy@itd0.dsto.gov.au (John Yesberg)
Subject: Re: China Airlines A300 Crash (Stalzer, RISKS-16.05)
> ... 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 (jdy@itd.dsto.gov.au)
------------------------------
Date: Wed, 18 May 1994 14:48:51 -0400
From: mkr@fid.morgan.com (Mike Rosenberg)
Subject: Re: Computer Crime on Wall Street (RISKS-16.08)
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 mkr@fid.morgan.com
------------------------------
Date: Sat, 21 May 94 16:45:30 EDT
From: Marc Horowitz <marc@MIT.EDU>
Subject: Re: Computer Crime on Wall Street
>> 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
collision.
Marc
------------------------------
Date: Tue, 17 May 1994 14:41:55 -0700 (PDT)
From: Bob Richardson <bob@CSOS.ORST.EDU>
Subject: Cable / Closed Circuit TV Info Display Risks and 911
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 bob@csos.orst.edu
------------------------------
Date: Wed, 18 May 94 14:40:16 -0400
From: dan@copernicus.bbn.com (Dan Franklin)
Subject: Re: Logging on as root is easy!
I am somewhat skeptical of the apparent failure in security described by
<eddy@gen.cam.ac.uk> 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
Password:
NFS server mbfs.bio 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
------------------------------
Date: Thu, 19 May 94 13:35:12 BST
From: eddy <eddy@gen.cam.ac.uk>
Subject: Re: Logging on as root is easy! (Franklin, RISKS-16.09)
> 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
door).
> ... 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.
Eddy
[A similar correspondence occurred between
Caveh.Jalali@eng.sun.com (Caveh Jalali) and Eddy,
but it is not included here because of the overlap. PGN]
------------------------------
Date: 19 May 1994 11:22:34 U
From: "Gary Preckshot" <gary_preckshot@lccmail.ocf.llnl.gov>
Subject: Re: UK ATM Spoof
Subject: Time:10:57 AM
OFFICE MEMO Re: UK ATM Spoof Date:5/19/94
Date: 19 May 1994
From: gary_preckshot@lccmail.ocf.llnl.gov
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.
Gary
DRTOPE@delphi.com
------------------------------
Date: 18 May 94
Subject: Privacy Digests
From: RISKS-request@csl.sri.com
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 "privacy-request@vortex.com"; you will receive
a response from an automated listserv system. To submit contributions,
send to "privacy@vortex.com".
* 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
comp-privacy@uwm.edu and administrative requests to
comp-privacy-request@uwm.edu.
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.
PGN
------------------------------
Date: 17 May 1994 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <risks-request@pica.army.mil>
(Dennis Rears <drears@pica.army.mil>). UK subscribers please contact
<Lindsay.Marshall@newcastle.ac.uk>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<risks-request@csl.sri.com> (which is not automated).
CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues
of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO
digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory
and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>"
logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may
differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and
WAIS are alternative repositories. See risks-15.75 for WAIS info.
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .
------------------------------
End of RISKS-FORUM Digest 16.09
************************
