RISKS@CSL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (04/27/87)
RISKS-LIST: RISKS-FORUM Digest Sunday, 26 April 1987 Volume 4 : Issue 78
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Re: Fidelity Mutual Funds Money Line feature (Martin Ewing, Brint Cooper)
Re: Forgery on Usenet (Matt Bishop)
Re: VCRs, Telephones, and Toasters (Mark Jackson)
References on computer-professional certification (John Shore)
CPSR/Boston presentation: "Reliability and Risk"
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
(Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM)
(Back issues Vol i Issue j available in CSL.SRI.COM:<RISKS>RISKS-i.j. MAXj:
Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.)
----------------------------------------------------------------------
Date: Thu, 23 Apr 87 23:09:11 PDT
From: mse%Phobos.Caltech.Edu@DEImos.Caltech.Edu (Martin Ewing)
Subject: Re: Fidelity Mutual Funds Money Line feature
To: risks%Phobos.Caltech.Edu@DEImos.Caltech.Edu
I'm another user of Fidelity's Money Line, and am now just a tad more
nervous. This last horror story confirms my latent suspicions.
Fidelity EFTS transfers can be initiated automatically via their "FAST"
telephone system. By calling an 800 number, and entering a sequence of some
20-30 digits, you can (1) get the status of your account (balance, last
investment, redemption, and dividend), (2) transfer between two existing
accounts, (3) transfer into a NEW account (in any of 60+ funds), and (4)
initiate an EFTS transfer from your bank account (if preauthorized).
Apparently all Fidelity accounts are born with FAST access. All you (or
anyone else) need to commit fiscal mayhem are your Fidelity account number
and a security code which (are you ready for this?) consists of the last 4
digits of your Social Security Number.
All of Salander's troubles might have come from a malicious "friend" on the
telephone. Even without slurping up funds from the bank, such a prankster
could create dozens of accounts for you in obscure funds. (Everything is
confirmed by mail, of course.)
I had thought that the 24-hr human assistance line would have been
sufficient to correct any random computer errors. Their attitude has been
good, in my experience. However, one particularly chatty operator did let
on that, while she thought the FAST service was generally good, she
strongly recommended calling the assistance line for transactions. "The
computer line has no backup," she said.
I note that my discount brokerage is similarly lenient in telephone
transactions. They don't have touchtone transactions, but they do take
orders over the phone with only my account number and no independent
verification. There outta be a law.
And now my bank has installed "TeleService" with features similar to Fidelity.
------------------------------
Date: Thu, 23 Apr 87 21:22:57 EDT
From: Brint Cooper <abc@BRL.ARPA>
To: bzs@bu-cs.bu.EDU
cc: risks@csl.sri.COM
Subject: Re: Fidelity Mutual Funds Money Line feature
Thank you for sharing your story with us. But why didn't you handle the
problem with the bank from the beginning? Around here, I don't think a
bank can release funds except upon your authorization; and if you revoke
that authorization, they may no longer release funds.
Then, upon occasion of the very first error, you simply close the bank account
and withdraw all your money. Fidelity is left "holding the bag," as it were.
I hope that, by sharing our experiences with the risks of computer systems, we
become more savvy at dealing with them. We're users as well as developers.
[I think we must all respond more forcefully when confronted with such
human-caused and other computer horrors. Perhaps a Ralph Nader-like
group might be appropriate, but individual action can also have an
effect, especially in quantity -- carefully worded nasty letters,
withdrawals of accounts, threats of lawsuits, and so on. PGN]
------------------------------
To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@CSL.SRI.COM>
Subject: Re: Forgery on Usenet (Brad Templeton, RISKS DIGEST 4.77)
Date: Fri, 24 Apr 87 07:32:12 -0800
From: mab@riacs.edu
Brad writes that there is no way to make USENET news secure, which is
perfectly correct (as has been pointed out.) He goes on to say that "I
think lots of people have got secure uucp mail, at least within their
organization, these days." Sorry, 'taint so. First, on any BSD UNIX system
except 4.3, and probably on any other UNIX V7-based system, mail on any
machine can be trivially forged, because they all use the "getlogin()"
routine to determine the sender. (4.3 does it right -- it uses
"getpwuid(getuid())".) Look at that routine sometime -- it's one of the
easiest to spoof.
If you have an SMTP mailer, things get to be even more fun. SMTP does not
do verification! Just connect to your SMTP mailer as would a foreign host,
and you're off. (To test this, we forged a letter from Opus the Penguin at
WhiteHouse.ARPA -- this was before domaining -- asking someone for pickled
herring heads for lunch, but if none were handy, for anything but squid.
Confused the heck out of the recipient until he asked the local mail guru,
me, what happened.)
There is an effort by the Internet Advisory Board Task Force on Privacy to
do something about protecting mail privacy and allowing it to be
authenticated. The task force proposal will be transparent, so it can be
dropped onto any SMTP implementation. If you're interested in this, grab a
copy of RFC 989 from the NIC.
Matt Bishop
------------------------------
Date: 24 Apr 87 11:04:11 EDT (Friday)
From: MJackson.Wbst@Xerox.COM
Subject: Re: VCRs, Telephones, and Toasters
To: mse%Phobos.Caltech.Edu@DEImos.Caltech.Edu (Martin Ewing)
cc: Risks@CSL.SRI.COM, MJackson.Wbst@Xerox.COM
Perhaps this is all fallout from cost-effective technology in one area
far outstripping advances in others? It is marvelously cheap to
implement functions in silicon, but actuators and displays are still
(relatively) expensive.
Thus one has the digital watch with 37 functions, each accessed by some
unique manipulation of only four buttons. For the VCR, providing a
screen display requires a (fairly inexpensive?) character generator, but
what about for a (non-video) telephone?
From a human factors viewpoint the effective bandwidth of the interface
limits the number of truly useful functions. But from a marketing viewpoint
the ability to advertise a maximum number of (technically useful) functions
is very attractive, and may carry the day. I suspect, therefore, that this
is going to get worse before it gets better.
Mark
------------------------------
To: seismo!csl.sri.com!risks@seismo.CSS.GOV
Subject: References on computer-professional certification
Date: 24 Apr 87 10:00:54 EST (Fri)
From: John Shore <epiwrl!shore@seismo.CSS.GOV>
I'm putting together a bibliography concerning the certification
of computer professionals, and I would appreciate some help.
I would like references to material about
(a) pros and cons of certification
(b) efforts related to certification
(c) certification methods
(d) current practice in other fields
(e) history of certification in other fields
Depending on the length of the resulting bibliography, I'll either
post it to RISKS or post an announcement about it.
Thanks in advance.
John Shore epiwrl!shore@seismo.css.gov ...seismo!epiwrl!shore
[We have noted previously the question of whether certification
might help reduce risks resulting from human foibles during
development, maintenance, etc. John's request is thus very
relevant here. I look forward to the results! PGN]
------------------------------
Date: Fri, 24 Apr 87 13:13:32 edt
From: reeves@decvax.dec.com (Jon Reeves)
To: risks@csl.sri.com
Subject: Presentation on Star Wars Computing April 29, Chelmsford MA
Disclaimer: I have no connection with any of the groups mentioned below.
Original-Date: Fri, 24 Apr 87 10:08:30 edt
Original-From: jmartin@abyss (Joseph A. Martin)
"Reliability and Risk", a multiprojector presentation on the computational
aspects of the Strategic Defense Initiative, will be given on Wednesday,
April 29, 7:30p.m. at the Old Town Hall, in Chelmsford Center. Please
forward this to anyone whom you feel would be interested. Thank you. --Joe
RELIABILITY AND RISK: COMPUTERS AND NUCLEAR WAR
A 34-minute slide/tape presentation
Reliability and Risk...
...investigates whether computer errors in key military systems--some of
them unpreventable errors--could trigger an inadvertent nuclear war.
...features technical, political, and military experts discussing the role
of computers at the heart of civilian and military systems, from the space
shuttle to nuclear weapons to Star Wars;
...describes the ways in which all large, complex computer systems make
mistakes--often unexpected and unpreventable mistakes:
o The 46-cent computer chip failure that led to a high-priority
military alert.
o The software error that led to the destruction of the first Venus probe.
o The design flaw that caused a missile early-warning computer to
mistake the rising moon for a fleet of Soviet missiles.
...explores the growing reliance on computerized decision making and how a
computer error could trigger a disaster, especially in a time of crisis.
...explains why we should not rely exclusively on computers to make
critical, life-and-death decisions.
...uses straightforward language and graphics and is recommended for all
audiences. No technical knowledge is required.
...received a Gold Award in the Association for Multi Image New England
competition in November, 1986--the largest multi-image competition in the
country.
Speakers in Reliability and Risk include:
o Lt. General James A. Abrahamson, Director, Strategic Defense Initiative
Organization (SDIO)
o Lt. Col. Robert Bowman, Ph.D., US Air Force (retired), Former Director,
Advanced Space Programs Development
o Dr. Robert S. Cooper, Former Director, Defense Advanced Research Projects
Agency (DARPA)
o Dr. Arthur Macy Cox, Advisor to President Carter, SALT II Negotiations, and
Director, American Committee on U.S.-Soviet Relations
o Admiral Noel Gaylor (retired), former Commander-in-Chief of the Pacific Fleet
o Dr. James Ionson, Director, SDIO Office of Innovative Science and Technology
o Severo Ornstein, Computer Scientist (retired) and Founder, Computer
Professionals for Social Responsibility
o Professor David Parnas, Computer Scientist, Resigned from SDIO Panel on
Computing in Support of Battle Management
o Dr. John Pike, Associate Director, Federation of American Scientists
o Dr. William Ury, Director, Harvard Nuclear Negotiation Project
o Actress Lee Grant as narrator
and many others
Reliability and Risk was produced by Interlock Media Associates and CPSR/Boston
------------------------------
End of RISKS-FORUM Digest
************************
-------