Forum on Risks to the Public in Computers and Related Systems

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

Volume 16: Issue 62

Weds 7 December 1994

Contents

Baby-proof keyboard handling needed

Amos Shapir

Network file race condition

Andrew Koenig

Power failure causes airline check-in chaos

Fernando Pereira

Pepsi promotion misfires - computer error

John Dalbey

Formal verification of the AAMP5 Microprocessor

John Rushby

Re: Formal methods and the Pentium FDIV

Mark Stalzer

Re: Formal verification of INMOS T800

Patrick Campbell-Preston
Mathew Lodge

Re: Formal methods ...

Steve Kilbane
Mark Lomas

Re: Slade's review of Schneier's "Applied Cryptography"

Richard Schroeppel

Self-extracting emacs elisp code

David Blob

Virus time

Dwight Silverman
Zygo Blaxell
Reuven Lerner

Program Announcement - ISOC 1995 Symp. Netw. & Distr. Sys. Security

David M. Balenson

Info on RISKS (comp.risks)

Baby-proof keyboard handling needed

Amos Shapir <amos@nsof.co.il>

Wed, 7 Dec 94 14:09:56 IST

We were having the whole family for a Hannukah party last week.
Grandpa sat at a chair next to the PC (which was up and running
Windows), holding six-month-old May in his arms.  Being a digital kid,
she quickly reached for the keyboard.  By the time we noticed and
managed to turn off the computer, half the system files were gone
(which is what we discovered the next day, when the system started to
behave strangely).

Trying to figure out what had happened, it seems little May could only reach
the bottom line of the keyboard -- but that's where the ALT, ENTER, DELETE
and the arrow keys are!  In Windows 3.1, ALT puts the cursor into the
command menu, ENTER activates the menu item it's on; in some menu, DEL
deletes the marked files...

Amos Shapir  nSOF Parallel Software, Ltd.  Givat-Hashlosha 49905, Israel
amos@nsof.co.il  Tel: +972 3 9388551   Fax: +972 3 9388552

Network file race condition

<ark@research.att.com>

Wed, 7 Dec 94 10:58:06 EST

A story with entertainment value, albeit no clear moral:

A couple of nights ago I was working away at my workstation when the world
(figuratively) collapsed: suddenly all my network connections had gone
haywire.  A little investigation revealed that /etc/hosts, the file that
lists names and IP addresses for the rest of the universe, had become
corrupted: it had huge quantities of null characters in it and very little
useful data.  How had that happened?

After some poking around and much thought, I came to the following
conclusion.  I've recently been setting up some machines for a few of my
colleagues.  The most straightforward way of getting those machines into a
sensible initial state, I thought, would be to restore the dump tapes from
my own machine onto theirs.  After all, I keep my machine in pretty decent
shape.

Of course there was no need to restore my home directory on each machine.
Instead, I told each of the other machines that my home directory was really
a link to the mounted file system that contained my home directory on my
`home' machine.  All pretty routine so far, but that turned out to be cause
number 1.

Cause number 2 was that when I cloned my machine, what I cloned included
/usr/spool, the directory with all the spool files.  That directory includes
files that tell cron, a program that starts background jobs at particular
times, what jobs to start.  That meant that the `midnight' job that normally
ran on my home machine now ran automatically on each of several machines.
Because my home directory was mounted on each of these machines, that job
did its thing simultaneously several times in the same directory.

Cause number 3 was that my midnight job, among other things, extracts a
complete new /etc/hosts file from one of our other servers and installs it.
It checks that what it got is sane, to defend against /etc/hosts becoming
empty when the server is down, but of course it doesn't defend against
having several instances running at the same time.  So what must have
happened is that two of those instances finally hit the same file at the
same time, causing parts of it to overlay other parts and general chaos to
ensue.

Andrew Koenig  ark@research.att.com

Power failure causes airline check-in chaos

Fernando Pereira <pereira@research.att.com>

Tue, 6 Dec 1994 23:21:53 -0500

This Monday, 5 December 1994, I was traveling with a colleague from Denver
Stapleton to Newark on United flight 302, supposed to leave at 6:06 PM. When
we got to the airport at 3:30 (in plenty of time to beat threatened snow),
the baggage check-in agents were not actually checking-in passengers but
simply tagging bags by hand, because a power failure had brought down the
check-in database servers. After the bags where checked in, we were directed
to another agent that looked up the gate for flight 302 on a printout.
Actual passenger seat assignment and check-in was to be done manually at the
gate. Since we were early, we waited at the gate until 5 PM, not wanting to
bug the overworked gate agents until near our scheduled departure. But when
we talked to the gate agent soon after 5 PM, she told us that she had no
information about flight 302; some other flight was due to leave that gate
too close to 6:06 PM to allow time for flight 302, and she had no way of
finding out where 302 was supposed to be. She finally told us to call the
central 800 number for United reservations to check the gate info! My
colleague is a United Premier member. He called the Premier help desk, who
gave him another gate number for a supposedly on-time departure. He
communicated that information to the original gate agent, who proceeded to
announce it over the PA for other 302 passengers without further
confirmation from any other authority.

We went to the new gate, where we found neither plane nor gate agents.
We asked the agent at the next gate for help. He knew nothing about
302, and expected some other flight to use the empty gate. His paper
notes indicated the original gate for 302. But he eventually called
around, and found out yet another supposed gate for the flight.

Third time lucky. That turned out to be the correct gate, although its
electronic flight info display was showing a different flight.  All the
departures monitors in the terminal were also showing outdated and scrambled
information without any indication of its incorrectness. Enterprising gate
agents were taping paper signs with correct flight numbers over the bogus
electronic signs.

But the problems were not over. The plane for flight 302 arrived, we
boarded, and were supposed to leave just 20 or so minutes late. Except that
the flight crew was delayed in an incoming flight, and that information,
normally handled by the downed computer system, was not made available to
the ground staff for assignment of an alternate crew. We ended leaving
around 1 1/2 hour late.

This all happened in a relatively light traffic non-holiday Monday, in
pretty good weather (the snow didn't materialize). I can't imagine
what the chaos would have been like around a major holiday. It was
clear from all our interactions with all the gate agents that they
were not operating according to a well-designed, well-drilled manual
backup procedure. They behaved professionally for the most part in a
difficult situation, but much of what they were doing seemed decided
on the spot, from personal initiative, and without good phone access
to an authoritative manual database of flights and gates, even though
that information was obviously still available to the air-traffic and
airport systems, given that flights were still landing and taking off.

Fernando Pereira, 2D-447, AT&T Bell Laboratories, 600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636  pereira@research.att.com

Pepsi promotion misfires - computer error

John Dalbey <jdalbey@galaxy.csc.calpoly.edu>

Wed, 7 Dec 1994 11:05:27 -0800 (PST)

Time magazine (Aug 9) reports a computer error in a Pepsi promotional
lottery in the Philippines.  The computer generated 800,000 winning numbers
instead of 18.  Obviously, Pepsi didn't pay the $32 billion in prize money
their mistake would have cost them.

Pepsi has paid nearly $10 million in "appeasement" efforts ($20 "goodwill"
prize), but this apparently didn't satisfy disgruntled "winners." Over
22,000 people, each of whom believed they had won the $40,000 prize, have
filed about 5,000 criminal and 700 civil suits.  The Philippine Senate Trade
Committee faults the company for "gross negligence" and "misleading or
deceptive advertising."

If anyone knows any technical details about the nature of this
"computer error," I would like to hear about them.

John Dalbey, Computer Science Dept, Cal Poly, SLO, CA  jdalbey@calpoly.edu

Formal verification of the AAMP5 Microprocessor

John Rushby <RUSHBY@csl.sri.com>

Wed 7 Dec 94 11:41:18-PST

With messages in RISKS about formal verification (not) being applied to
commercial processors, this might be a good time to mention the work that's
going on across the hallway from PGN:

 "Formal Verification of the AAMP5 Microprocessor:
  A Case Study in the Industrial Use of Formal Methods"

  by Steven P. Miller (Collins Commercial Avionics) and Mandayam Srivas (SRI)

  To be presented at WIFT '95: Workshop on Industrial-Strength Formal
  Specification Techniques, April 5-8, 1995, Boca Raton, Florida USA.

Available over the web through http://www.csl.sri.com/aamp5.html
or by ftp from ftp.csl.sri.com/pub/reports/postscript/aamp5.ps.gz

The AAMP5 doesn't have floating point, but it is a real processor with
a pipeline, microcode, and 500,000 transistors (it's a derivative of
the AAMP2, of which there are 30 on board each 747-400).

John

Re: Formal methods and the Pentium FDIV (Lodge, RISKS-16.61)

Mark Stalzer <stalzer@macaw.hrl.hac.com>

Wed, 7 Dec 1994 09:22:40 +0800

The NY Times (or was it LA?) a few days ago reported that the double
precision fdiv problem in the Pentium is due to a table that was incorrectly
copied from the 486 -- not an algorithmic bug.  Many formal approaches would
not have caught this kind of error since it would have been natural to
assume that the table was correct (I mean, after all, it was generated by
computer!) Also, one of the floating point bugs in a previous x86 processor
(I think it was the atan bug in the 486) was due to electrical difficulties
-- the algorithm was correct, but the electrons had different ideas in a
certain case. This is a class of errors that only testing or circuit
simulation with accurate device models can catch.

Mark Stalzer, mas@acm.org

  [Also noted by "Jeffrey P. Bradford" <jbradfor@ecn.purdue.edu>, who added,
     "We all know computers make mistakes, either HW or SW, and any results
     from computers need to be compared against common sense."  PGN]

Re: Formal verification of INMOS T800 (Lodge, RISKS-16.61)

Patrick Campbell-Preston <PATRICKCP@shapel.ug.eds.com>

Wed, 07 Dec 1994 13:33:12 -0300 (BST)

When the T800 came out, my then employers (FEGS Ltd) were working on a
research project in collaboration with INMOS and several other partners.

At one point INMOS told us they had had to halt production of T8's after
a bug had been found in the floating-point microcode, resulting in the
wrong result being given for some IEEE-defined special case (I think
it was zero divided by zero giving the wrong flavour of NaN). I think
the bug was found by the formal verification process, of which they were
certainly very proud.

One more point is worth mentioning: the T800 is a very simple chip
architecture compared to something like the Pentium, and I would guess
formal verification of the latter would be a much larger task.

Patrick

---

Re: Formal verification of INMOS T800 (re Patrick Campbell-Preston)

Mathew Lodge <lodge@ferndown.ate.slb.com>

Wed, 7 Dec 94 17:53:40 GMT

Perhaps this is a case of less RISK for RISCs! (sorry, couldn't resist)

Inmos formally proved only the FPU: they didn't do it for the whole
processor.  Does the Pentium implement so many more floating point
operations that proof is intractable?

Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown,
Dorset, UK, BH21 7PP  lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404

Re: Formal methods ... (Lodge, RISKS-16.61)

Steve_Kilbane <steve@cegelecproj.co.uk>

Wed, 7 Dec 1994 08:56:00 +0000

Proving that the algorithms used are correct is one thing, but getting a
correct implementation of those algorithms in silicon is another, and that's
where the testing comes in.

Steve_Kilbane@cegelecproj.co.uk

---

Re: Formal methods ... (Lodge, RISKS-16.61)

<Mark.Lomas@cl.cam.ac.uk>

Wed, 7 Dec 1994 18:08:02 GMT

Some staff from Inmos gave a talk here some time ago on their procedure for
verifying a floating-point implementation.  Their experience was slightly
more interesting than Mathew suggested.

Apparently, in addition to their formal model they had a "known correct"
implementation built by a competitor.  All tests were verified against
this reference implementation.

At one point during testing they found that their implementation disagreed
with the reference implementation and spent quite some time trying to diagnose
the fault.  It turned out that their implementation had been correct first
time, but that they had discovered a bug in a competitor's product.

No prizes for guessing who built the reference implementation

    Mark

Rob Slade's review of Schneier's book "Applied Cryptography"

"Richard Schroeppel" <rcs@cs.arizona.edu>

Wed, 7 Dec 1994 13:27:37 MST

Rob Slade's review of Schneier's book "Applied Cryptography" should have
mentioned that the book contains a substantial number of typos, and that
Schneier offers an errata sheet (schneier@chinet.com).  This will be
especially important if you try to use the programs in the appendix.  I like
the book.

Rich Schroeppel   rcs@cs.arizona.edu

Self-extracting emacs elisp code

David Blob <blob@syl.dl.nec.com>

Wed, 7 Dec 1994 11:57:50 -0600

With all this talk about self extracting mail "viruses", a friend showed me
that in emacs (which I use to read mail, along with vm) has the ability to
self-extract elisp code.  This feature seems to be turned on by default, and
it not only applies to mail read with emacs, but rather every file visited
(when the feature is on, of course).

The way it works is by having a line which reads "Local Variables:" followed
by the lisp variables you would like to set...well, it may seem petty, but
you can execute programs, make connections and much more through cleverly
written elisp code contained within.

It's simple to turn off, at any rate...

(setq enable-local-variables  f) ;; turns off feature  (in emacs 19)
(setq enable-local-variables  1) ;; makes it ask first (in emacs 19)
(setq inhibit-local-variables t) ;; turns off feature  (in emacs 18)

Anyhow, I think the risks here speak for themselves...

Virus time

Dwight Silverman <Dwight.Silverman@chron.com>

Tue, 6 Dec 1994 21:05:18 -0600 (CST)

Shareware has a bad rap as a carrier of computer viruses. But one of the
commercial software industry's dirtier little secrets is that viruses
often get transmitted via shrink-wrapped boxes in stores.

Or, sometimes, viruses just get sent to computer writers.

A California company called Bit Jugglers called me today to say a title
they'd sent me, Kids World, was infected with a virus. This only happened
to the copies sent to the press -- those folks who write about computer
software in magazines or newspapers. The virus did not make it into
copies shipped to stores.

Bit Jugglers urged me to destroy my copy of Kids World. And if I'd
installed the software (I have not), they would have sent me the latest
version of McAfee's Scan, a virus detection program. A new, clean copy is
on its way to my desk.

The moral of the story is obvious. Trust NO floppy -- you don't know where
it's been. Scan everything.

Dwight Silverman

The Houston Chronicle, Computer columnist  dwight.silverman@chron.com
713-220-6873   Fax: 713-220-7273  Audiotext: 713-468-7866 ext. 1001

---

Virus _IS_ virus alert (Berlinger, RISKS-16.61)

Zygo Blaxell <zblaxell@miranda.uwaterloo.ca>

Wed, 7 Dec 1994 03:41:04 -0500

> I have received it 4 times now from different sources.)

Obviously, the alert itself _is_ the virus.  Watch:

<>I have just received this message and been asked to take it seriously:

This gets the virus scheduled on the CPU (note that it occurs at the
beginning of execution).

<>There is a virus on America Online being sent by E-Mail.  If you get

This is the target architecture and operating system: AOL users.  Note that
it also works on similar architectures with different operating systems.

<>anything called "Good Times", DON'T read it or download it.  It is a
<>virus that will erase your hard drive.

This is something that looks like a useful message to fool the user while
the virus does its work.

<>Forward this to all your friends.
<>It may help them alot.

...and this is the propagation code. ;-)

Zygo Blaxell, Math student at the University of Waterloo.
System/network admin for the Computer Science Club and miranda.

---

Good Times

Reuven Lerner <reuven@hpwadck.wal.hp.com>

Wed, 7 Dec 1994 09:51:05 -0500

I'm sure that I am not the only RISKS reader who has been bombarded by
warnings regarding the supposed "Good Times" virus.  Just about all of
the warnings I received were forwarded from two or three previous
people, said that the virus was distributed from America On-Line, and
claimed that if you were to download or read the message (which had a
subject of "Good Times"), your hard disk could be reformatted.

Each copy of the warning then suggested that people forward the
warning to as many other users and mailing lists as possible, because
of the severity of the problem.

I've seen at least one announcement from CIAC (at least, I *think* it
was from CIAC) telling people that there is indeed no virus, that most
mail readers won't automatically execute programs sent via e-mail, and
that people generally shouldn't worry.

There seem to be several risks associated with this incident:

(1) People don't understand what e-mail can and cannot do.  Most of
    the people forwarding the warnings didn't understand the
    difference between viewing a mail message and turning the contents
    of that message into an executable program, let alone the fact
    that different platforms work differently and thus would require
    separate viruses.

(2) Rumors spread quickly.  I was amazed to see just how fast this
    rumor spread; within a 24-hour period, I saw a dozen or so copies
    of the warning on five or six different mailing lists.  People
    wanted to help their fellow users (a good thing), but passed the
    warning on without verifying the rumor's validity (a bad thing).
    You could probably make a good argument that the warning itself
    was a virus!

(3) Explanations spread slowly.  More than two days after I first saw
    the virus warning, people continued to forward copies of it to
    various mailing lists -- even after I and others told list members
    that the virus announcement was probably a hoax.  It will probably
    be another few days before the CIAC warning (along with assurances
    from computer experts) reaches all of the people who are no longer
    sure whether it is safe to read their e-mail.

(4) Bugs do exist.  The fact is that there probably are holes in mail
    readers that will do nasty things to people's files and accounts.
    But now that people have been told not to worry, they'll take
    future warnings less seriously.  Without a universally known and
    trusted authority on these issues -- and let's face it, most users
    would probably trust their friends more than CIAC or CERT -- this
    may turn into the computer equivalent of the children's story,
    "The Boy Who Cried Wolf."

Reuven

Program Announcement - ISOC 1995 Symp. Netw. & Distr. Sys. Security

"David M. Balenson" <balenson@tis.com>

Wed, 07 Dec 1994 13:57:48 -0500

David M. Balenson, Program Co-Chair, ISOC '95 SNDSS
Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA
balenson@tis.com; tel 301.854.6889; fax 301.854.5363

                    THE INTERNET SOCIETY SYMPOSIUM ON
                 NETWORK AND DISTRIBUTED SYSTEM SECURITY
                         16-17 FEBRUARY 1995
                 CATAMARAN HOTEL - SAN DIEGO, CALIFORNIA

The symposium will bring together people who are building software and/or
hardware to provide network and distributed system security services.  The
symposium is intended for those interested in the more practical aspects of
network and distributed system security, focusing on actual system design
and implementation, rather than in theory.  We hope to foster the exchange
of technical information that will encourage and enable the Internet
community to apply, deploy and advance the state of the available security
technology.

                 P R E L I M I N A R Y   P R O G R A M
           [meals, breaks, registration info removed by PGN]

WEDNESDAY, FEBRUARY 15

6:00 P.M. - 8:00 P.M.
REGISTRATION AND RECEPTION

THURSDAY, FEBRUARY 16

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
OPENING REMARKS

9:00 A.M.
SESSION 1: DIVERSE APPROACHES TO SECURITY AT THE NETWORK LAYER
Chair: Stephen T. Kent (Bolt, Beranek and Newman, USA)

    Multicast-Specific Security Threats and Counter-Measures, Tony
    Ballardie and Jon Crowcroft (University College London, United
    Kingdom).

    Design of a Key Agile Cryptographic System for OC-12c Rate ATM,
    Daniel Stevenson, Nathan Hillery, Greg Byrd, and Dan Winkelstein
    (Microelectronics Center of North Carolina - MCNC, USA).

    IpAccess: An Internet Service Access System for Firewall
    Installations, Steffen Stempel (University of Karlsruhe, Germany).

11:00 A.M.
SESSION 2: PANEL: SECURITY ARCHITECTURE FOR THE INTERNET INFRASTRUCTURE
Chair: Robert W. Shirey (The MITRE Corporation, USA)

    Security for the Internet Protocol (IP) and IP Next Generation,
    Paul A. Lambert (Motorola, USA).

    Security for the Internet Domain Name System, James M. Galvin
    (Trusted Information Systems, USA).

    Security of Routing Protocols in the Internet, Gary Scott Malkin
    (Xylogics, USA).

    Security Approaches to Routing in the Internet, Sandra L. Murphy
    (Trusted Information Systems, USA).

2:00 P.M.
SESSION 3: OFF-LINE OBJECT DISTRIBUTION SECURITY
Chair: Jeffrey I. Schiller (Massachusetts Institute of Technology, USA)

    Trusted Distribution of Software Over the Internet, Aviel D. Rubin
    (Bellcore, USA).

    Location-Independent Information Object Security, John Lowry (Bolt
    Beranek and Newman, USA).

3:30 P.M.
SESSION 4: INTERNET PAYMENTS
Chair: Ravi Ganesan (Bell Atlantic, USA)

    Electronic Cash on the Internet, Stefan Brands (Centrum voor
    Wiskunde en informatica - CWI, The Netherlands).

    PANEL: Internet Payment Mechanisms - Requirements and Architecture
    Chair: Ravi Ganesan (Bell Atlantic, USA)
    Panelists: B. Clifford Neuman (Information Sciences Institute, USA),
    David Crocker (Brandenburg Consulting, USA), and others TBD

7:00 P.M. DINNER BANQUET

FRIDAY, FEBRUARY 17

8:30 A.M.
SESSION 5: SECURITY MONITORING TOOLS - PRACTICE AND EXPERIENCE
Chair: Michael St. Johns (Advanced Research Projects Agency, USA)

    NERD: Network Event Recording Device: An Automated System for
    Network Anomaly Detection and Notification, David G. Simmons and
    Ronald Wilkins (Los Alamos National Laboratory, USA).

    An Overview of SNIF: A Tool for Surveying Network Information Flow,
    Jim Alves-Foss (University of Idaho, USA).

    Distributed Audit Trail Analysis, Abdelaziz Mounji, Baudouin Le
    Charlier, Denis Zampunieris and Naji Habra (Facultes Universitaires
    de Namur - FUNDP, Belgium).

10:30 A.M.
SESSION 6: AUTHENTICATION AND AUTHORIZATION
Chair: B. Clifford Neuman (Information Sciences Institute, USA)

    SESAME V2 Public Key and Authorisation Extensions to Kerberos,
    Piers McMahon (ICL, United Kingdom).

    Yaksha: Augmenting Kerberos with Public Key Cryptography,
    Ravi Ganesan (Bell Atlantic, USA).

    GSS-API Security for ONC RPC, Barry Jaspan (OpenVision
    Technologies, USA).

1:30 P.M.
SESSION 7: MECHANISMS OF IDENTITY - THE CERTIFICATE INFRASTRUCTURE
Chair: Hilarie Orman (University of Arizona, USA)

    A Certificate Management System: Structure, Functions and
    Protocols, Nada Kapidzic and Alan Davidson (Stockholm University &
    Royal Institute of Technology, Sweden).

    PEMToolKit: Building a Top-Down Certification Hierarchy for PEM
    from the Bottom Up, Alireza Bahreman (Bellcore, USA).

    A New Approach to the X.509 Framework: Allowing a Global
    Authentication Infrastructure Without a Global Trust Model, Suzan
    Mendes (TS-E3X - Research and Development Center, France) and Christian
    Huitema (INRIA, France).

3:30 P.M.
SESSION 8: PANEL: SECURITY ISSUES FOR MOSAIC AND THE WORLD WIDE WEB
Chair: Fred Avolio (Trusted Information Systems, USA)
Panelists: Peter J. Churchyard (Trusted Information Systems, USA),
  Allan M. Schiffman (Enterprise Integration Technologies, USA), and
  Bill Cheswick (AT&T Bell Laboratories, USA)

GENERAL CHAIR
    James T. Ellis, CERT Coordination Center, Carnegie Mellon University

PROGRAM CO-CHAIRS
    David M. Balenson, Trusted Information Systems
    Robert W. Shirey, The MITRE Corporation

FOR MORE INFORMATION, contact Gloria Carrier by phone at (703)-883-4508 or
via email to gcarrier@mitre.org.

Report problems with the web pages to the maintainer