RISKS@CSL.SRI.COM.UUCP (12/17/86)
RISKS-LIST: RISKS-FORUM Digest, Tuesday, 16 December 1986 Volume 4 : Issue 30
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Arpanet outage (Andrew Malis)
Dynamic Signature Verification (Robert Stroud [and Brian Randell])
Wobbly skyscrapers and passive vs. active controls (Niall Mansfield)
Re: The Audi 5000 problems (Matt Smiley)
Modifying bank cards (Rodney Hoffman)
Credit card mag strips (Ted Marshall)
Fast-Food Computing (Edward Vielmetti)
"bugs" (Doug McIlroy, Jonathan Clark, Bob Estell)
*** NOTE: This issue omits a number of submissions on educational ***
*** testing, computerized discrimination, and other subjects on ***
*** which we seem to have reached the point of limited returns. ***
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: Mon, 15 Dec 86 10:46:48 EST
From: Andrew Malis <malis@ccs.bbn.com>
Subject: Arpanet outage
To: hedrick@topaz.rutgers.edu
Cc: tcp-ip@sri-nic.arpa, malis@ccs.bbn.com
[An earlier message asked, "Why did the Northeast corridor disappear from
the Arpanet last weekend? The Network Operations Center said one trunk had
been broken, and they were cut off from most everyone, too. I thought there
was enough redundancy in the Arpanet to prevent a single trunk from causing
such extensive outage...":]
At 1:11 AM EST on Friday, AT&T suffered a fiber optics cable break between
Newark NJ and White Plains NY. They happen to have routed seven [different]
ARPANET trunks [all] through that one fiber optics cable. When the cable
was cut, all seven trunks were lost, and the PSNs in the northeast were cut
off from the rest of the network. Service was restored by AT&T at 12:12.
The MILNET also suffered some trunk outages, but has more redundancy, so it
was not partitioned.
Andy Malis
[Robert W. Baldwin <BALDWIN@XX.LCS.MIT.EDU> noted: This is a classic
example of redundancy at one level of abstraction that turns out to be
non-redundant at a lower level of abstraction.]
[Redundancy works sometimes: I received several copies of Andy's
note. Yes, this is a lovely example. By the way, AT&T is laying a
fiber-optic cable under the Atlantic. That will provide LOTS of
opportunities for virtually distinct paths to co-occupy the same
physical channels. PGN]
------------------------------
From: Robert Stroud <robert%cheviot.newcastle.ac.uk@Cs.Ucl.AC.UK>
Date: Tue, 16 Dec 86 12:15:20 GMT
To: risks@csl.sri.com
Subject: Dynamic Signature Verification
There was an article in The Independent recently (2nd Dec 1986) about
dynamic signature verification and "the arrival of biometrics as a practical
security technology". A company called AI Transaction Security from
Cambridge have produced a gadget called Securisign, two of which are being
used to control access to "a very secure area" at the EEC's headquarters.
[EEC is European parliament]
The article concluded as follows:
"Dynamic signature verification has turned up one disappointment.
Researchers originally hoped that signature pads could test the sobriety of
people such as nuclear plant operators when they signed on for a shift.
However, research shows that most people can sign their names convincingly
even when hopelessly drunk". [Copyright (c) 1986 Newspaper Publishing PLC]
I found this last comment interesting because the last time this topic came
up on RISKS, I recall that the consensus was that the technology did not
work because you had to sign your name very carefully, i.e. not when you
were "tired and emotional". However, when I showed the article to Brian
Randell, he told me the following anecdote:
Some years ago, I was involved (in an official capacity) in reviewing a
research project, at a Laboratory which I would prefer not to identify, on
dynamic signature verification. I was given a demonstration of the system,
which involved my being asked to sign my name five times, and then being
asked to sign again to confirm that the system had now "learnt" and could
recognise my signature. Much to the consternation of the demonstrator, my
entirely unpremeditated reaction was to turn to a colleague, and ask him to
sign my name. Without any prior warning or practice, he roughly imitated
what he could recall of my hand movements, without attempting to reproduce
the written appearance of my signature. The machine accepted his efforts as
my signature. I was then informed, in tones of considerable embarassment,
that in an effort to speed up the demonstration, the thresholds had been set
low, and that all would be well if they were reset and I gave an adequate
number of signatures. So, they were reset, and I gave (more than) the
requested numbers of signatures. To my surprise, the demonstrator expressed
surprise when I indicated that I felt it appropriate to repeat my
experiment, and again challenged my colleague to repeat his "feat" -
something he did immediately and effortlessly!
The point of this story is that this struck me as an elementary check to
make on dynamic signature verification systems - yet I do not recall ever
seeing claims, in any of the (admittedly popular) articles I have read on the
topic, regarding the ability of the system to defeat attacks based on seeing
how a person signed his/her name. [End of Brian's story]
------------------------------
Date: Mon 15 Dec 86 17:28:20 N
To: RISKS@CSL.SRI.com
From: Niall Mansfield <MANSFIEL%EMBL.BITNET@WISCVM.WISC.EDU>
Subject: Wobbly skyscrapers and passive vs. active controls
PGN in RISKS-4.26
> This raises interesting questions about the relative precision, accuracy,
> and soundness of "metal algorithms" and comparable analog devices in general.
If you change the scene a bit and take a mildly absurd example, you could
have the same sort of considerations in a desk lamp - either use a normal
passive Anglepoise type, or a hi-tech computer-controlled active
servo-postioned type lamp. I'd reckon that the old fashioned lamp would
behave itself it power cuts (although not very brightly), electrical storms,
glitchy mains periods, the last day of february of the year 2000, etc.,
whereas I wouldn't be at all surprised if the robot lamp went berserk
sometime and brained me or smashed my teeth in because the chap next door
started radio broadcasting.
For whatever reason - perhaps that we have had such or similar artifacts for
centuries - we are confident and "know" that passive devices made of metal
tubes and weights and springs are not sensitive to various outside effects
which DO affect computers and consequently computer controlled devices, and
if only because they behave resonably, (i.e. as we expect them to) such
passive devices have a great safety advantage.
------------------------------
Date: Tue, 16 Dec 86 00:52:37 PST
From: crash!pnet01!msmiley@nosc.ARPA (Matt Smiley)
To: crash!risks@sri-csl@nosc.ARPA
Subject: Re: The Audi 5000 problems
Audi did more damage with the '...there isn't anything wrong.' statement than
could be done by simply saying they don't know what it is. Statistically, the
rate of such accidents with the Audi should be proportional to the rate of
such accidents with other vehicles. It obviously is not, leading me to think
there's some defect in the engineering of the vehicle. I had a similar problem
with an old Ford truck of mine, and it took months for me to figure out that
it was due to a defective motor mount. The torque of the engine would lift it
off the mount and subsequently pull the accelerator linkage to the floor. A
similar oddity could be plaguing the Audis.
...nosc!crash!pnet01!msmiley@NOSC <Matt Smiley>
[The summary list of RISKS-4.1 notes that an Audi investigation was
reported earlier in Software Engineering Notes, but I just noticed that
the reference was wrong: it should have been SEN 11 2 (April 1986). PGN]
------------------------------
Date: 16 Dec 86 08:11:51 PST (Tuesday)
From: Hoffman.es@Xerox.COM <Rodney Hoffman>
Subject: Modifying bank cards
To: RISKS@CSL.SRI.COM
From the Los Angeles Times, Dec. 15, 1986 (Reuters):
COMPUTER 'HACKERS' HELD IN W. GERMANY
WIESBADEN, West Germany -- Police have arrested four computer "hackers" said
to have robbed banks in the Frankfurt area of more than $50,000 by
manipulating cash dispenser cards with a home computer. Hesse State police
said the four, one woman and three men, had been roaming Frankfurt and
surrounding towns since May with a computer plugged into the battery of
their Mercedes limousine. They were arrested at the end of November.
The four hackers bought bank cash cards for $1,500 apiece from their family
and friends, who then notified their bank that the cards had been stolen.
The four then used their computer to change the codes on the cards' magnetic
strip so that they could withdraw more money than the limit set by the cards
from automatic tellers, or to tap other accounts. Under a law on computer
crime passed last August, the four face jail terms of up to five years if
charged and found guilty.
------------------------------
Date: Mon, 15 Dec 86 11:45:59 PST
From: blia.UUCP!ted@cgl.ucsf.edu (Ted Marshall)
Subject: Credit card mag strips
To: risks@sri-csl.ARPA
I have noticed a new trend in the way stores imprint credit card slips.
In the olden days, the embossed numbers and letters on the card were
mechanically transfered to the slip. The only use of the magnetic strip on
the back was for verification of the credit limit.
I have now seen two stores (including the local Radio Shack) where the
mag strip reader feeds data to an electronic cash register which not only
dials-up the bank to verify credit but also prints out the slip for the
customer to sign. Unless the clerk checks the printed information on the
slip against the embossed card, there is no verification of the information.
Credit card companies are making it harder to counterfit the embossed
information on the cards. But a hardware hack can still build a gizmo for
$20 that will copy the magnetic information from a "borrowed" card to his.
He then makes sure the other card gets returned so that the bank isn't
notified. The hack walks into the Radio Shack, buys $1000 worth of stuff
with "his" card, and it gets charged to his friend's account. The only
thing to trace him with is the signature on the slip, and it's easy to
sign your name so that it's close enough for the clerk but no one will
ever trace it to you.
------------------------------
Date: Tue, 16 Dec 86 16:15:04 EST
From: Edward_Vielmetti@um.cc.umich.edu
To: NEUMANN@CSL.SRI.COM
Subject: Fast-Food Computing
ReSent-To: RISK@CSL.SRI.COM
I must have been in the cycle early for McDonald's fast-food intelligent
man-machine systems, according to Guthery's law:
> In an evolving man-machine system, the man will get
> dumber faster than the machine gets smarter.
McDonald's fast food computers (i.e., cash registers) collect all sorts of
data on the individual employee at the counter and on all counter sales as a
whole. They also do not have a <no sale> key that opens up the cash
register, probably to prevent theft. That made it real hard to fix a
mistake without calling a manager to get a key to open the drawer.
Solution? Well, the people I worked with at McD's had been around the
system long enough to figure out how to get around it. Without getting into
too many details of why things were as they were, the easiest way to open
the drawer without a manager was to ring up a sale that gave away a tub of
barbecue sauce for McNuggets and nothing else.
(Hit <promo> <barbecue> <promo> <total> .)
Of course, that messed up the daily statistics some.
Edward Vielmetti, Ex-McDonalds employee, Computing Center Microgroup, U. Mich.
------------------------------
To: RISKS [via farber%huey.udel.edu@relay.cs.NET]
From: doug%btl.csnet@relay.cs.NET
Subject: "bugs"
Date: Sun 14 Dec EST 1986 21:39
plugs Unwanted trash that contaminates output. The classic example is a
cheery advertising blurb like "Welcome to MUCUP Version 2.7,"
which cripples the next program down the pipe.
drugs Unwanted features that contaminate specs; something the cat drug in.
------------------------------
Date: Mon, 15 Dec 86 11:45:51 EST
From: jhc%mtune.UUCP@harvard.HARVARD.EDU (Jonathan Clark)
To: harvard!risks@sri-csl.arpa
Subject: "bugs"
At a recent course I heard Jim Gray of Tandem (seriously) describe two
more bug types:
Heisenbugs: generally transient failure conditions that exist inside
systems. ('I can't let you have this resource now because it has been
locked'.) Typically, when the operation is retried on another processor, it
succeeds because the backup processor is in a different internal state.
Bohrbugs: repeatable failures even when retried on another processor.
Typically these are 'hard errors'.
------------------------------
Date: 16 Dec 86 10:05:00 PST
From: "ESTELL ROBERT G" <estell@nwc-143b.ARPA>
Subject: "bugs"
To: "risks" <risks@csl.sri.com>
"augs" - induced while augmenting a system.
"dugs" - added while fixing other bugs, digging the hole deeper.
"jugs" - portable bugs, bottled and bonded.
"lugs" - which slow down the system [e.g., security features].
"nugs" - little "nuggets" of gold, which didn't pan out.
"qugs" - errors in queues that make batch jobs miss deadlines,
and print files twice, or not at all.
"rugs" - evenly distributed throughout the code, and pervasive.
"tugs" - little interfaces which keep big systems in tow.
"xugs" - alien bugs [like E-Mail penetrations of UNIX systems]
------------------------------
End of RISKS-FORUM Digest
************************
-------