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…
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 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]
... 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
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]
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
cooper@culv.unisys.com mclean@itd.nrl.navy.mil
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
lunt@csl.sri.com kemm@cs.ucsb.edu
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 db@lanl.gov
Jeremy.Jacob@prg.oxford.ac.uk
-----------------------------
Date: Fri, 19 Jul 91 1:17:57 CST
From: Ross Williams <ross@spam.ua.oz.au>
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, ross@spam.ua.oz.au, 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 <lhe@sics.se>
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
Please report problems with the web pages to the maintainer
x
Top