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 2

Thursday 9 January 1992


o UK Government security breach
Robert Jenkins
o Landlord's software chokes on identical check numbers
Jon Weintraub
o The "Miracle" computer-controlled piano teaching system
Ed Nilges
o Gambling machines scramble checking facility
George Michaelson
o Re: Life-and-Death Computer
Tom Perrine
Bob Kerns
o Re: Snow at San Jose ???
Alan Marcum
Christopher Pettus
o Re: Customer Clogs Honda 800 Number
Sanford Sherizen
o Re: Screensaver doing "nothing"
Bill Davidsen
A. Padgett Peterson
o Re: ZIP+4
Kraig Meyer
Ed Wright
Brad Templeton
John J. DiLeo
o Risk Assessment for Aviation Safety — a request
Peter C Olsen
o Rampant Virology — a book by Mark Ludwig
Ray Kaplan
o Info on RISKS (comp.risks)

UK Government security breach

Robert Jenkins <>
Wed, 8 Jan 92 20:52 GMT
The Guardian of 8 January carries the following report, headlined
"Security Flaw in Whitehall":

Fake names were fed into a Whitehall [i.e., central government] computer to
give unauthorised staff access to details of top security safes holding cabinet
papers and sensitive defence documents, an investigation by the National Audit
Office, parliament's financial watchdog revealed yesterday.

The issue of security furniture, such as filing cabinets for classified
documents, was "left in the hands of an inexperienced officer who had virtually
unlimited control of the system and was not effectively supervised," says the

It goes on: "Control over access to the computer system was minimal; staff who
were no longer authorised to use it, and two fictitious names thought to have
been entered by a previous employee, continued to have access.

"Staff training was inadequate, procedures were not documented, and inaccurate
stock information was leading to the posting of wrong figures to the accounts.
The staff were unable to generate invoices for equipment and substantial
amounts had consequently not been charged. At least one duplicate payment,
amounting to 92,000 pounds, had been made to a supplier."

The report said there was no evidence of fraud, "but the serious lack of
control, and the limited audit trails, made it impossible to provide an
unconditional assurance that it had not."

Landlord's software chokes on identical check numbers

Jon Weintraub <>
Thu, 9 Jan 92 12:48:53 -0600
My landlord has been `politely threatening' us since the first of the year for
overdue rent.  After careful checking, the problem was that both my roommate
and I each happened to pay with a check numbered 144 from our respective
accounts.  The computer supplanted its record of the first check with its
record of the second — it was counting on check serial number to be a unique
identifier across accounts!  If we were less lucky, we might be in court over
this by now.

The "Miracle" computer-controlled piano teaching system

Tue, 7 Jan 1992 17:11:16 GMT
This morning (7 Jan 1992) on the Today show, the "Miracle" computer-controlled
piano teaching system from the Software Toolworks was demonstrated for
announcer Katy Couric.  This is a high-quality electronic piano and software
running on several platforms (including the Mac and the PC) which teaches piano
by lessons and by monitoring play on a key-by-key basis.  It was the subject of
some reasonably smarmy ads as Yuppie parents watched, eyes glistening, as their
Little Darlings played rather complicated pieces reasonably well.  The
performance in the ads has been borne-out by tests of the system; it is a good
way of teaching piano skills, interpreted as being able to play the music on
the page.  Thereby, however, lies a potential Risk to music aesthetics.

For when Katy Couric played a decent version of "Happy Birthday", including
some rather elegant grace notes, the computer gave her a low score of 38%.
This is it could not recognize the slight improvisation represented by grace
notes as an improvement over the music displayed on the screen.  In my opinion,
a good piano teacher would give Couric a higher score for the creativity
implicit in grace notes.

More than this, the developers of "The Miracle" seem unaware of the fact that
Playing The Music Exactly As Written (PTMEAW) is (in a global sense) not the
usual practice.  Not only is folk music almost completely improvised, Indian
classical music gains much of its richness from being IN PART improvised by
master musicians every time it is performed.  Even in the Western classical
tradition, improvisation was the norm prior to the Baroque era.  Deliberate
error, even, has played an extensive part in music.  Italian and German
violinists of the 17th century used a system of deliberately "incorrect"
tuning, called "scordatura", by which the Baroque composer Biber gained much
emotional intensity in his violin sonatas.  Up until Beethoven the
instrumentalist in a concerto provided a "coda" in which the soloist could
improvise on the theme, so PTMEAW was not even the norm in Mozart's time.

Nowadays, although classical music is subject to PTMEAW (with the absurd stress
on "original instruments" being part of this), non- classical music, including
folk, rock and country gains much of its liveliness by retaining both
improvisation and "scordatura" (that is, deliberate error for emotional

"The Miracle" completely ignores this by assigning high scores in a dehumanized
fashion to students who, unlike Couric, don't have the creativity to improvise.
I predict that two types of populations will evolve on "The Miracle":
unimaginative keyboarders of the music as written, and hackers, who will misuse
the features.  In neither group will true musicians be found.

"The Miracle" does look like a useful tool for learning music, but I object
both to its operatic name, which makes an overlarge claim, and to its
incorporation of numeric scoring.  The designers could have (under the advice
of a decent musicologist) deliberately eschewed the assignment of numeric
scores and restricted themselves to the display of natural-language

Gambling machines scramble checking facility

George Michaelson <>
Tue, 7 Jan 1992 10:02:53 +1100
ABC Radio (Australia) reported this morning that different manufacturers "one
armed bandits" (in-line gambling machines) confuse the centralized checking
systems to which they are networked, and destroy each others records.

This has delayed installation of the systems in clubs and hotels around the
state of Queensland, until new code can be put in to ensure they can be checked
up on.

Worry about abuses of the machines for gambling, tax evasion and links with
crime (for money laundering, and alleged mafia involvement in the manufacture &
distribution) has been a big political football here.

Re: Life-and-Death Computer

Tue, 7 Jan 92 11:03:13 PST
The Washington Post editorial in Risks 13.01 (Subject: Life-and-Death
Computer) overlooked one other problem with the APACHE software: it
has the potential to generate self-fulfilling prophecies.

It appears that APACHE is really reporting on patient "profiles": age,
weight, general medical condition, cross-referenced with specific
complaints or injuries and treatments and survival rates.

Since APACHE reduces people to profiles, we might as well use that
term in discussion.

Lets say that a "profile" is not treated with a given procedure, in part due to
the "advice" of APACHE, and then dies.  If the information concerning this
"profile" is then fed back into the APACHE database, this will decrease the
"survivability" quotient for subsequent "profiles" with the same initial set of
problems.  Each time a patient (oops, "profile") with a given complaint is not
treated (and dies), the survival quotient decreases again.

Each time APACHE (indirectly) advises a doctor to withhold treatment for a
condition, it increases the probability that it will "advise" withholding
treatment for the next patient (oops, "profile") with the same basic
complaint/injury, leading to another death, leading to another survival
quotient decrease.

The editorial remarks that "a computer can serve the cause of accurate
diagnosis only on the basis of properly entered information by the physician
using his or her senses".  Even if data is 100% correct, it still leads to
positive feedback which will further skew the output data.

Tom Perrine (tep), Logicon - T&TSD, P.O. Box 85158, San Diego CA 92138
                   +1 619 597 7221  UUCP: sun!suntan!tots!tep

Life-and-death computer: Numbers lie

Wed, 8 Jan 92 06:12:15 -0500
In RISKS 13.01, Warren McLaughlin cites a Washington Post article about
programs which give highly-precise probabilities on medical treatment outcomes,
and how this can lead to doctors relinquishing their proper decision-making

It seems clear to me that the problem here isn't that the doctor
is relinquishing his responsibility by being too trusting of the
software, so much as it is the programmer is relinquishing the
responsibility to the doctor by presenting bad information.

The problems inherent in encoding weights for different courses of action (or
any other "non-monotonic" comparison) is very familiar to anyone familiar with
expert systems.  In addition to the illusion of accuracy illustrated in the
article, there are numerous other kinds of error introduced at every step, from
the initial assignment of weights for the raw data (what is a "favorable
outcome" in treatments to prolong life in a terminal disease), observed
situation (what is "slight swelling of the lymph nodes"), anomolies when these
are reasoned on in conjunction with each other (often you can prove a>b>c>a),
and then, finally, in the way they are reported.

Assuming that these problems are dealt with in a realistic manner, for the
program to communicate reasonably with the doctor, it is necessary to give some
idea of the precision of these numbers.  One of the better techniques is to use
"error-bars".  This can help transform what appears to be a definitive

Cut off head:  40%
Give aspirin:  30%
Cut off foot:  20%


 -Treatment-   0   10   20   30   40   50   60   70   80   90  100
Cut off head:  |-------------------X----|
Give aspirin:       |---------X--------------|
Cut off foot:       |----X--------------|

As you can see, this makes it much more clear that the
program really hasn't decided much of anything at all.

It should also be clear from my example that in addition to the numerical
information, an explanation of the reasoning process together may well be
warranted, to check for any unwarranted assumptions, and other things to look
out for.  (Such as the need for reattaching the head after repairs are
effected, and the assumption that the patient is a robot).

(The disease in question, of course, is "headache").

In real life, a doctor giving a second opinion isn't just going to give a
number.  He's going to give reasons, and an idea how sure he is of the
appropriateness of a particular treatment and alternative treatments and even
perhaps alternative diagnosis to consider.  [Or maybe the insurance industry
has this process reduced to a coded number now too, in which case, the Risks
should be obvious].

The deceptive problems of encoding preferences and subjective evaluations into
numbers is, of course, a pervasive problem in other areas.  Indeed, the entire
area of risk analysis is rife with it, as I've pointed out indirectly in other
messages.  It's so much easier to calculate with simple numbers that this is a
very tempting trap to fall into.  But we must resist the temptation to
manufacture certainty where non exists.  Whether we are computer professionals,
scientists, pollsters, or journalists, or newspaper reader I think being
careful with these issues is a matter of professional integrety.  It's an
integrety which is all too often lacking, out of ignorance, sloppiness, desire
to persuade, or desire to be persuaded.

         [finger rwk@... suggests this might be someone named Bob Kerns.  PGN]

Re: Snow at San Jose ??? (Pettitt, RISKS-13.01)

Alan M. Marcum - Tech Support <Alan_Marcum@NeXT.COM>
Mon, 6 Jan 92 14:47:46 PST
> 1) a decode error (I don't know what the correct decode of VBSY is)
> 2) VBSY does mean snow and spray and the NWS screwed up the forecast.

There's a third possible cause, which I guess I'd call the probably
cause.  Someone made a typographical error.  VSBY is the contraction
for visibility.  BSY could well translate to snow and blowing spray.

For the RISKS folks, note also that the translation Contel provides
is made available as a courtesy.  They have a large disclaimer
stating this, and requesting that the pilot acknowledges his
responsibility for correct translation according to the relevant
portions of the Federal Aviation Regulations.

There is the RISK, though, of typos in critical information with little or no
redundancy, such as the FAA's cryptic weather information.

Alan M. Marcum, NeXTedge Technical Support, amm@NeXT.COM

Re: Snow in San Jose ??? (RISKS-13.01)

Christopher Pettus <cep@Apple.COM>
6 Jan 92 21:57:25 GMT
>Either way computer weather briefing has a way to go yet.

Indeed.  One of the problems with computerized decoding of National Weather
Service (NWS) weather information is that the format, while supposedly
standardized, is actually typed in by humans with no checking in a pretty
free-form format.  In this case, the answer is both (1) and (2).

A terminal forecast has two parts, an 18-hour "forecast" and a 6-hour
"categorical outlook" (although even weather briefers are often unaware of the
difference).  The forecast is relatively detailed: the clouds are going to be
at 4000 feet, it's going to be raining, the visibility is going to be 5 miles
in fog, etc.

The categorical outlook is pretty generic, and just makes braod claims about
the weather, in particular ceilings greater than 3000', visibility greater than
6 miles, etc.  If the visibility is expected to be restricted, "VSBY" is put
into the categorical.

In this case, the forecaster expected the visibility to be at three miles, so
he stuck a 3 in the categorical (free-format, no checking).  This is not a
meaningless thing to do, since three miles of visibility is a "magic number"
(it allows flight operations that might otherwise be prohibited).

This isn't what the "official" format allows, so the program decided
that it had just hit a standard notation for visibility, where the
visibility is given in miles, then followed by letter codes for what
kind of goo is restricting the visibility (for example, "2RF" means
"visibility 2 miles in rain and fog").  "S" is snow, "Y" is spray, and
"B" in front of a code means "blowing," and the "V" I assume was
ignored, so we have "Visibility 3 miles in snow and blowing spray."

The whole weather reporting system is based on ancient 110-baud teletype
technology, and is in desperate need of being trashed and redone.  But it
probably will not be for many years.

-- Christophe

Re: Customer Clogs Honda 800 Number

Mon, 6 Jan 92 22:06:51 PST
It is pretty well established that such abuse of an 800 number (or any number
for that matter) constitutes harrassment.  In the famous case of the guy doing
this to the tele-evangelist, I believe that the caller was prosecuted, found
guilty, and had to make some sort of restitution.

Keep in mind that virtually all 800 (and 900) customers already receive the
caller's number for about 95%+ callers via the carriers' Automatic Number
Identification (ANI) systems (this is actually different from Caller-ID, but
the distinction is too complex to elaborate on here).  Only larger customers
usually receive this information in real-time with the call, but most receive
the caller numbers with their phone bills, or sometime after the call via other
means, and abusive patterns can be clearly seen in such data.

Customer Clogs Honda 800 Number (Cont.)

Sanford Sherizen <>
Wed, 8 Jan 92 01:54 GMT
There is more about this incident.  According to the TAB, a very good local
newspaper in this area, Daniel Gregory has been charged with telephone
harassment after he made at least 100 phone calls in one day and faxed a 14-foot
computer banner saying "Dan Gregory is unhappy with his Honda."  Gregory
admitted making the calls.  "It could have been as many as 100 in one day," he
DA." (Emphasis added by me to highlight why the U.S. is in decline)

He made a comment about the long fax.  "A roll of fax paper is $12 at Staples
(office store).  We're talking about a multi-million dollar company getting mad
because I use a lot of fax paper?"

While this story has received some coverage around the U.S., it has been treated
as if it is a funny story.  Some form of man-bites-Honda.  The fact is, however,
that this incident shows a vulnerability of technology.  Is this phone clogging
almost a virus-type phenomenon?  Can it be possible on a larger scale?  Say
someone doesn't like their boss, the Internal Revenue, their ex-spouse, a
political candidate, a computer network, or some other party.  Then "la-de-da"
is the right response.

For all we know, Gregory may run for national office on the La De Da Platform.
Oop, sorry, I think that political platform is already taken by at least one
other candidate for president.

Sanford Sherizen, Data Security Systems, Inc., Natick, MA 01760 USA

Re: Screensaver doing "nothing" might be a resource hog

bill davidsen <>
Wed, 8 Jan 92 09:12:47 EST
  Also note that "screensavers" and "lock screen" programs can use a lot of
ethernet bandwidth if you run them on X terminals. This can actually be enough
of a factor to measure, particularly if you have a site where people tend to
lock a lot of terminals at night while the administration is trying to take
dumps over the net.

bill davidsen   (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
  GE Corp R&D Center      Moderator and 386-users digest.

ScreenSavers & Resource Hogs (Swartz, RISKS-13.01)

A. Padgett Peterson <>
Tue, 7 Jan 92 09:28:30 -0500
The comments concerning the effects of a screensaver on a Sun station brings
to mind a couple of incidents that occured a few years ago on our Vax systems.

The first involved a brand new, state-of-the-art VAX 11/780 and a digital
"clock" (with alarm). A short (50 or 60 lines) DCL program, it was quite
popular until it was found that four simultaneous "clocks" would swamp
the 1 VUP 780 and cause logins to take upwards of five minutes.

The second was a program that used QIO and QIOW calls (never could get all
of the commas straight without help) that enabled the VAX to function as
a terminal emulator. Add in a Racal-Vadic 1200 baud (great improvement over
300 baud Silent 700s) modem and it was possible to debug systems in New York
from my desk in Florida. With a TekHex conversion, binary traffic was also
possible (this was before XMODEM, KERMIT, or UUENCODE programs were available
so everything was "home grown" but worked) so we could make "on-line" fixes
to a Mil-Std-1750A program.

Trouble was that in order to make a multitasking system operate as a terminal,
constant cyclic checking of the workstation port and the output port was
necessary. As a result the program was something of a hog and we were politely
requested to only use it when necessary, preferably after hours.

In any event, one Friday an engineer left work with his terminal still running
the program (this was a *long* time ago) even though the phone was hung up.
Three weeks later we got the bill for that weekend from the computing center:
$32,000.00 for resources used. Needles to say some frantic negotiations ensued.

Of course the high cost of VAX time back then is what financed the PC
revolution here so it wasn't all bad, just "there is nothing new under the Sun"

Re: ZIP+4 (RISKS-13.01)

Mon, 06 Jan 92 15:38:39 PST (Douglas W. Jones,201H MLH,3193350740) writes:
>I recently asked at my post office how many houses shared the same ZIP+4 code
>with my house.  The answer was that if I lived in a single-family dwelling, I
>almost certainly have a unique ZIP+4 code.

[Unique ZIP+4] was not the intended or actual implementation of ZIP+4 that I'm
familiar with.  Generally, the last 4 digits indicate which block the address
lies in (or sometimes additionally, which side of the block).  My parents live
in a subdivision in Michigan with one acre lots, and they share their ZIP+4
code with 1/2 miles' worth of single family dwellings, because that is the
distance between the two cross streets.  The other side of the street has a
different ZIP+4 code, even though all of the mailboxes are on the same side of
the street.

Check out a ZIP+4 directory at your local post office to see who you share your
ZIP with.
                                        Kraig R. Meyer

    [Also noted by the following: (John R. Levine) (Randal L. Schwartz) (Craig Seidel) (J. Dean Brock) (Arthur Goldstein) (John Sullivan)
    and PGN himself, who owns a ZIP+4 that is unique — which
    is the case for box numbers in small post offices.  PGN]

Re: ZIP+4 (RISKS-13.01)

Ed Wright <>
Thu, 9 Jan 92 10:21:53 PDT
The Zip + 4 system gets your letter to the correct carrier,
correct side of the street, correct two block segment.

Soon Zip + 6 will emerge (its under test now) and that will give each
address a unique numeric sequence.

Re: ZIP+4 (RISKS-13.01)

Brad Templeton <>
Tue, 7 Jan 92 20:26:22 PST
Actually, rather than letting people mail to me with my Zip+4 (which only
specifies some people exactly and not others) I would rather the post office
(and other shippers) implement a scheme where I can get a unique code (number
or alpha), perhaps of my choice, which identifies my address in Post Office
computers, and only there.

People would be able to mail to:  Code: foobazbarx, U.S.A.

And the mail would get to me.  The P.O. would be pledged never to reveal where
I actually live except on court order.  In fact, the actual information should
only be available in the local post office computer — other computers would
only know which local post office to send mail for foobazbarx.

Naturally, you could have more than one code, if you wish to pay.  Mailers
would be free to add more redundant information, but you would want a check
letter (the x) on the end so that people who take down your address can be sure
they have it right when they are talking to you.

There's a real way to use computers to preserve your privacy, and make mailing
and address transcription easier, too.

Re: ZIP + 4 codes

"John J. DiLeo" <>
9 Jan 92 23:56:16 GMT
...  For the more stout-hearted (and those to whom the CD-ROM is not available),
all government depository libraries should have a full set of printed
directories (I filed them in the depository stacks at Johns Hopkins when I was
a student employee there).  Entries are listed by: 1)City name/Post Office
name; 2) Street name/P.O. Box group; and 3) numerically by block numbers.

John DiLeo,

Risk Assessment for Aviation Safety

Peter C Olsen <>
Wed, 8 Jan 1992 02:30:30 GMT
I'm doing a strategic study on aviation security and I'm looking for
information about techniques that might be used to model the threat, risk, and
effectiveness of countermeasures in commercial aviation security ---
particularly airline security.  I am particularly interested in approaches that
might be useful in helping to quantify and refine the qualitative data which
seems to be all that is available.  Similar problems have been addressed by the
people in the computer security and nuclear safety arenas.

I'd appreciate any information or advice.

Please reply to ME via email because I don't follow this newsgroup; I will
summarize if there is any interest.

Peter Olsen
PO Box 410, Simpsonville, MD 21150       202-366-6525 (office)

Rampant Virology

Making memories <>
Wed, 8 Jan 92 20:51 MST
More books to keep you awake at night (I've only seen volume 1 so far.)

The Little Black Book of Computer Viruses, 169 pages, Mark Ludwig, ISBN
0-929408-02-0, $14.95 - American Eagle Publications, P.O. Box 41401, Tucson,
AZ  85717 - (602) 888-4957.  (Thanks to Winn Schwartau for this referal to a
publisher right here in my own town!)

The back cover of this one tells it all:

WARNING.  This book contains complete source code for live computer viruses
which could be EXTREEMELY DANGEROUS in the hands of incompetent persons.  You
can be held legally liable for the  misuse of these viruses, EVEN IF SUCH
MISUSE IS UNINTENTIONAL.  Do not attempt to execute any of the code in this
book unless you are well versed in systems programming for personal computers,
and you are working on an isolated machine.

    Introduction:   "This is the first in a series of three books about
            computer viruses...  All three volumes are full of
            source code...  It is enevitable that these books will
            offend some people ...  The first volume is a
            technical introduction... The second volume discusses
            scientific applications...  The third volume discusses
            military applications ... (And, a lengthy disertation
            on everything from the social meaning of this all to
            the "why do it" of it all (that would play very nicely
            here in RISKS.?))
    Vol 1

    Ch 1 - The basics
        Functional elements
        Tools needed to write viruses

    Ch 2 - Simple COM file infector

    Ch 3 - Sophisticated executable virus

    Ch 4 - Simple boot sector virus

    Ch 5 - Sophisticated boot sector virus

    Appendix 1 - TIMID

    Appendix 2 - INTRUDER

    Appendix 3 - A basic boot sector

    Appendix 4 - KILROY

    Appendix 5 - STEALTH

    Appendix 6 - Hex file loader

    Appendix 7 - BIOS and DOS interupt functions

    Appendix 8 - Suggested reading list

Kaplan's comments:
    1) - "Oh, 


Please report problems with the web pages to the maintainer