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 12 Issue 7

Tuesday 16 July 1991


o RISKS: US West 10x charges users
o Houston City Hall voice-mail prank
S. Spenser Aden
o Re: Risks of posting to newsgroups
Li Gong
o 1992 IEEE Symposium on Research in Security and Privacy
John McLean
o Puzzle Boxes: Reply to comments
Ross Williams
o Info on RISKS (comp.risks)

RISKS: US West 10x charges users

Mon Jul 22 13:26:27 1991
Heard on KIRO radio this morning:

US West has implemented a new computer system to time long distance calls more
closely.  The new system, according to US West representatives, will "save long
distance customers considerably in the long term."  For the short term,
however, it will cost them extra.

The system breaks calls down to the nearest 6-second period, rather than
charging the caller for a full minute when only part was used.  However, a
programming error caused all bills sent out between July 7th and 10th to be
computed at 10 times the normal rate.  The error was not discovered until 12
days after the system became active.

US West representatives said that "customers who pay the (incorrect) bill will
be credited on their next bill."

Houston City Hall voice-mail prank

"Peter G. Neumann" <>
Sat, 20 Jul 91 14:42:23 PDT
Houston acquired an AT&T telephone system in 1986 for $28M, but configured it
with no passwords required for accessing voice mail.  Thus, it should not
surprise any of you to hear that recently a "prankster intercepted and rerouted
confidential telephone messages from voice-mail machines in City Hall,
prompting officials to pull the plug on the telephone system."  Messages were
being delivered to nonintended recipients.  [Source: San Francisco Chronicle,
20Jul91, p.A5]

   [Also noted by Steve Bellovin]

The voice-mail shuffle at City Hall

Tue, 23 Jul 1991 8:51:05 CDT
... A few stations even played quick snippets from one message, which appeared
to be a kind of verbal "love letter" left for someone.  Needless to say, the
intended recipient was not the actual recipient.  The perpetrator evidently
would somehow try to simlulate a message break tone before each misdirected
message by whistling a tone on the recording.

While some of the redirected messages were, in some people's opinion, harmless,
others were matters of City and State affairs, and the ramifications of these
messages not being received were more than trivial.  Needless to say, the
service was down the next day for "upgrade modification".

As one newscast put it at the end of their story, "when you leave a message at
City Hall, don't leave one you wouldn't want repeated in public."

S. Spenser Aden, Lockheed Engineering and Sciences Co.   (713) 483-2028
NASA -- Johnson Space Center, Houston -- Flight Data and Evaluation Office

Re: risks of posting to newsgroups

Li Gong <>
Wed, 17 Jul 91 16:01:27 EDT
I remember seeing a report that someone was surprised to find out that his
opinion posted to RISKS, a USENET newsgroup, was quoted in a book.  I just got
the following message from a mailing list's book review section:

ELECTRONIC MAIL ON CHINA.  Vol. 1 (February 18 to June 3, 1989) & Vol. 2 (June
4 to July 4, 1989).  Edited by Esbjorn Stahle & Terho Uimonen.  Stockholm:
Skifter utgivna av Foreningen for Orientaliska Studier, 1989.  pp. 394 & 424.

Reviewed by Zhenqin Li

    This two-volume publication is very unusual, in the sense that it is
perhaps the first ever book almost entirely based on articles of a Usenet
newsgroup (soc.culture.china or SCC).  It should be of interest to a wide
readership on the computer networks ...

[Li Gong, ORA Corporation, 675 Mass Ave, Cambridge, MA]

1992 IEEE Symposium on Research in Security and Privacy

Mon, 22 Jul 91 12:12:48 EDT
                               CALL FOR PAPERS
1992 IEEE Symposium on                                 May 4-6, 1992
Research in Security and Privacy                       Oakland, California

                                 sponsored by
                              IEEE Computer Society
                    Technical Committee on Security and Privacy
                             in cooperation with
             The International Association for Cryptologic Research (IACR)

The purpose of this symposium is to bring together researchers and
developers who work on secure computer systems.  The symposium will
address advances in the theory, design, implementation, evaluation and
application of secure computer systems.  Papers, panel session
proposals, and position papers are solicited in the following areas:

  Secure Systems       Privacy Issues     Information Flow
  Network Security     Formal Models      Viruses and Worms
  Database Security    Access Controls    Security Verification/Validation
  Authentication       Data Integrity     Auditing & Intrusion Detection

Send six copies of your papers, panel session proposals, and position
papers to John McLean, Program Co-Chair, at the address given below.

We provide ``blind'' refereeing.  Put  names and affiliations of
authors on a separate cover page only.  Abstracts, electronic
submissions, late submissions, and papers that cannot be published in
the proceedings will not be accepted. Papers submitted from outside
North America should be sent via Federal Express or other overnight
courier service.

Papers must be received by November 8, 1991 and must not exceed
7500 words.  Authors will be required to certify prior to December 20,
1991 that any and all necessary clearances for publication have been
obtained.  Authors will be notified of acceptance by January 24, 1992.
Camera-ready copies are due not later than February 28, 1992.

The Symposium will include informal poster sessions.  Poster session
papers will appear in a special issue of Cipher that will be published to
coincide with the symposium.  Send one copy of your poster session paper
to David Bailey, Cipher editor, at the address given below, by January 31,
1992.  Electronic submission of the latex source for poster session papers
is strongly encouraged.  Poster session authors must send a certification
with their submittal that any and all necessary clearances for publication
have been obtained.

A limited number of scholarships will be available for student authors.

                          PROGRAM COMMITTEE
David Bailey, Los Alamos   Jeremy Jacob, Oxford   John McHugh, UNC
Tom Berson, Anagram        Sushil Jajodia, GMU    Catherine Meadows, NRL
Martha Branstad, TIS       Dale Johnson, MITRE    Jon Millen, MITRE
George Dinolt, Loral       Paul Karger, OSF       Dan Nesset, Livermore
John Dobson, Newcastle     Tanya Korelsky, ORA    John Rushby, SRI
Jim Gray, NRL              Steve Lipner, DEC      Ravi Sandhu, GMU
Tom Haigh, SCTC            Teresa Lunt, SRI       Elizabeth Sullivan, Amdahl
                                                  Yacov Yacobi, Bellcore


Deborah Cooper, General Chair            John McLean, Program Co-Chair
Unisys Corporation                       Naval Research Laboratory
5731 Slauson Avenue                      Code 5543
Culver City, CA 90230                    Washington, DC 20375
Tel: (213)338-3727                       Tel: (202)767-3852         

Teresa Lunt, Vice Chair                  Richard Kemmerer, Program Co-Chair
SRI International, EL245                 Computer Science Department
333 Ravenswood Avenue                    University of California
Menlo Park, CA 94025                     Santa Barbara, CA 93106
Tel: (415)859-6106                       Tel: (805)893-4232               

Jeremy Jacob, European Contact           David Bailey, Cipher Editor
Oxford Univ. Computing Laboratory        USDOE, WQD
11 Keble Road                            PO Box 5400
Oxford, England OX1 3QD                  Albuquerque, NM 87115
Tel: +44 865 272562                      Tel: (505)845-4600
Fax: +44 865-273839            


Date: Fri, 19 Jul 91 1:17:57 CST
From: Ross Williams <>
Subject: Puzzle Boxes: Reply to comments.

I am extremely grateful for the many comments I have received following my
posting to comp.risks on my puzzle box idea. I have also received some postings
forwarded by Peter Neumann.

Because of the volume of mail, the common themes of several of the comments,
and the possibility of keeping interested comp.risks readers up to date, I have
decided to reply in a posting. I will quote only from those who posted, as I do
not think I should quote from private email. If you send me email on this topic
and are happy to have it quoted in comp.risks, please say so.

So far, I have not received any fatal technical arguments. However, some
messages quote examples that may constitute prior art.

If prior art does exist, I would be interested to know how much puzzle boxes
are actually used in practice in safety-critical device interfacing. Most of
the "prior art" messages I received quoted applications in areas such as
password protection and operating system page protection. Whether or not the
puzzle box idea is original, I believe it to be useful, and would like to see
it used in safety-critical systems. Judging from the reactions I have received,
it seems likely that the puzzle box idea (if well known) has been underused in
practice because of an erroneous perception that the technique is subject to a
single-point software failure (see below).

A copy of my puzzle box provisional patent application is available by email
upon request (i.e. I can email it to you).

Ross Williams,, 18-Jul-1991

Single Point Software Vulnerability
Most of the mail I received stated that a system employing puzzle boxes is
vulnerable to a single-point software error. Lars-Henrik Eriksson's posting is
typical of the messages that raised this objection:

   From: Lars-Henrik Eriksson  <>
   Date: Wed, 17 Jul 91 09:58:42 +0200
   The microprocessor must have a program to send the proper code
   sequence. Both hardware and software failures might cause this program
   to run accidentally. It should be safer than having a single bit
   activate the hardware device. However, it is not clear to me that
   having the microprocessor send a very complicated code sequence such
   as the solution to the Hanoi puzzle is any better than just having it
   send a very simple sequence such as the three numbers 1, 2, 3. In both
   cases there must be a program to generate the sequence, and in both
   cases that program could be entered accidentaly.

The essence of the objection (in the above and other messages) is that if a
puzzle box is employed, there will have to be a subroutine (specifically, an
address) which when executed causes the puzzle box to activate. This code
structure introduces a single point vulnerability because all that needs to
happen is for the Program Counter (PC) to somehow get to that address.

I thought of this problem soon after having the puzzle box idea. There is a
paragraph on the topic in the provisional patent application:

   Software Trigger --- A danger arises in systems that use puzzle devices
   if the controlling computer contains a software procedure whose job is to
   activate the puzzle device. The existence of such a procedure implies that
   the system is only as safe as the address in the program counter register of the
   computer. This may not be acceptable. This problem can be countered by
   using the results of calculations (performed in the computer) leading up to
   the decision to activate in the actual puzzle device activation sequence

The essence of the solution is contained in the quote, but I will flesh it out
further as this was the most common objection.

As far as I can see, a good way to protect systems from accidentally entering
certain "dangerous" states is to engineer a tortuous path from "normal" states
to the "dangerous" states. The puzzle box does this in hardware. The same trick
can be pulled in software.

All of the readers raising the single point software failure objection assumed
that there MUST exist a single subroutine whose execution causes the
unconditional activation of the puzzle box. This need not be so.

To provide a "tortuous" software activation path, we need to create some
distance in the microprocessor state space between the "normal" and the
"dangerous" states. Under the above assumption, the distance is just 16 to 32
bits of highly dynamic PC register! To expand the state space, we can create a
memory array called firing_sequence.

   firing_sequence : array[0..31] of byte;

At regular intervals (e.g. during interrupts (with care!)), this array could be
zeroed by a routine called (say) reset_puzzle_box. A second routine called
fire_puzzle_box writes the array firing_sequence to the puzzle box output port.

In any critical system the decision to "fire" will usually be a complex one
requiring a number of checks to be performed. As each successive check is
passed, the system moves closer to the firing state. For a system that employs
a puzzle box, the process can include writing values into the firing sequence
array. Thus the various logical decisions that culminate in the decision to
fire each contribute part of the "password".

In fact, under certain conditions, you can build the firing sequence into the
decision code itself.

   procedure pour_tea;
   begin pour_tea
   if teapot_temperature


Please report problems with the web pages to the maintainer