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 firstname.lastname@example.org email@example.com 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 firstname.lastname@example.org email@example.com 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 firstname.lastname@example.org Jeremy.Jacob@prg.oxford.ac.uk ----------------------------- Date: Fri, 19 Jul 91 1:17:57 CST From: Ross Williams <email@example.com> 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, firstname.lastname@example.org, 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@example.com> 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 maintainerxTop