The Risks Digest

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 13 Issue 50

Sunday 17 May 1992

Contents

o Food stamp computer misbehaves in Maryland
Joseph E. Richardson
o Spelling checker advocates massive drug abuse
Randy Lindsey
o Credit card databases prefer St. to zip codes
David C. Kovar
o Risk of TRW Not Having Enough Information
S. Peter Loshin
o Re: Free TRW Credit Report
R. R. Hauser
o Yet more Software-in-the-Air scares
Simon Marshall
o More on the F-22 crash: pilot error now blamed
PGN
o Re: F-22 crash, cont'd.
Daniel P. Johnson
Larry
Bob Rehak
o Final Announcement for IFIP/Sec '92
Guy G. Gable
Carlos Delgado Kloos
o FTC Newsletter Volume 9
FTCS-92 + workshop on Fault-Tolerant Par.Dist.Sys.
o Info on RISKS (comp.risks)

Food stamp computer misbehaves in Maryland

Joseph E. Richardson <joseph@bse.com>
Wed, 13 May 92 09:43:21 EDT
Food Stamp Computer Clogs in Md. -- Overloaded System Causes Long Lines
By Retha Hill - Washington Post Staff Writer [Washington Post, 13 May 1992]

Maryland food stamp clients using a new electronic benefit system were unable
to buy groceries [on 6 May 1992 <JR>] after the state-of-the-art computer
system failed, causing long lines at hundreds of stores in the state.

The system, which the U.S. Department of Agriculture has said it plans to use
as a model for the rest of the coutry, became overloaded for the second time in
a month and shut down for about two hours as hundred, and possibly thousands,
of recipients tried to use their plastic benefit cards to make purchases.
Typically, the first few days of the month are heavy shopping days because that
is when clients receive benefits.

The system "reached a point where it clogged," said Helen Szablya, a
spokeswoman for the Maryland Department of Human Resources.  She said that she
did not know if other benefits that are encoded on the plastic cards, such as
welfare payments and child support, were affected.

About 31,000 Maryland residents in Montgomery, Prince Georges and Cecil
counties and Baltimore now have the cards.  Clients in Baltimore, Howard and
Anne Arundel counties are to get the cards by mid-summer, and eventually
200,000 recipients will use them.

Szablya said the electronic benefit transfer system is better than the old
method [Electronic systems are always "better", aren't they? :-) JR] of issuing
coupons to clients and said that problems are going to happen because it is the
first of its kind in the country. The system last stopped working April 11 for
about two hours.  "It's going to have a few blips.  We are happy with the fact
that we haven't had more," she said.

Shoppers and grocery store officials complained of long lines and carts loaded
with groceries abandoned as checkout stations.  Food stamp clients were given
$50 vouchers to make purchses, but cashiers had to call a toll-free number to
verify each transaction.

"We just think it's unfortunate that this happens and that it inconveniences
our customers," said Mitchell D. Herman, senior vice president for corporate
affairs for Shoppers Food Warehouse. [How true, how true. -- JR]

Joseph E. Richardson, Berard Software Eng., Inc., 101 Lake Forest Blvd,
Ste 360, Gaithersburg, MD 20877-2611   (301) 417-9884  joseph@bse.com


Spelling checker advocates massive drug abuse

Randy Lindsey <lindsey@tincup.enet.dec.com>
Tue, 12 May 92 12:57:56 PDT
It is not uncommon in large companies to require an annual "payout", in which
each employee picks up their paycheck in person, displaying ID.  I think this
is to guard against payroll padding.

At the facility where I'm doing a project, all 1,500 employees received a memo
ordering them to report to the cafeteria for their annual "peyote".  Peyote
appeared several times in the memo, and even in the title line!  Eventually
one of my colleagues ran "payout" through the spelling checker, and sure
enough it suggested "peyote" as the alternative.

Perhaps the spelling checker writers are junior staff with closer ties to their
college counter-cultural days than to corporate terminology...
                                                                Randy Lindsey


Credit card databases prefer St. to zip codes

"David C. Kovar" <kovar@eclectic.com>
Wed, 13 May 1992 09:38:32 -0400
  About two years ago, I started getting some credit card statements a few days
late. All of them had an incorrect zip code and the post office had corrected
them by hand and resent them. I called up the offending credit card companies
and tried to correct the problem.  Two of them corrected it, one of them
couldn't/wouldn't. I eventually cancelled the card belonging to the bank that
couldn't get the address right.

  Well, for various reasons, I've taken my time in paying off the account, so I
still get statements from them, still with the wrong zip code. Apparently the
Post Office is cracking down on bad zip codes because both AT&T and this
particular bank called me up this week to verify my address.

  About three months ago I finally figured out what I thought was the problem.
I live on Broadway, and my zip code is 02174. People frequently want to know if
it is Broadway Rd, Broadway St, Broadway Ln?  It's just Broadway. All of the
offending statements had my address as Broadway St, and my zipcode as 02111.
Someone's database, somewhere, mapped Broadway St. to a 02111 zip code and, if
the zip code was corrected but the street address wasn't, it would modify the
zip code again to what it believed was correct.

  So, I explained all this to the person from the bank, had her change the
street address and the zip code, and we'll see if it works.

  If anyone has any more information on this problem, I'd be interested in
hearing about it. I don't have enough time at the moment to track down which
database these guys are using. If anyone is curious, the bank is Chase
Manhattan.
                                     -David Kovar

    [We have had a spate of similar tales of woe in the past.  In this case,
    please send responses to David.  If anything exciting comes up, I am sure
    he will share it with us.  PGN]


Risk of TRW Not Having Enough Information

"S. Peter Loshin" <pql1191@mvs.draper.com>
Tue, 12 May 1992 16:20:00 EDT
This might be of some interest, as I recently was denied credit (temporarily)
due to inability of the credit grantor to verify my address.  I cleared that up
by sending copies of utility statements to the credit grantor, but out of
curiosity I took advantage of the free copy of the TRW credit report that
caused the denial.

Maybe I'm just different - I use my middle name and don't use my given first
name, and I use a PO box for as much correspondence as possible - but the
report was VERY sparse.  My address was three years out of date and they had no
info on my employer or on any of the credit cards that I customarily use.
There were NO negative reports from any of the institutions listed, and only
one neutral report.

Overall, I was fairly pleased with the lack of complete information on me -
unless it was all a ruse to lull me into a false sense of security about my
privacy.

Peter Loshin | peter@draper.com | 555 Technology Sq Cambridge MA 02146


Re: Free TRW Credit Report (RISKS-13.46 and 47)

R. R. Hauser <rrh@gabriel.b11.ingr.com>
Fri, 8 May 1992 13:03:45 -0500
Three credit reporting agencies exist (to my knowledge): TRW,
    Transunion (Merchants), and Holloway Credit Bureau.

Since I happen to have my credit report in hand (Holloway) which
    lists address/phone for Transunion and TRW, I called TRW
    long-distance and spoke with a representative about the free
    credit report. She gave me this number 1-800-392-1122.

The risk seems low IF you do the following rather than trusting
    some bulletin board posted P.O. Box address.

Go to a local credit bureau and get your report (~$10) or borrow
    someone's to get valid address/phone for TRW. Call and inquire.

Since this may cost a bit you could call the 1-800 number I got
    from TRW and wait until a representative comes on. The risk
    in trusting this posted phone number can be reduced by waiting
    until a person comes on rather than trusting a computerized voice.

When questioned, the TRW representative (how knowledgeable?)
    implied that _establishing_ any kind of credit had nothing to
    do with this service. Also, a bill is not necessary ... just
    anything with the name-address linkage. Hmmm...

Seems that the risk of someone easily obtaining your credit report
    from TRW may be higher now.

 R. R. Hauser                       DOMAIN: hauserr@infonode.ingr.com


Yet more Software-in-the-Air scares

Simon Marshall <S.Marshall@sequent.cc.hull.ac.uk>
Sun, 17 May 1992 16:06:12 +0000
Here are yet more stories concerning flight control software going wrong in
commercial passenger aircraft.  It is taken from the front page of the UK
``Sunday Telegraph'' May 17, 1992, a so-called ``quality newspaper''.  The
article is quoted in its entirety.

  Air scares over computers", Robert Matthew and Christopher Elliott.

  A spate of software errors forcing planes into sudden changes of speed and
  direction has rekindled concern about the use of computers by the aircraft
  industry.  An internal British Airways document discloses 10 serious
  incidents involving computer errors in January, including:

  - January 13, when the flight-management system on a Boeing 747-400 from
    Washington to Heathrow suddenly ordered a speed reduction of 50 knots.

  - January 26, when a Boeing 747-200 flying to Gatwick from Barbados
    experienced a sudden increase in thrust due to a software error.

  - January 27, when a Boeing 747-200 from Manchester to Islamabad suddenly
    pitched upwards.  The crew had to turn off the auto-pilot to bring the
    aircraft back into normal flight.

  Other computer errors have led to navigational deviations and to the
  auto-pilot wandering from the correct route.

  British Airways said action had been taken to rectify the problems, which did
  ``not present any threat to the safety of the aircraft''.  A spokesman added
  that the software had Civil Aviation Authority approval and had been tested
  by BA for more than 100 hours before entering service.

  But leading computer experts are worried that there is no adequate way of
  testing the enormously complex software routinely used by the aircraft
  industry.

  The British Computer Society will call this week for international standards
  on the design of safety-critical software, and for special qualifications
  from [sic] those working the field.

  Professor John Cullyer, of Warwick University, chairman of the society's
  Safety Critical Systems Task Force, said: ``We haven't for enough highly
  educated and trained checkers.  We actually know what we ought to be doing but
  we just don't have enough men and women sufficiently qualified.''

  Professor Bev Littlewood, of City University, London, has told the American
  Association for Computing Machinery that the aircraft industry could not
  substantiate claims for computer reliability."


There are couple of things that made me post this article.  Firstly, the number
of incidents - 10 in a single month with BA.  This implies that software is not
working in normal, routine, flying conditions, where you might expect the
behaviour of such systems to be correct.  There are no suggestions in the
article that "the pilot flew to low", "the pilot applied full thrust too late",
and so on, but that the systems themselves failed to perform correctly in
normal conditions.

The second is that at least some of the "software errors" were within
auto-pilot control systems (it may be all, the article is not clear - maybe BA
does not fly any fly-by-wire aircraft anyway, I don't know).  These systems
are, as I understand it, typically not used for takeoff or landing, but to fly
from A to B once airborne.  Given the number of years these systems have been
around, it worries me to think that these relatively simple systems fail at
this frequency, while fly-by-wire, with its increased complexity and the
increased reliance upon those systems for the safety of the aircraft, is now
being applied to commercial aircraft.

The third is that the software had "CAA approval", as if this is meant to make
us feel any better, and that it had been tested by BA themselves (not the CAA),
for "100 hours before entering service".  This does not seem particularly
rigorous to me!

The fourth came with the old call for qualifications for those working in
safety-critical software design; lack of suitably trained people.  Maybe the
CAA and aircraft manufacturers should be training their software personnel?

Simon Marshall, Dept. of Computer Science, University of Hull,
Hull HU6 7RX, UK   Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181


More on the F-22 crash: pilot error now blamed (RISKS-13.46)

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 14 May 92 12:10:56 PDT
Those of you who read RISKS-13.46 noted that computer software seemed to be
implicated in the crash of the only flying F-22 prototype.  A later report now
suggests pilot error.  As usual, the real causes are probably some combination
of a poorly designed human interface, software design and implementation
problems, hardware-software system response delays, and pilot problems
(training, complexity, etc.).

An AP report somewhen during 11-13 May (while I was in D.C.) had these
statements (starkly excerpted):

   A new Air Force videotape of the crash, shot from the plane's side, shows
the radar-eluding aircraft with its landing gear down as it nears the runway at
the California base.  The landing gear is then drawn back up about the same
time the afterburners go on. The plane then bucks wildly before hitting the
pavement, sliding several thousand feet and burning.  [...]
   Congressional sources, who requested anonymity, said the Air Force now
suspects that pilot error caused the crash. A final report is not expected for
several weeks after the Air Force completes its investigation.

   Air Force Chief of Staff Merrill McPeak [quoted in RISKS-13.46 as hoping
that it was software, because that would be "relatively straightforward" to
fix] testified before Congress he suspected the crash was the result of a
mechanical malfunction in the plane's computer system.  "I am utterly convinced
personally that this is a very meritorious design," said McPeak [...].  The Air
Force chief of staff said he saw no need to change the program, which calls for
650 of the fighter planes to become operational in 2002.


Re: F-22 crash (Watson, RISKS-13.47)

<drdan@src.honeywell.com>
Mon, 11 May 92 09:08:43 CDT
I haven't entered this discussion because there are a lot of people with more
solid credentials, but there are some elementary points to be made. If I get my
ears pinned back, so it goes.

When something goes seriously wrong in a control system, a common result is
that the system goes unstable. The wild motions of the tail are due to
positive feedback between the control system, the pilot, and the aircraft
responses. As to what caused the instability, it can be almost anything,
software error, design error, hardware failure.

A likely explanation would be that the aircraft had some unexpected
aerodynamic characteristics in the low altitude, high weight regime that it
was flying (to be expected in a prototype aircraft, that's how test pilots
earn their pay). The result was a "PIO" (Pilot-Induced Oscillation).

One can view this as a software error since the fix is to change the software
to allow for the unexpected dynamics, or as a pilot error since he was part of
the positive feedback loop, but it is better to classify it as a design problem
since one of the goals of the design is to avoid creating a situtation in which
a PIO is possible.

Daniel P. Johnson, Honeywell Systems and Research Center, MN65-2500, 3660
Technology Drive, Minneapolis, MN 55418 drdan@src.honeywell.com 612-782-7427


Re: F-22 crash, cont'd. (Watson, RISKS-13.47)

<larry@psl4381.NMSU.Edu>
Wed, 13 May 92 13:23:50 MDT
I recorded the same footage and played it several times in slow motion to
observe the porpoising motion of the ship. A flash from the cockpit (assumed to
be the ejection system) could be seen at the end, just before the ship kissed
the runway.

I believe you'll find that large, rapid movements of control surfaces are a
common feature of modern fly-by-wire control systems for fighters. It is
necessary because of the complex flying modes involved, particularly on
take-off and landings, which limit control surface effectiveness. Special
[non-linear] servo modes are involved.

Such problems are likely to be exacerbated on the YF-22 which is probably an
unstable design to begin with (to achieve maximum maneuverability) stabilized
by the computerized control system.

>  Odd that the software should be seen as a possible cause of the crash, ...

You can almost bet that the pilot was NOT the problem. The handful of people
who can qualify as test pilots are not the sort to make the mistake of extreme
pilot input. Many have been known to cooly report problems and symptoms in the
last few seconds of their lives.

As for software, someone observed that if buildings were constructed like
programs, the first woodpecker to come along would destroy civilization!
(Still, I would expect this particular control program to be a state of the art
example of good software..)

>  I though most aircraft could dump/vent excess fuel, you don't have to be at low
>  altitude to do this, do you?

That's another problem. Suppose we suddenly reduce the flight weight of a
fighter by a significant percentage? It seems reasonable that the ship might
need to be retrimmed quite a bit after a major fuel dump, so it is probably not
prudent to do it at low altitudes.
                                                    Larry


Re: F-22 an speaking out of turn (Watson, RISKS-13.47)

Bob Rehak Ext. 3-9437 <A20RFR1@niu.bitnet>
Mon, 11 May 92 10:15 CDT
All well designed aircraft have a fuel jettison system for dumping fuel.  Most
fuel is dumped at higher altitudes so that it evaporates before it hits the
ground; however, if your aircraft is in distress and is at a low altitude and
you are someplace isolated like the F-22 was, who cares if you jettison the
fuel.

The claim that the F-22 was doing these low altitude high speed passes to
reduce its fuel load so it could land with a greater saftey margin sounds bogus
to me.  If the aircraft was in distress these aren't the kind of maneuvers a
prudent pilot would be doing.

Also, what about the risks of speaking out of turn.  I feel Gen.  McPeak's
statements are a bit premature and could bias the accident investigators.  I
don't how many times I have gone done the wrong path in tracking down a
software problem because I was biased by the information given to me by a
software developer (who's judgement, expertise, ect. I trusted).  Moral of the
story, start at the beginning and follow your judgement not theirs.  If the
investigators were to think: Hey, let's look at the s/w and computers because
that's where the Gen. says the problem is... well you know what happens next.

Bob Rehak, DBA At Large, A20RFR1@MVS.CSO.NIU.EDU


Final Announcement for IFIP/Sec '92

"Dr. Guy G. Gable, IFIP/Sec '92 Program Chair" <ISCGUYGG@nusvm.bitnet>
Sat, 16 May 92 07:24:36 SST
                               THE IFIP/SEC'92
              8th INTERNATIONAL INFORMATION SECURITY CONFERENCE

                               May 27-29, 1992
                        Raffles City Convention Centre
                                  Singapore

    [FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or get
    it from Guy Gable.  PGN]


IFIP'92 registration form

Carlos Delgado Kloos <cdk@dit.upm.es>
Thu, 7 May 92 19:47:27 +0200
    [FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or
    get it from Carlos Delgado Kloos.  The DEADLINE FOR EARLY REGISTRATION
    DISCOUNT is 25 May.  NEXT MONDAY!!! PGN]


FTC Newsletter Volume 9

FTCS NEWS <ftcsnews@snowy.crhc.uiuc.edu>
Thu, 23 Apr 92 11:34:32 CDT
ELECTRONIC NEWSLETTER ON FAULT-TOLERANT COMPUTING

VOLUME 9, APRIL 1992

EDITOR: Prith Banerjee, University of Illinois

CONTENTS: (Each item can be searched by keyword ITEM
           and separated by a line of =========)

1. GENERAL INFORMATION AND REGISTRATION FOR FTCS-92,
   7-10 JULY 1992, The Lafayette Hotel, Boston, Massachusetts USA
2. ADVANCE PROGRAM FOR FTCS-92
3. WORKSHOP ON FAULT TOLERANT PARALLEL DIST. SYS.
   Campus Center Hotel, Amherst, Massachusetts USA, July 6-7, 1992
4. CALL FOR PAPERS (HICSS-26) DEADLINE EXTENSION
5. COURSE ANNOUNCEMENT (FAULT-TOLERANT DISTRIBUTED COMP.)

   [Full text of this issue can be found on CRVAX, cd RISKS: ,
   file FTCSNEWS.9 , or from ftcsnews@snowy.crhc.uiuc.edu (FTCS NEWS).
   The deadline for discount registration for FTCS-92 is 25 June.  PGN

Please report problems with the web pages to the maintainer

Top