The RISKS Digest
Volume 19 Issue 53

Tuesday, 6th January 1998

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Sun Valley ski area forgets to back up
David Kipping
Debit-card program cancelled because of fraud
Steve Bellovin
Japanese bank records stolen
Steve Bellovin
Easter Eggs in Commercial Software
Larry Werring
Pharmacy computer keys on names, mixing confidential records
MCImail spam blocker adds to woes
Michael M. Krieger
Spammers blackmail AOL
Stephan Somogyi
Sending the wrong message with flowers
Bear Giles
Re: What really happened on Mars Rover Pathfinder
Ken Tindell
Fred Schneider
Re: Adjust your defibrillator
Richard Cook
Re: Has Microsoft already infected itself?
David M. Chess
Eric Cholet
ERCIM-FMICS 3 - Call for papers
Diego Latella
Info on RISKS (comp.risks)

Sun Valley ski area forgets to back up

David Kipping <>
Wed, 24 Dec 1997 12:09:16 -0500
The Sun Valley ski area in Idaho has a high-tech ticketing system.  You buy
a season discount pass for a small fee and get a card with photo and bar
code.  To ski you then pay for the day (at a discount).  There is no paper
ticket as all information is in the ticketing computer.  When you are ready
to get on the ski lift, an attendant scans your pass with a hand-held
terminal, your bar code is sent to the ticketing computer by radio, the
computer validates that you have paid for the day, and the result is sent
back by radio to the hand-held terminal.  All this happens in less than a
second.  The pass database is built up over several months as passes are

During the week of 14 Dec 1997, the hard disk on the ticketing computer
failed and the ticketing database was destroyed.  The computer hardware was
quickly repaired, but there was no backup for the ticketing database.  All
pass-holders (several thousand) are required to come to the Sun Valley
offices where personal data is re-entered, new photos are taken, and new
passes are issued.

Debit-card program cancelled because of fraud

Steve Bellovin <>
Sun, 28 Dec 1997 09:22:45 -0500
According to the AP, Burns National Bank (Durango, CO) is cancelling its
debit-card program because of fraud.  The article is maddeningly incomplete
about technical details.

Apparently, the "hackers" (to quote the article) counterfeited plastic cards
and "took account number sequences off software that resides on the Internet
before encoding them in the magnetic strip on the back of the card."  When
the fraud was detected, some customers had new cards issued, with some
unspecified extra security feature.  It didn't work; within a month, the
accounts were penetrated again.

Three other banks have been victimized by a similar scheme.  All four use
the same debit card vendor; Burns blames the vendor for inadequate security,
in some unspecified form.  They're looking for a new supplier; until then,
the entire program is being suspended.  Losses to date — which are
apparently being absorbed by the banks — total $300,000.

Japanese bank records stolen

Steve Bellovin <>
Mon, 05 Jan 1998 11:40:15 -0500
Reuters reports (
that a Japanese bank's computer records were penetrated.  Data on some
customers, including names, addresses, and birthdays, was taken.

The bank says that the problem likely occurred because of a software upgrade
last year.  It declined to release any further details about the software.

An AP report on the incident said that an employee with the firm doing the
software upgrade allegedly offered the data to a mailing-list company.  That
company alerted the bank, saying that the data — which included financial
information — was "too detailed".

Easter Eggs in Commercial Software

Larry Werring <>
Mon, 5 Jan 1998 12:29:09 -0500
Do you know what kind of hidden features are hidden in commercial
applications?  Do you know how much disk space is wasted as a result of
these hidden applications (known as Easter eggs) within commercial
applications?  What do Easter eggs have to say about project management,
quality control and configuration management of the company developing
products containing the Easter eggs?  How much extra is the consumer paying
for products to cover the cost of developing these hidden and utterly
useless applications?  How much time is being wasted by employees at the
expense of their employer (usually the customer who paid for the
application) to look for and play with these Easter eggs? What other unknown
features are embedded within commercial products? Can you trust any
commercially developed product?  What follows are two examples of Easter
eggs hidden within commercial applications (I have used Microsoft products
only to demonstrate how elaborate an Easter egg can be).

Example 1:

Open Excel 97.
Open a new worksheet and press the F5 key.
Type X97:L97 and press the Enter key.
Press the Tab key.
Hold Ctrl-Shift and click the Chart Wizard button on the tool bar.
Once the Easter egg is activated, use the mouse to fly around - right
button for forward, left for reverse.

Note: If you don't have DirectX drivers installed you will only get a list
of developer names.  If you do, you will encounter a flight simulator.  Can
you find the focal point of the virtual region with the scrolling display?

Example 2:

Open Internet Explorer.
Select "About Internet Explorer" from the help menu.
Hold down the Ctrl key and use the mouse to select and drag the "e" in the
upper right hand corner onto the picture of the Earth and release the Ctrl key.
Hold down the Ctrl key again and use the mouse to drag the "e" so that it
pushes the words "Microsoft Internet Explorer 4.0" out of the way and
return the "e" to the planet earth.
If it hasn't already started to run, press the "unlock" button to see a
display of all the IE 4.0 development team.

Note: This Easter egg is lengthy.  The author has attempted to interject
humour at various points in the display but has failed miserably.  In fact,
the author admits to a crime committed by one or more members of the team
(theft of construction sign - remember the teenager convicted of multiple
counts of manslaughter for stealing a traffic sign).  Also, at the very end
of the display, the author impugns the character of several team members
(basis for possible defamation of character suit by the individuals?).  I'll
bet that this Easter egg was never approved by the IE 4.0 project manager or
Bill Gates.

So-called Easter Eggs are hidden within many Microsoft applications (Windows
95 and NT, for example).  However, other products apparently have them as
well (e.g. Netscape and Macintosh System 7.5 for example).

I remember the days when every line of code was examined before we would
allow a program to be used in a trusted environment.  This was deemed too
expensive so now we "trust" software creators.  How can you "trust" any
commercial product sold by a major manufacturer when it can be demonstrated
that many products from the manufacturer include hidden applications and
possibly functions as part of the product.

Note:  I addressed an e-mail about this to Microsoft's Security guru's but,
as usual, got nothing back but an acknowledgement of receipt.

Larry Werring, IT Security Consultant

Pharmacy computer keys on names, mixing confidential records

<[identity withheld by request]>
Weds, 24 Dec 1997
I suffer from an embarrassing medical condition, treatable only by expensive
medication that has no other uses in adults.  If you buy the medication, in
other words, you probably have the condition.

My doctor phoned a prescription in to the local CVS.  Ninety minutes later,
I showed up to collect it.  I told the pharmacist my name, and she handed me
the medication.  She then told me my insurance had expired in January 1997,
and I would therefore have to pay the full price.

I explained to her that my insurance (through an HMO) is very much in force
but doesn't cover drugs, and that she obviously had bad information,
presumably from CVS' computers.  Both my given name and surname are fairly
common in the U.S.A.; there are at least four others with my first and last
names in the local area.

She refused to believe me at first, changing her mind only when I pointed
out that it wasn't my address her computer had printed on the receipt.  She
then took back the medication, asked for my name, date of birth, address,
telephone number, and medical allergies.  Irked, but wanting to avoid a
fight, I tendered information to her satisfaction, paid for the medication,
and left the store.

Apparently, when the prescription came in, CVS simply assumed that it must
have been for the person with the same name already in their system.  I can
think of at least five risks of this sloppy system:

1.  If the other guy's insurance hadn't expired, I could have scammed
    free or nearly-free medication on his (insurance's) dime.

2.  If I hadn't asked what was going on, his records at CVS would show
    that he obtained medication for an embarrassing medical condition.

3.  Since I'm quite certain the CVS technician didn't call back to
    disabuse them, his old insurance now thinks he obtained medication
    for an embarrassing medical condition.  If I had been getting the
    equally distinctive drugs for HIV, such a disclosure could have quite
    serious consequences for the poor sap.

4.  CVS' database includes information on patients' allergies to
    medication.  The pharmacist didn't ask me whether I had any
    allergies until after I established that she was working from
    the wrong record.  Their vaunted system for tracking patients
    will not work to the extent they are mixing up people with the
    same name.

5.  Immediately distrustful of CVS, I gave the pharmacist a false
    address, phone number, and date of birth.  Now there are five
    locals with my first and last name.

Silver lining: at least they don't key on the Social Security Number.

  [... although that can beneficially disambiguate...  PGN]

MCImail spam blocker adds to woes

"Michael M. Krieger" <MKRIEGER/0005975596@MCIMAIL.COM>
Thu, 25 Dec 1997 22:26:39 -0500 (EST)
MCI Mail's new anti-spam filter option depends on a non-optional system
change MCI's Internet gateway makes to subscriber addresses when sending
outbound messages; this yields undesirable consequences, perhaps worse than
the original spam problem.

In particular, MCI Mail created a (probability ---> 1.0) Risk of its users
being sitting ducks for spammers when it switched to sequentially assigning
the traditional seven digit 123-4567 address/ID's to new accounts (in lieu
of spacing them out).  This allows automated spam addressing, e.g., the
Internet addresses <>, <>, ...

To overcome this, MCI Mail recently gave its users the option to block
numerically addressed messages (e.g., <> in my case),
while making
          <username/> a new acceptable address format.

Because "username" (which is a user's logon, e.g., "jsmith") is not public
(nor susceptible to automated deduction from the 7-digit address),
over-spammed MCI Mail users can invoke the filter while giving
<username/> to friends and other correspondents.

All well so far.  But "to complement the new filtering capability," MCI
Mail now converts (NON-optionally) its members' addresses to the new
format when messages exit the gateway into the Internet
  "so that if you did invoke the filter, your correspondents could still
   use their "reply" function and capture your address in a way that won't
   be impacted by the filter.  This change will take effect on Nov. 24."
   [quotes from MCI Messaging Notification, to Users on 12 Nov 1997]

Oops! Shouldn't this have been optional too?
Might not an MCI Mail user's intended Internet recipient have him/herself
already implemented blocking rules or filtering mechanism which will reject
   <username/> as unknown?

The obvious Risks are failed messages (some of which likely won't even yield
rejection notices) and corresponding business and personal loses, the burden
of resubscribing to listservs which can no longer recognize you, etc.
Moreover, in the future changing a "username" will mean resubscribing to
lists, and other administrative overhead.  Good way to drive off customers.

Perhaps most detrimentally, this forces the user's "username" into the
clear.  Although MCI Mail defaults new users to "jsmith" format, that can
be changed arbitrarily to anything, e.g., "smartestjsmith."  One might wish
to keep it private (account logon is the "username" and, if unique within
the MCI Mail system, "username" can also replace 123-4567 within MCI Mail,
as part of Internet addresses, etc.).

Finally, with time listmakers and spammers will capture many "username"'s
after which they will be even more difficult for users to elude than before!

Michael M. Krieger

Spammers blackmail AOL

Stephan Somogyi <>
Wed, 31 Dec 1997 16:31:30 -0500
  [Via the IP list of Dave Farber <> ]

CNN's been reporting this on Headline News today, but no reference to it on
their Web sites. However, the LA Times has the following on the subject:



A small snip of the LA Times article:

The opposing interests of electronic commerce and individual privacy erupted
in conflict Tuesday after a small Internet business group threatened to make
public the e-mail addresses of 1 million of America Online's 10 million
users if the giant service continues to bar the businesses from pitching
their products online to AOL members.  The Chino-based National Organization
of Internet Commerce said it would post the e-mail addresses on its own Web
site at the stroke of midnight Wednesday, making them available for
downloading by any business, group or individual seeking to make mass
electronic mailings.  The organization said it would leave the names posted
for 24 hours unless AOL offered small businesses a way to reach its 10
million members through inexpensive electronic means.

Sending the wrong message with flowers

Bear Giles <>
Fri, 2 Jan 1998 15:39:57 -0700 (MST)
At the FTD website (, the links for "get well" and "funeral"
arrangements are adjacent.  No problem with new mice driven by someone under
no stress, but with an older mouse and frazzled nerves it would be easy to
click "funeral" instead of "get well" — something that would not be
pleasant for the viewer.

The risk is that page layout for interactive media is different than
non-interactive media.  Something which works well, when simply read, may
have serious flaws when it requires a person to interact with it in
real-world conditions.

Bear Giles <>

Re: What really happened on Mars Rover Pathfinder (Jones, R-19.49)

Ken Tindell <>
Fri, 12 Dec 1997 19:16:15 -0000
>This scenario is a classic case of priority inversion.

So classic that it has happened before many times in many projects.  And I
fear will continue to happen. Today, people are building critical real-time
systems based on Windows NT. But NT doesn't implement priority inheritance.
Instead it contains a "priority randomizer" which randomly selects tasks and
alters their priorities in the hope that eventually the priority inversion
goes away. Whilst this may be adequate for a general-purpose computer in a
workstation environment, this is unlikely to be adequate for a critical
real-time system.

>For the record, the paper was:
>L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
>Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
>vol. 39, pp. 1175-1185, Sep. 1990.

I must point out that their work appeared much earlier in technical reports
and conference proceedings and was widely cited before the 1990 paper
appeared.  Interested readers might like to read the following paper, which
gives an historical perspective on when major results were made available:

  "Fixed Priority Scheduling: An Historical Perspective", Audsley, Burns,
  Davis, Tindell, Wellings, Real-Time Systems journal, March 1995, Volume 8,
  No. 2/3, pp. 173-198.

I find it outrageous that engineers in 1997 are building critical systems
that contain serious defects that were detectable and correctable ten years
ago. I do wonder at what point failure to be aware of these risks
constitutes negligence.

What really happened on Mars Rover Pathfinder (Mike Jones, R-19.49)

"Fred B. Schneider" <fbs@CS.Cornell.EDU>
Mon, 5 Jan 1998 18:29:27 -0500 (EST)
Readers of RISKS could get the wrong impression about who did what and when
from what David Wilner is reported to have said in Mike Jones' item on the
Mars Pathfinder mission in RISKS-19.49.  This note attempts to provide some
missing information.

Jones' Mars Pathfinder article ends with:


   David [Wilner] also said that some of the real heroes of the situation
   were some people from CMU who had published a paper he'd heard presented
   many years ago who first identified the priority inversion problem and
   proposed the solution.  ...

   For the record, the paper was:

   L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols:
   An Approach to Real-Time Synchronization. In IEEE Transactions on
   Computers, vol. 39, pp. 1175-1185, Sep. 1990."

Actually, a "priority inheritance" protocol can be found in

  B. W. Lampson and D. D. Redell.
  Experience with processes and monitors in Mesa.
  {\it Communications of the ACM},
  vol. 23, no. 2, pp. 105--117, February 1980.

which is a reprint of a paper that appeared in Dec 1979 (7th ACM Symposium
on Operating System Principles).  Below is the relevant excerpt; it is
almost — but not exactly — what Sha et al. investigate.

   "4.3  Priorities

     In some applications it is desirable to use a priority scheduling
   discipline for allocating the processor(s) to processes which are not
   waiting.  Unless care is taken, the ordering implied by the assignment
   of priorities can be subverted by monitors.  Suppose there are three
   priority levels (3 highest, 1 lowest), and three processes P_1, P_2,
   and P_3, one running at each level.  Let P_1 and P_3 communicate using
   a monitor M.  Now consider the following sequence of events:

    P_1 enters M
    P_1 is preempted by P_2
    P_2 is preempted by P_3
    P_3 tries to enter the monitor, and waits for the lock
    P_2 runs again, and can effectively prevent P_3 from
     running, contrary to the purpose of the priorities

     A simple way to avoid this situation is to associate with each
   monitor the priority of the highest-priority process which ever enters
   that monitor.  Then whenever a process enters a monitor, its priority
   is temporarily increased to the monitor's priority..."

So, it would be incorrect to credit Sha et al. for first *identifying* the
problem or for first *proposing a protocol* to solve it.  Lampson & Redell
do not give any quantitative analysis of their prio scheme, though.

The development of this thread of research in real-time scheduling is
accurately described in section 5 of Audsley et al., as noted by Ken Tindell.

A parable comes to mind.  School children in the U.S. are taught that
"Columbus discovered America".  Ultimately they learn that Columbus
was preceded by, among others, the Vikings.  So why aren't they taught
that "The vikings discovered America"?  Perhaps it is because when
Columbus discovered America, it stayed discovered.

Re: Adjust your defibrillator (McGraw, RISKS-19.52)

Richard Cook <>
Fri, 26 Dec 1997 08:40:50 -0600
Gary McGraw seems surprised that implantable defibrillators can be
externally programmed and hopes that there are some safety mechanisms
available to prevent unintended or maliciously intended reprogramming. I
encounter these devices in my daily practice and want to provide a little
background for other readers of RISKS.

Actually, these devices are pretty much the definers of what is the state of
the art in medical electronics. I know of no other information technology in
medicine (including all the monitoring and lab system technology that we
have studied and written about over the years) that has anything like the
reliability and robustness of heart pacers and defibrillators.  It may be
interesting for readers to know that, until very recently, the only way one
could become a candidate for an implantable defibrillator is to have had a
documented episode of sudden cardiac death, i.e. to have had ventricular
fibrillation. Needless to say, this kept the potential recipient pool small:
few people survive the initial event!

The devices have a number of features that are tuned to individual patient
characteristics, and they are re-tuned over time. What one is trying to do
is to assure that the device will sense fibrillation and fire but not fire
when fibrillation is not actually present. It can be uncomfortably startling
to be defibrillated when nothing is really going on, and these devices have
lots of program dedicated to making sure that a shock is really indicated.

For this reason, programming of the devices is an essential feature — you
can't really use them effectively without being able to interrogate them,
reset various features and tune them in a number of ways. Gary's claim that
this is a source of risk is surely true, and it is one (but only one) reason
that the guys who make these things are so heavily invested in reliability
and safety. In fact, I suspect that this sort of device is less a model of
what can go wrong and more a model of what actually can be done well not
only in medical devices but with technology in general. But it is always
useful to keep in mind that the people walking around with these things have
already had at least one major lesson in coping with risk! This is the only
device, besides a coffin, that I know of that you have to die to get!
                                           Cognitive Technologies Laboratory
Richard I. Cook, MD, Department of Anesthesia and Critical Care, University
of Chicago; 5841 S. Maryland Ave., MC 4028; Chicago, IL 60637 1+773-702-5306

Re: Has Microsoft already infected itself? (Brown, RISKS-19.52)

"David M. Chess" <>
Tue, 6 Jan 98 09:19:49 EST
> Can anyone explain what this string is doing in WWINTL32.DLL

That is a string that occurs in the "DMV" Word macro virus.  It is present
in that DLL almost certainly in order to allow Word for Office 97 to
recognize that virus in infected Office95-format files, so that it can avoid
bringing the virus along when it converts to Office 97 format.  There are a
number of different virus-fragments in that DLL.  (This has in fact led to a
certain amount of confusion.  It is accepted practice in the anti-virus
community to always mask or otherwise trivially encrypt such virus
search-strings so as to avoid false positives and user suspicions; that was
not done in this case, obviously.)

Knowing too much, too obviously, about the enemy is often enough
to get you suspected yourself...  *8)

David M. Chess, High Integrity Computing Lab, IBM Watson Research

  [Also commented on by Eric Florack <>.  PGN]

Re: Has Microsoft already infected itself? (Brown, RISKS-19.52)

Eric Cholet <>
Wed, 24 Dec 1997 20:02:14 +0100
Well, I examined my copy of the same file, and found a bunch of such strings:

You have been infected by the Alliance
This one's for you, Bosco
echo y|format c: /u
Parasite Virus 1.0
Where's the Gerbil of bubby?
Now, where's that Gerbil of bubby?
Hi sexy!
Description : On FileOpen, detect documents masquerading as templates,
  warn user and optionally restore them to documents

My guess is that they're simply virus signatures used by Word's macro virus
detection code.  Still, where's the Gerbil of bubby ?

Eric Cholet <>

ERCIM-FMICS 3 - Call for papers

Diego Latella <>
Mon, 5 Jan 1998 15:46:27 +0100 (MET)
                         FIRST CALL FOR PAPERS
              Third ERCIM International Workshop on
       Formal Methods for Industrial Critical Systems (FMICS)
                Centrum voor Wiskunde en Informatica (CWI)
           CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
                             May 25-26, 1998

The First International Workshop on Formal Methods for Industrial Critical
Systems took place in Oxford on March 19, 1996, and the second edition was
held in Cesena on July 4-5, 1997. The Third International Workshop will take
place in Amsterdam on May 25-26, 1998.

The aim of the FMICS workshops is to provide a forum mainly intended for,
but not limited to, researchers of ERCIM sites, who are interested in the
development and application of formal methods in industry. In particular,
these workshops should bring together scientists that are active in the area
of formal methods and interested in exchanging their experiences in the
industrial usage of these methods. They also aim at the promotion of
research and development for the improvement of formal methods and tools for
industrial applications.

Please notice that the FMICS workshop will be held in the same week as the
ICDCS98 conference, which will also be held in Amsterdam.

Authors are invited to send five copies of a full paper (in English, up to
25 pages) to the Programme Chair:
  J.F. Groote, CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands
by February 15th, 1998. An electronic version of the paper in Postscript
format plus an abstract should also be sent to:

  W.J. Fokkink - University of Swansea - UK
  G. Kolk - Holland Railconsult - NL
  S. Smolka - State University of New York - Stony Brook, USA

  J.F. Groote - CWI - NL (Chair)
  F. Gnesi - CNR/IEI - Pisa, IT
  D. Latella - CNR/CNUCE - Pisa, IT
  R. Mateescu - CWI - NL
  A. Poigne - GMD - Bonn, G
  J. Tretmans - University of Twente - NL

Informal participant proceedings will be distributed at the workshop.

Deadline for submission:  15 February 1998

Up-to-date information will appear at

Please report problems with the web pages to the maintainer