Subject: RISKS DIGEST 13.73
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Monday 17 August 1992 Volume 13 : Issue 73
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Microwave oven autonomously turning on (A E Eckberg)
Outdated sports news recurs (Geoff Kuenning)
Fire department to get computer dispatching (Robert Allen)
Electronic payment takes 2 weeks! (D. Langford)
Security breach cited as class schedule erased (UBC) (Thomas Dzubin)
A true tale of terror in the making: AUTOPAY (Steve VanDevender)
Another saga of long-distance carrier confusion (Brian Holt Hawthorne)
Intolerance and human differences (Rob Horn)
Re: Bug or Fraud (A. Padgett Peterson)
Re: Voting (Karen Frenkel)
1993 Research in Security & Privacy, Call for Papers (Teresa Lunt)
The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to
[email protected], with relevant, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. REQUESTS please to
[email protected].
Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
For information regarding delivery of RISKS by FAX, phone 310-455-9300
(or send FAX to RISKS at 310-455-2364, or EMail to
[email protected]).
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.
----------------------------------------------------------------------
Date: Mon, 17 Aug 92 05:57:44 EDT
From:
[email protected] (A E Eckberg)
Subject: microwave oven autonomously turning on
This article was originally posted in 'misc.consumers' and
'misc.consumers.house', and a responder suggested also posting in 'comp.risks'.
I'm looking for information from anyone who has experienced an
electronic-control appliance "autonomously" turning itself on or otherwise
doing something that it was not explicitly "commanded" to do by a user. Also,
if anyone has not experienced this first-hand, but knows of such incidents, I'd
like to know.
Here's why I'm looking for this information.
Recently, while we were out of the house, our electronic-control microwave oven
turned itself on. While this oven has a timer, it had not been activated, and
there was no "logical" reason for the microwave to turn on. There had been,
however, an electrical storm in the area that was severe enough to have
affected many of the computer systems where I work (about a mile from our
home), and the only logical explanation for the microwave coming on was that
its microprocessor control had received just the right impulses from the storm
to set it running. We don't know how long the oven had been running when we
came back, but when we entered the house the microwave was running and had
burned/melted a plastic trim piece inside, and had filled the house with
burned-plastic fumes.
In my opinion, electronic controls for appliances should be designed with more
fail-safe capabilities than seem to be the case here, and it appears to me that
our oven has a fundamental safety design flaw. Very likely ALL
electronic-control appliances share this flaw, and there are likely to be
severe consequences, although probably quite rare. In our case our house would
probably have burned if we had not come back and turned the microwave off.
Because occurrences like this are probably very rare, and maybe even
unbelievable, I'd like to hear from anyone else who could relate incidents
similar to this that could add to the believability of what happened.
Please send relevant information to me at
[email protected]
------------------------------
Date: Mon, 17 Aug 92 00:50:43 PDT
From:
[email protected] (Geoff Kuenning)
Subject: Outdated sports news recurs
About a year ago, Hennessey's, a local bar, replaced the usual ESPN programming
on one of their four TV monitors with an obviously computer-generated display
giving the day's sports scores, standings, and miscellaneous news, as well as
showing advertising and some simple graphics. I found it to be a nice
addition, since ten minutes or so of watching would give me the results on my
favorite teams.
This summer, the system has developed a rather troubling memory problem. There
seems to be a flaw in the deletion of outdated information. In July, for
example, it reported on the outcome of a Stanley Cup hockey game played in
April, complete with a coach's comments on the (supposedly) next-scheduled
game. This evening (August 16), it displayed baseball standings showing the
Dodgers in fourth place, 6.5 games out of first. (As of this morning, they
were in last place, 22 games behind. I guess today's loss to San Francisco
really helped their standings!)
Even more interesting, the out-of-date results are mixed with up-to-date
information. The incorrect baseball standings were followed by a Las Vegas
odds display gaving information on the correct National League baseball
schedule for Monday.
I have no idea how the system works (except that the immediacy of the
results and the speed of the display update together indicate a local
computer which receives information from a service via a modem), so I
can't speculate on where the problem lies. But it's clear that
somebody needs to erase the disk!
Geoff Kuenning
[email protected] uunet!desint!geoff
[Sounds as if there is a selective three month lag for certain
results. OR, could it be that some of the data entry is done by people
who write dates such as 7/4/92 to mean 7 April rather than July 4? PGN]
------------------------------
Date: Thu, 13 Aug 92 21:06:02 GMT
From:
[email protected] (
[email protected])
Subject: Fire department to get computer dispatching
From a scanner hobbiest newsletter:
Hayward [California] Fire department is going to be going to all MDT dispatch
in the future. According to Hayward Fire, they will never, ever, have to use
voice traffic again. Even the Battalion Chief won't hear the calls since there
will be no voice traffic calls. The Chief will have to be near a computer
terminal to see the calls. This according to an anonymous source.
The risks should be obvious...
------------------------------
Date: Fri, 14 Aug 92 17:22:36 BST
From: "D.Langford" <
[email protected]>
Subject: Electronic payment takes 2 weeks!
I bank with one of the UK's largest building societies, the Nationwide. I was
attracted by their advertising, which offered 'electronic payments' via their
cashpoint machines. You notify details of the accounts you'll want to pay, and
can then send money to pay the bills from any machine. It looked neat and fast,
and I liked the idea of a paperless payment.
I'd used it to pay my credit card bills for about a year, when in May I needed
to settle a Visa account of 600 pounds or so ($1100). It was twelve days before
the due date...
Yes, that's right. Although they debited my account immediately, they did not
pay the credit card company for two weeks - and I incurred interest charges for
not making a payment when I'd made it 2 weeks before.
This was NOT an accident, it wasn't a mistake - Nationwide told me that their
terms and conditions permitted them to take up to TWO WEEKS to make an
ELECTRONIC payment! The small print, which talks of 'working days' rather than
'real' days, bore this out. I'd - foolishly - always assumed payment would be
made faster if I used an electronic cashpoint; this was several times slower
than a paper transaction!
The RISKs are obvious; your money goes, but bills are not paid, and the bank
doesn't tell you.
I asked for a technical explanation - writing a system which takes two weeks to
process a payment sounded tricky to me. The eventual answer was so depressing
it had to be true - mag tapes are moved physically around the UK, until they
eventually arrive at the right location.
------------------------------
Date: Thu, 13 Aug 92 18:43:37 PDT
From:
[email protected] (Thomas Dzubin)
Subject: Security breach cited as class schedule erased (UBC)
(From _The Vancouver Sun_ August 13, 1992. Article by Lynn Moore)
University of B.C. student Tamiko Musgrove thought the worst had happened when
she checked on her class schedule for September and found she didn't have one.
Only two weeks earlier, Musgrove had used UBC's telephone registration system
and managed to get all nine courses she needed for her second year of study,
including those hard-to-get labs. Someone, Musgrove concluded after a brief
investigation, had breached the security of the Telereg system and wiped out
her courses. A Telereg hotline operator told her someone using her student
number and birth date entered the system one week after she chose her courses
and dropped them one by one. And seven of the nine courses she wanted had
filled up since then. Although Musgrove was quickly reinstated into her
courses after assuring UBC it wasn't she who dropped them, she still wonders if
Telereg security is up to snuff. UBC registration coordinator Sham Pendleton
says it is and what happened to Musgrove is rare. "One or two students each
year" claim their registration files have been tampered with through the
Telereg System, Pendleton said. And Martin Ertl of the Alma Mater Society said
Telereg security breaches have not been reported to the student association.
Students should keep their eight-digit identification number to themselves,
Pendleton said. That and their birth date combine to make the Telereg access
code. "Chances of someone knowing that combination of numbers is very, very
slim," she said. Student identification numbers have to be used on every
assignment and lab that is handed in to be marked, countered Musgrove, and it
would not difficult for a determined classmate to learn a student's number.
Birth dates are a little more difficult to figure out but not impossible, said
Musgrove, who believes that a male classmate who was harassing her last year
erased her courses. Pendleton said that when cases like Musgrove's arise,
students are put back into their original courses and given a new _and
fictitious_ birthday. Students can also request that a new birth date be
assigned to them if they fear their numbers are known to others, she said.
Thomas Dzubin,
[email protected]
------------------------------
Date: Wed, 12 Aug 92 23:30:22 PDT
From:
[email protected] (Steve VanDevender)
Subject: A true tale of terror in the making: AUTOPAY
I work for a game software company in Eugene, Oregon. It has grown
tremendously over the past year as a result of a successful series of products
and a merger with another, larger company, going from 35 to 135 employees in
about a year.
Traditionally, employees have been asked to hand in signed timesheet forms to
report vacation and sick leave days taken and information on projects we were
working on. During the last pay period the accounting department announced
they were going to introduce a program called AUTOPAY that would run on the
company-wide LAN to gather this information, and that eventually paper
timesheets would be phased out.
Someone soon noticed that since you only needed to provide your LAN login name
to AUTOPAY for identification, it was possible for anyone to view and modify
anyone else's timesheet data. When I brought up my concerns to our chief
financial officer while handing in my paper timesheet, I was assured that data
from AUTOPAY would be checked before being entered into the payroll system.
Later this person also responded to a public e-mail message noting that AUTOPAY
had no security, saying that "the only reason someone would modify another
person's timesheet would be to be mean or ornery." By now I had become
concerned, and wrote an e-mail reply of my own saying that with that kind of
attitude and no security, we were just waiting to be stung. I also noted that
computer-gathered data of this type is all too often used without any
verification. Even with verification it would still be possible to do subtle
things like add vacation days a few at a time to someone else's timesheet until
they were used up, resulting in at best confusion and at worst loss of pay when
the person claimed real vacation time.
Since then we've gone through another pay period where password protection was
hacked into the program. I promptly requested a password in person (the
announcement asked people to send password requests in e-mail!), then
discovered on returning to my office that I couldn't get it to work. I then
tried something that I hoped wouldn't work, but suspected would -- I grepped
the directory tree containing the AUTOPAY files for the first few characters of
my password, and found it in one of the files. To my horror this file was
publicly readable _and writable_; I could see other people's passwords and
modify them if I had wanted to. All six characters (the maximum allowed!) were
entered correctly in the password file but if I typed them into the program
they would never match, although typing the first five would work. After I
complained about the lack of access protection for the password file it was
made read-only, which means that although now people can't change other's
passwords, they can still find out what they are.
Unfortunately the head-in-the-sand approach to security exhibited by the
accounting staff and some other participants in a small public e-mail
discussion has been rewarded so far because no one has been malicious enough to
try screwing up the AUTOPAY data. I have gotten a bit frustrated that the
attitude towards security for data that affects everyone's pay is so lax.
Another less drastic problem with this AUTOPAY system is that it has an
unusually poor user interface, particularly when it comes to saving timesheet
data and exiting the program--I usually have to run through it twice to make
sure that my data has been entered properly because the method for exiting and
the prompts given by the program are obscure. The individual author (whose
name appears in a garish and pointless title screen) appears to know as little
about user interface design as he does about security.
Although nothing has yet gone terribly wrong with AUTOPAY, it has all the
ingredients of a minor computer security fiasco in the making. I hope that any
sequels I write will be happier ones.
------------------------------
Date: Mon, 10 Aug 92 09:53:41 EDT
From:
[email protected] (Brian Holt Hawthorne)
Subject: Another saga of long-distance carrier confusion
Kraig Meyer reported on being switched from MCI to AT&T without any action on
his part. We has something similar happen to us recently, but with an
additional twist.
In February, MCI called our home and convinced my wife to sign us up for the
MCI Friends & Family program, promising her $20 of free long distance and that
they would switch us back free to AT&T if we didn't like it. She asked them
explicitly how the $20 would be paid ("a credit on your first month's bill")
and generally made sure they weren't trying to pull any tricks. I was surprised
that several days later, we were on MCI, since I have a password on my New
England Telephone account that they assured me would prevent anyone from making
any changes without it. Risk number one: a supposedly secure system that allows
unauthorized transactions if they come from certain sources that NET trusts,
but I don't.
In early March, we received an envelope from MCI containing a $5 certificate
good only for our March bill, a $5 certificate good only for April and a $10
certificate good only on our May bill. I immediately called MCI and explained
that this was unacceptable, and that I wasn't going to do business with a
company that lied to us. I told them to switch us back to AT&T free like they
had promised. I was told that I would have to call my local phone company for
that change, that they could only switch people to MCI, not to other carriers.
I asked them how they were going to pay for it, and they said "a credit on your
bill". Risk number two: MCI claims to be unable to reverse their transactions.
I called NET and they agreed to switch me back to AT&T. Several days later, the
700 number that tells you your LD carrier told me I was on AT&T. When our
March bill arrived, it had all LD calls billed by MCI. I called the 700
number, and sure enough, we were back on MCI.
NET looked up the change and told me that apparently MCI frequently puts
through changes a couple of months in a row, to make sure that people really
get switched. They agreed to switch me back to AT&T immediately at no cost.
They also told me not to pay for any of the calls billed by MCI after the date
was supposed to have been switched to AT&T. Risk number three: Transactions
are not verifiable, and are repeated.
A month later, our April bill arrived, and all of the LD charges were billed
by...you guessed...MCI. We called NET who informed us MCI had pulled the same
trick: apparently not many people take them up on their offer to switch back
after a month. NET told us not to pay the LD charges (so we ended up getting
the free LD service after all :-) and switched us BACK to AT&T. About this time
I started getting entreating letters and phone calls from BOTH AT&T and MCI
begging me to get back on their service. I was very short with MCI, and had to
try very hard to convince that AT&T telemarketers that I really was on AT&T and
they weren't going to pick up a commission on me. Risk number four:
telemarketing databases that seem out-of-date with customer records.
When our May bill arrived, our LD calls were billed by MCI. This time NET
assured us that we really were on AT&T and they would look into it. They told
us to pay the bill (over my protestations). The 700 number told us we were on
AT&T.
Our June bill was also billed by MCI, and this time we managed to talk to
someone at NET who took an intellectual interest in what was happening, and
tracked things down. Apparently, NET had us correctly connected to AT&T's LD
network, and everytime we called, the technicians would check the configuration
on our number and see that we had already been changed to AT&T and do nothing.
The billing system, however, had failed to notify AT&T that we were back on
their network, and had also failed to notify MCI that we were off of their
network. Moreover, NET's billing system actually thought we were on MCI.
Our July bill correctly showed us on AT&T for the latter part of the month.
Question: does this mean that NET generates the billing data for LD calls
dialed, rather than the company that is actually carrying those calls??
[email protected] +1.617.255.9600x132
------------------------------
Date: Wed, 12 Aug 1992 15:39 EST
From: HORN%
[email protected]
Subject: Intolerance and human differences
System designers will need much more understanding of diversity (not the PC
kind) as computer based systems go into widespread use. The somewhat
intolerant comments regarding user inability to understand obvious systems are
indications of design flaws. There are some people who are stupid, and others
who have learned to use feigned stupidity as a negotiating mechanism, but most
of these problems are related to different personality traits.
As a basic, I recommend that anyone working with such systems really learn
about how different people can be. The Hermann Brain dominance profile
(left-right brain) and the Myers-Briggs profiles are two important ways to
discuss some aspects of differences. There are also many other more discipline
specific analyses of such things as human behavior under stress, etc. Reading
the literature is a start, but the organized training courses are very
important. Take one if possible. You may learn a lot about how differently
react and how differently they want to be treated.
One of the classic examples is between the analytic left-brained engineer who
insisted on a detailed theoretical training method. His customers were
physically oriented lower-left brain sensor types. They wanted someone to take
them to the machine, literally hold their hands, have them push the buttons,
and directly experience the machine. The engineer felt that this would be a
very demeaning experience, while they thought the lecturing was worthless and
insulting. A simple personality difference.
Also, don't forget the impact of age, illness, stress, and the like on
behavior. Now that more of us have grey hairs you see more computers that are
usable by bifocal wearers. Rob Horn
[For more on the left-brain / right-brain differentiation, see my chapter,
Psychosocial Implications of Computer Software Development and Use: Zen and
the Art of Computing, in Theory and Practice of Software Technology,
edited by Ferrari, Bolognani, and Goguen, North-Holland, pp. 221-232, 1983.
PGN]
------------------------------
Date: Wed, 12 Aug 92 15:29:49 -0400
From:
[email protected] (A. Padgett Peterson)
Subject: Re: Bug or Fraud (RISKS-13.72)
> [Once again this brings up the concern of people thinking that anything that
> happens in a computer system that wasn't expected by the end users is a bug.
> I'd like a job where I got paid $7000 to remove a "conditional statement."
Back before the flood there used to be a joke about the computer repairman
(person?) that , when called to fix a problem, disappeared inside the computer
with a little silver hammer. Shortly there can a musical *tonk* from inside
and all of the lights began to blink.
Emerging, the repairman presented the owner with a bill for US$ 25000.25. The
owner protested and requested an itemized bill. The repairman complied with
the following: Striking computer: US$ .25
Knowing where to strike computer: US$ 25000.00
I have yet to have anyone complain about my prices to cure a virus. Padgett
------------------------------
Date: Wed, 12 Aug 92 16:27:42 EDT
From:
[email protected]
Subject: Re: Voting (Mercuri, RISKS-13.72)
Rebecca Mercuri has given the wrong address for the hearing on voting machines
that is to take place on Aug. 20. The correct address is: 42 Broadway, which
is downtown near Battery Park City. This hearing is for the press and is a
contract briefing. The second hearing, on Sept. 10, is open to the public.
------------------------------
Date: Fri, 14 Aug 92 11:39:27 -0700
From: Teresa Lunt <
[email protected]>
Subject: 1993 Research in Security & Privacy, Call for Papers
CALL FOR PAPERS
1993 IEEE Symposium on May 24-26, 1993
Research in Security and Privacy Oakland, California
sponsored by
IEEE Computer Society
Technical Committee on Security and Privacy
in cooperation with
The International Association for Cryptologic Research (IACR)
The purpose of this symposium is to bring together researchers and developers
who work on secure computer systems. The symposium will address advances in
the theory, design, implementation, evaluation, and application of secure
computer systems. Papers and panel session proposals are solicited in the
following areas:
Secure Systems Privacy Issues Information Flow
Network Security Formal Models Viruses and Worms
Database Security Access Controls Security Verification
Authentication Data Integrity Auditing and
INSTRUCTIONS TO AUTHORS:
Send six copies of your paper and/or panel session proposal to Richard
Kemmerer, Program Co-Chair, at the address given below. Put names and
affiliations of authors on a separate cover page only, as a ``blind''
refereeing process is used. Abstracts, electronic submissions, late
submissions, and papers that cannot be published in the proceedings will not be
accepted.
Papers must be received by November 15, 1992 and must not exceed 7500 words;
papers that exceed this length will be rejected without review. Authors will
be required to certify prior to December 25, 1992 that any and all necessary
clearances for publication have been obtained. Authors will be notified of
acceptance by February 1, 1993. Camera-ready copies are due not later than
March 15, 1993.
The Symposium will also include informal poster sessions. Send one copy of
your poster session paper to Teresa Lunt, at the address given below, by
January 31, 1993. Electronic submission of the latex source for poster
session papers is strongly encouraged. Poster session authors must send a
certification with their submittal that any and all necessary clearances for
publication have been obtained.
PROGRAM COMMITTEE
Tom Berson Paul Karger Jon Millen
Anagram Laboratories OSF MITRE
Deborah Cooper Tanya Korelsky Jeff Picciotto
Paramax Systems Corporation ORA MITRE
George Dinolt Sue Landauer Phillip Porras
Loral Labs TIS Aerospace
Virgil Gligor Teresa Lunt Ravi Sandhu
University of Maryland SRI George Mason Univ.
Deborah Hamilton Doug McIlroy Marv Schaefer
Hewlett-Packard Laboratories AT\&T Bell Labs CTA
Jeremy Jacob John McLean Brian Snow
Oxford University NRL NSA
Sushil Jajodia Catherine Meadows Yacov Yacobi
George Mason University NRL Bellcore
For further information concerning the symposium, contact:
Teresa Lunt, General Chair Cristi E. Garvey, Vice Chair
SRI International, EL245 TRW, MS R2-2104
333 Ravenswood Avenue One Space Park
Menlo Park, CA 94025 Redondo Beach, CA 90278
Tel: (415)859-6106 Tel: (310)812-0566
FAX: (415)859-2844 FAX: (310)812-7147
[email protected]
Richard Kemmerer, Program Co-Chair John Rushby, Program Co-Chair
Computer Science Department SRI International, EL254
University of California 333 Ravenswood Avenue
Santa Barbara, CA 93106 Menlo Park, CA 94025
Tel: (805)893-4232 Tel: (415)859-5456
FAX: (805)893-8553 FAX: (415)859-2844
[email protected] [email protected]
Jeremy Jacob, European Contact
Oxford Univ. Computing Laboratory
11 Keble Road
Oxford, England OX1 3QD
Tel: +44 865 272562
FAX: +44 865 273839
[email protected]
------------------------------
End of RISKS-FORUM Digest 13.73
************************
