Subject: RISKS DIGEST 12.07
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Tuesday 16 July 1991 Volume 12 : Issue 07
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents: [IT'S SUMMER SLOWTIME, IN CASE YOU ARE WONDERING!]
RISKS: US West 10x charges users (patlo)
Houston City Hall voice-mail prank (PGN, S. Spenser Aden)
Re: Risks of posting to newsgroups (Li Gong)
1992 IEEE Symposium on Research in Security and Privacy (John McLean)
Puzzle Boxes: Reply to comments (Ross Williams)
The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to
[email protected], with relevant, substantive
"Subject:" line. Others ignored! REQUESTS to
[email protected]. For
vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 12, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
----------------------------------------------------------------------
Date: Mon Jul 22 13:26:27 1991
From:
[email protected]
Subject: RISKS: US West 10x charges users
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."
------------------------------
Date: Sat, 20 Jul 91 14:42:23 PDT
From: "Peter G. Neumann" <
[email protected]>
Subject: Houston City Hall voice-mail prank
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]
------------------------------
Date: Tue, 23 Jul 1991 8:51:05 CDT
From:
[email protected]
Subject: The voice-mail shuffle at City Hall
.. 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
------------------------------
Date: Wed, 17 Jul 91 16:01:27 EDT
From:
[email protected] (Li Gong)
Subject: Re: risks of posting to newsgroups
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]
------------------------------
Date: Mon, 22 Jul 91 12:12:48 EDT
From:
[email protected]
Subject: 1992 IEEE Symposium on Research in Security and Privacy
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
INSTRUCTIONS TO AUTHORS:
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
FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT:
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
[email protected] [email protected]
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
[email protected] [email protected]
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
[email protected]
[email protected]
------------------------------
Date: Fri, 19 Jul 91 1:17:57 CST
From: Ross Williams <
[email protected]>
Subject: Puzzle Boxes: Reply to comments.
PUZZLE BOXES
============
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,
[email protected], 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 <
[email protected]>
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
itself.
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
read_io(teapot_temperature);
read_io(cup_sensor);
read_io(dormouse_sensor);
read_io(mad_hatter_robot_arm_health);
reset_puzzle_box;
if teapot_temperature<min_temp then
reset_puzzle_box;
else
write_puzzle(firing_value_1);
if cup_sensor=no_cup then
reset_puzzle_box;
else
write_puzzle(firing_value_2);
if dormouse_sensor=under_spout then
reset_puzzle_box;
else
write_puzzle(firing_value_3);
if mad_hatter_robot_arm_health=just_not_well then
reset_puzzle_box;
else
write_puzzle(firing_value_4);
write_puzzle(firing_value_5);
write_puzzle(firing_value_6);
-- Teapot pouring robot arm activated.
-- Enjoy a nice hot cup of tea.
endif
endif
endif
endif
reset_puzzle_box;
end pour_tea
As far as I can see, the code above is not subject to a single point software
failure. There is nowhere to jump to to fire the puzzle box without lots of
checking. Thus, the software and the puzzle box proceed cautiously, hand in
hand, from the safe state to the dangerous state.
Some will say that the above code is messy, but then they have probably never
seen a squashed dormouse! More seriously, the extra code messiness does
introduce new risks and I can sympathize with this point. However, it is a
different point and I hope that the above has well and truly dispatched the
single point software failure argument against puzzle boxes.
I am convinced that formal methods do provide, or will soon provide, the
capacity to deal with "safe" but "messy" code such as the code above (e.g. use
of the Malpas verifier or such programs in the future).
To an extent, the concern with single point software failures is a product of
the "good software engineering" mindset which dictates that there should be a
single routine for firing! I suspect that the single-point objection would not
have been raised so strongly in the 1950's when everyone was a hacker!!!!!
A related criticism comes from Steve Bellovin:
From:
[email protected]
To:
[email protected] (Ross Williams)
Cc:
[email protected]
Subject: Puzzle boxes for critical device interfacing
Date: Wed, 17 Jul 91 14:43:19 EDT
...
A puzzle box is only going to help if the computer must consult external
state in order to perform the correct calculation, and if that external
state varies depending on whether or not activating the device is reasonable.
But if you can make that sort of determination, you're probably better
off using hard-wired logic as an interlock.
--Steve Bellovin
In the tea-party example above, the decisions could just as well have been made
based on internal data constructed in very complicated ways from interaction
with the real world (including other computers in a distributed safety-critical
kernel). In fact the tea party example does just that if you imagine it
starting just after the IO calls.
Separating Concerns
-------------------
A common theme in the messages I received was people making statements of the
form "Puzzle boxes are no good because they are vulnerable to X." For example,
many people seemed to think that the idea was USELESS because of the single
point software problem discussed above, whereas, puzzle boxes would still
provide comprehensive protection against a variety of other kinds of failure,
even if the single-point objection held true. Another common objection was
people saying that I was confusing ease of activation with vulnerability and
that the real problem to be solved is ensuring that the software is correct.
Adding a puzzle box just confuses the issue they said.
The classic example (in my view) of lack of separation of concerns are the
people who think that formally verifying programs is not a useful thing to do
because "there might be bugs in the compiler".
The biggest danger with using a useful technique that has weak points is that
the user may forget about the weak points at some stage, and be lulled into a
false sense of security. This point was raised by a few readers and on this I
concur.
Hardware Failures
-----------------
One or two people criticised the idea on the basis of hardware failures. If the
puzzle box is supposed to provide protection against hardware failures in the
computer and its output interfaces, who provides the protection for the puzzle
box's outputs?
First, the puzzle box may be very much larger and more physically robust than
the microprocessor controlling it. For example, the microprocessor may operate
at 5V and 0.001A whereas the puzzle box may operate at 100V and 2A (using big
clunky relays perhaps). The signals from the microprocessor can be amplified
before being fed into the puzzle box.
Second, unlike computers (which are very complicated), the focus on
puzzle box design can be on ensuring that an N-point failure cannot
cause a transition to the "dangerous" state from a "safe" state. The
Gray code puzzle box I have designed provides such protection by using
isolated switches in series to control the output.
Originality
-----------
This section lists some of the "prior art" examples I received.
An example that was quoted by a few readers was that of some modern
computers/operating-systems that use specially locked pages of memory to hold
critical data structures. In these systems the operating system can set a group
of pages to read-only status. The only way to write to the pages is to send a
complex sequence of bytes to some kind of port. This unlocks the memory for
writing. Afterwards, the OS can lock the pages up again. This system is
different from ordinary memory protection as the mode change is possible from
the kernel without transferring control and without software checks.
On a similar vein, it was suggested that ordinary computer protection modes
implement puzzle boxes because it is hard to get from one mode to another.
Mike Olsen posted a message suggesting that puzzle box protection is too
similar to ordinary password protection to warrant the granting of a patent.
I received mail from people who quoted rather simple protection systems as
examples of puzzle boxes. For example, someone described a memory mapped hard
disk drive which would not respond to requests unless a certain code had been
written in a high memory location.
By far and away the most interesting "prior art" example was the rocket example
posted by Phil Karn. This posting describes rockets launched in the 1980's
which used a linear feedback shift registers to interface rocket engines to
their controlling computers.
Authentication
--------------
Some readers thought that the puzzle box was supposed to be an authentication
device. It is not. Puzzle boxes are for protecting critical devices from
chaotic computer systems not malicious humans.
Lars-Henrick Eriksson (
[email protected]) took the authentication argument to the
other extreme saying that, as the puzzle box is not protecting against a
malicious human, the sequence 1,2,3... is as good as a Gray code sequence. This
argument is valid. However, the sequence must be complex enough to be unlikely
to be generated by a crashed computer and it seems to me far more likely that
0,1,2,3,4,5 be sent to a port than the Gray code sequence. Also a Gray code
puzzle box is likely to be easier to implement and more reliable than a counter
as only one bit changes at each step. This avoids potentially dangerous race
conditions.
On Patenting
------------
Many readers seemed to think I was pursuing a software patent, and I think this
was a behind a few responses which claimed Unix passwords, protocols, and other
checksum/authentication techniques as prior art.
As far as I am concerned, the puzzle box idea is specifically a hardware idea.
Like many of the readers, I am opposed to software patents. I am a member of
the League for Programming Freedom and responded to the recent USPTO call for
comments on computer patent law. However, I am not opposed to hardware patents
as I think that hardware is a much cleaner domain, and the economics of
production are quite different.
I chose the patent path to make some money and to draw attention to and promote
the idea (which I think is a good and worthy one). I do not intend to extract a
pound of flesh if the patent is granted, although I will expect an ounce.
Finally, I must state that my opinion on software and hardware patents has not
been driven by what I have invented. Over the past year, I have developed five
(I believe) patentable data compression algorithms (LZRW1 and LZRW1-A, LZRW2,
LZRW3 and LZRW3-A, LZRW4, LZRW5), which I have chosen to place in the public
domain (LZRW4 and LZRW5 to be released soon). LZRW3-A outperforms Unix compress
(which is based on a patented algorithm) in speed and compression and memory
consumption for most non-huge files.
Those who wish to discuss patent law should followup to news.groups :-).
Provisional Patent
------------------
Some people asked what a provisional patent is. In Australia, you can lodge a
"provisional patent application", which should give a good idea of the
invention, but need not be too rigorous. You can lodge such an application with
only a few hours preparation. As I understand it, the application is merely
filed by the patent office (in a filing cabinet presumably), and you then have
a year in which to make more serious applications in Australia and other
countries (e.g. a PCT application). I am of the understanding that in the US,
the first application must be a full patent application, and that as a result,
some US inventors choose to file a provisional patent in Australia first and
then later file a full US patent. Note: To file a provisional in Australia from
the US, you need permission from the US government.
Thanks again to those who mailed comments to me.
------------------------------
End of RISKS-FORUM Digest 12.07
************************
