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…
According to BBC Radio 4 news (17.00 Dec 2nd), a Picadilly Line underground train travelled 1.5 miles at 20-40 mph including going through Caledonian Road station, without a driver. The driver (and sole crew) had got out to close a door "without carrying out the proper procedure to shut down the drive systems" according to a spokesman for London transport. The train stopped automatically at a red light, and was boarded by LT staff who had commandeered the following train and given chase. No passenger pressed the emergency alarm - but it wouldn't have helped as it just rings a bell in the driver's cab. A colleague believes that there is a "dead-man's handle" which the driver must have disabled. My theory is that the train had decided to play Mornington Crescent and seized its opportunity. -- Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk Fax: +44-225-465205 [I presume this is a NEW incident. RISKS-9.81 described a case contributed by Stephen Page: On 10 Apr 1990, the driver of an Underground train had taped down the drive control, relying instead on the doors being closed to enable the train to move forward. He then left the train to see why the doors had not closed. The doors closed, and the train took off. But Martyn's report sounds like the same story! Maybe it was just the same driver, 3.6 years later. PGN]
Keith Lockstone noted the problem of call loggers catching his Mercury Telephone system password when using the system from work to access his personal Mercury account. The phone directory of numerous places where I have worked have in their user information the fact that using British Telecom charge cards should not be done because of call loggers picking up the card password. The same applies to Mercury passwords clearly. The risk? The standard one of sending passwords in the open through a system which is not secure. Namely the fact that it is not possible to ensure the password is not intercepted. Think of all the passwords being passed in clear form over tcp/ip links - then shudder! For Mercury, at least the phone number and time of every call is on the bill allowing you to check usage. Of course for Mercury you could also use the non-passworded (132) system where Mercury picks up the number you are calling from as the basis for charging. There though you cannot do useful things like cost centres (yet!) Peter Debenham, Rm165, APR, Meteorological Office, London Rd., Bracknell, Berks., UK. RG12 2SZ tel: +44 (0)344 856974(wk)
The 30 Nov 1993 edition of the _Rocky Mountain News_ (Denver) reports that Wyoming Secretary of State Kathy Karpan is considering legislation to allow overseas Wyoming residents *fax* in their ballots, to "improve" the absentee-voting process. Bear Giles bear@fsl.noaa.gov/cs.colorado.edu
The following is taken from the BBC television programme called WatchDog. This programme is screened on a Monday evenings at 7:30pm (GMT - UK). I am recounting this story as best I can - however I am only human. Today (29th Nov 93) they described a man which had been driven to take pills to calm him down by an anonymous phone caller. This caller would ring him up in the middle of the night and wake him up. He contacted BT (British Telecom) and they tried to trace the call for him. However due various factors they could only tell him the area from which the phone call was originating. He did get to the phone one night and discovered that his caller was not human but a machine. So BT lent him a FAX machine with which to receive the call. From the faxed message it was possible to work out from where the fax communication originated. BT went to the company concerned and told them what was happening. It turned out that one of their FAX machines had been trying to send this one fax over and over again. All this took about two years and in the process the gentleman described was driven to pills - and all the company would say to him at the end of the day was sorry. Moral: don't put your phone number of your FAX transmissions. Andrew Blyth, Department of Computer Science, 20 Windsor Terrace, University of Newcastle Upon Tyne, Newcastle Upon Tyne, England NE1 7RU
As part of the Defense Authorization Bill for FY 1994, the U.S. Congress has asked the Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) to undertake a study of national policy with respect to the use and regulation of cryptography. The report of the study committee is due two years after all necessary security clearances have been processed, probably sometime summer 1996, and is subject to NRC review procedures. The legislation states that 120 days after the day on which the report is submitted to the Secretary of Defense, the Secretary shall submit the report to the Committees on Armed Services, Intelligence, Commerce, and the Judiciary of the Senate and House of Representatives in unclassified form, with classified annexes as necessary. This study is expected to address the appropriate balance in cryptography policy among various national interests (e.g., U.S. economic competitiveness (especially with respect to export controls), national security, law enforcement, and the protection of the privacy rights of individuals), and the strength of various cryptographic technologies known today and anticipated in the future that are relevant for commercial purposes. The federal process through which national cryptography policy has been formulated is also expected to be a topic of consideration, and, if appropriate, the project will address recommendations for improving the formulation of national cryptographic policy in the future. This project, like other NRC projects, will depend heavily on input from industry, academia, and other communities in the concerned public. Apart from the study committee (described below), briefings and consultations from interested parties will be arranged and others will be involved as anonymous peer reviewers. It is expected that the study committee will be a high-level group that will command credibility and respect across the range of government, academic, commercial, and private interests. The committee will include members with expertise in areas such as: - relevant computer and communications technology; - cryptographic technologies and cryptanalysis; - foreign, national security, and intelligence affairs; - law enforcement; - commercial interests; and - privacy and consumer interests. All committee members (and associated staff) will have to be cleared at the "SI/TK" level; provisions have been made to expedite the processing of security clearances for those who do not currently have them. Committee members will be chosen for their stature, expertise, and seniority in their fields; their willingness to listen and consider fairly other points of view; and their ability to contribute to the formulation of consensus positions. The committee as a whole will be chosen to reflect the range of judgment and opinion on the subject under consideration. The detailed composition of the committee has not yet been decided; suggestions for committee members are sought from the community at large. Note that NRC rules regarding conflict of interest forbid the selection as committee members of individuals that have substantial personal financial interests that might be significantly affected by the outcome of the study. Please forward suggestions for people to participate in this project to CSTB@NAS.EDU by DECEMBER 17, 1993; please include their institutional affiliations, their field(s) of expertise, a note describing how the criteria described above apply to them, and a way to contact them. For our administrative convenience, please put in the "SUBJECT:" field of your message the words "crypto person". Finally, some people have expressed concern about the fact that the project will involve consideration of classified material. Arguments can and have been made on both sides of this point, but in any event this particular ground rule was established by the U.S. Congress, not by the CSTB. Whether one agrees or disagrees with the asserted need for classification, the task at hand is to do the best possible job given this constraint. On the National Research Council The National Research Council (NRC) is the operating arm of the Academy complex, which includes the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The NRC is a source of impartial and independent advice to the federal government and other policy makers that is able to bring to bear the best scientific and technical talent in the nation to answer questions of national significance. In addition, it often acts as a neutral party in convening meetings among multiple stakeholders on any given issue, thereby facilitating the generation of consensus on controversial issues. The Computer Science and Telecommunications Board (CSTB) of the NRC considers technical and policy issues pertaining to computer science, telecommunications, and associated technologies. CSTB monitors the health of the computer science, computing technology, and telecommunications fields, including attention as appropriate to the issues of human resources and information infrastructure and initiates studies involving computer science, computing technology, and telecommunications as critical resources and sources of national economic strength. A list of CSTB publications is available on request.
BKUMASSC.RVW 930817 International Security Technology Inc. 99 Park Avenue, 11th Floor, New York, NY 10016 212-557-0900 fax: 212-808-5206 "Using McAfee Associates Software for Safe Computing", Jacobsen, 1990 There are many books which are aimed at helping you use specific commercial programs. Usually, however, such books are either targeted at "dummies" or purpose to reveal secret or undocumented features. The title here seems to suggest both a generic goal, safe computing, and a specific means. Those "in the know" of course, realize that safety here is being limited to protection against viral programs. Certain other works have been associated with the company named here, and have resulted in rather unfortunate products. In the Foreword and Preface we see the game "rah, rah" chauvinism. It is, therefore, a rather pleasant surprise to find that chapter one, in defining viral programs, doesn't do a bad job. A computer virus is said to execute with other programs, but that explanation is immediately extended with a lucid and factual account of the boot sequence on MS-DOS computers. It even distinguishes between the boot sector and the master boot record (although Jacobson loses points for referring to the MBR as the partition table.) The rigorous will find errors in the first chapter. Program infection is shown strictly in terms of an appending virus. Although FAT or system viri (referred to as "cluster-point") are described, companion viri are not. The statement is made that "viruses may include a Trojan Horse": the definition is that of a trojan, the examples are clearly logic bombs. Chapter two is entitled "Planning a Virus Control Program". This would seem to be concerned with establishing the level of risk for a company and producing policy and procedures for virus protection. Unfortunately, the detail included here is very sparse. Some extremely broad guidelines are given, but the reader is literally left with more questions than answers after reading this chapter. Eventually a companion volume by the same author is mentioned as dealing with the details. At the beginning of chapter two one is told that chapter three, "Virus Prevention Techniques" gives the answers for protecting a single computer. Rule one: write protect everything. Rule two: Buy SCAN. Rule three: buy *more* SCAN. Rule four: have extra copies of SCAN around (be sure to buy extra licences.) Chapters four to seven are basically reworkings of the documentation for VSHIELD, SCAN, CLEAN and the network uses thereof. One immediately asks, of course, which version was used. One is not immediately answered: chapter eight indicates, and nine supports, the presumption that version 85 was used. In the mailing with my review copy I received a letter indicating that update files are produced. The files, USINGxxx.ZIP, where xxx is the version number, are stated to be available on the McAfee BBS and the McAfee forum on Compuserve. Apparently the updating is not constant: the "current" version of the McAfee products, as this was received, was 106, and had been for some time. According to the letter, the "current" version was USING102 and USING106 was due out shortly. Chapters eight and nine tell you how to get technical support, first, and a copy of the program, second. The answers are to call the McAfee BBS, the McAfee Compuserve forum, or call McAfee Associates and buy it. An order form for the McAfee products is bound into the back of the book: it will surprise no one that the publisher of the book is a McAfee agent. Chapter ten is entitled "The Ten Most Common Viruses". Those familiar with the sometimes unfortunate accuracy of the VSUM lists will recognize the entries. In a listing at the end of the chapter, BRAIN and Stoned are included in a list of "stealth" viri which can cause "catastrophic damage" or "cause all files to become infected during the scanning process". Essentially, what you have here is printed (and dated) documentation for the McAfee programs. Since the functions of the programs change less frequently than the scan strings, most of the material is still relevant. Problems can be checked against the current McAfee documentation. As such, this may be a useful book, fairly reasonably priced considering the cost of the programs themselves. One shortcoming is that the network section still relies on the combination of stand-alone software: the NLM versions are not mentioned. In contrast to most "third party" books, though, there is little here that will either change the performance or ease the use, of the product under discussion. copyright Robert M. Slade, 1993 BKUMASSC.RVW 930817 Permission granted to distribute with unedited copies of the Digest =========================604-984-4067============================== DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca
>From the CPSR Alert 2.06 (Dec. 1, 1993) A series of memoranda received by CPSR from the Department of Commerce last week indicate that the National Security Agency was actively involved in the 1992 FBI Digital Telephony Proposal. Two weeks ago, documents received by CPSR indicated that the FBI proposal, code named "Operation Root Canal," was pushed forward even after reports from the field found no cases where electronic surveillance was hampered by new technologies. The documents also revealed that the Digital Signature Standard was viewed by the FBI as "[t]he first step in our plan to deal with the encryption issue." The earliest memo is dated July 5, 1991, just a few weeks after the Senate withdrew a Sense of Congress provision from S-266, the Omnibus Crime Bill of 1991, that encouraged service and equipment providers to ensure that their equipment would "permit the government to obtain the plain text contents of voice, data and other communications...." The documents consist of a series of fax transmittal sheets and memos from the Office of Legal Counsel in the Department of Commerce to the National Security Agency. Many attachments and drafts, including more detailed descriptions of the NSA's proposals, were withheld or released with substantial deletions. Also included in the documents is a previously released public statement by the National Telecommunications and Information Administration entitled "Technological Competitiveness and Policy Concerns." The document was requested by Rep. Jack Brooks and states that the proposal could obstruct or distort telecommunications technology development by limiting fiber optic transmission, ISDN, digital cellular services and other technologies until they are modified, ... could impair the security of business communications ... that could facilitate not only lawful government interception, but unlawful interception by others, [and] could impose industries ability to offer new services and technologies. CPSR is planning to appeal the Commerce Department's decision to withhold many of the documents. To subscribe to the Alert, send the message: "subscribe cpsr
Re: Computerized Pornography (Randell, RISKS-15.30)
Charlie Stross <charless@sco.com> Thu, 2 Dec 1993 10:39:14 +0000 (GMT)The obvious RISK of this proposed law is that the evidence in question -- on-line pornographic material — is fungible. It would be fairly easy for a police officer with a copy of PhotoShop to modify legal or quasi-legal images stored on a confiscated personal computer by adding, for example, a child's head to the image — and thus "fit up" a victim for a jail sentence as a child pornographer. Such tampering would be very difficult to prove. In case this sounds paranoid, several police officers in the UK have in the past couple of years, been found to have tampered with evidence in a number of cases. The classic instance was the West Midlands Serious Crime Squad, which was disbanded under intense public scrutiny. It was found that officers had consistently perverted the course of justice, and forged confessions and evidence against people who were imprisoned as a consequence of this. Charlie Stross is charless@sco.com, charlie@antipope.demon.co.uk
Re: Lufthansa Airbus Warsaw Crash 14 Sep 93
Udo Voges <voges@iai.kfk.de> Wed, 1 Dec 93 09:26:48 +0100According to TV-news and dpa, the A320 crash had three causes: 1. bad weather (heavy rain, wind from rear) on new runway without rain gutter 2. wrong weather report from the tower (light rain and wind from ahead/side) 3. control system enables thrust reverse etc only if both wheels carry at least 12 t weight. Due to 1+2, touch down was some 900 m late and only with one wheel on slippery runway. Due to 3 (+above) no braking power by thrust reverse for some 8-10 sec., it was not possible to override the control system. Airbus finally agreed to modify its control system to enable landing/braking actions already if the weight on the wheels is 2t. (Is this restriction due to e.g., the Lauda Air crash of a Boeing with thrust reverse enabled during flight?) Airbus is not willing to allow overruling of this control system. Udo Voges, Kernforschungszentrum Karlsruhe GmbH, Institut fuer Angewandte Informatik, Postfach 3640, D-76021 Karlsruhe, GERMANY +49-7247-82-5725 [This echoes what Peter Ladkin contributed to RISKS-15.30, and is included for those of you who did not go through Peter's account. PGN]
Re: United Parcel Service signatures (Carroll, RISKS-15.29)
<Andrew_Marc_Greene@frankston.com> Wed, 24 Nov 1993 10:22 -0400As the president of my company pointed out when I asked him why he kept the bitmap of his signature in a directory readable by anyone in the company, "Anyone who has my signature, a fax machine, and a fax modem can sign whatever he wants with my name anyway." (That's how he got the bitmap in the first place.) - Andrew Greene
CFP: 13th Symp. on Reliable Distributed Systems
Rick Schlichting <rick@cs.arizona.edu> 30 Nov 1993 22:38:29 -0700CALL FOR PAPERS 13th Symposium on Reliable Distributed Systems Oct. 25 (Tues), 1994 - Oct. 27 (Thurs), 1994 Dana Point, California SPONSORS: IEEE Computer Society TC on Distributed Processing IEEE Computer Society TC on Fault-Tolerant Computing IFIP WG 10.4 on Dependable Computing THEME: The theme of the symposium is reliability of distributed and parallel systems, including distributed applications, distributed operating systems, and distributed databases. Papers are sought that address the reliability, availability, security, and performance aspects of distributed and parallel systems. Papers that deal with experimental results, testbeds, development, and data from operational systems are of particular interest. TOPICS OF INTEREST: The following topics, as they relate to distributed and parallel systems, are of interest to the Symposium: - System-Level and Software Fault Tolerance - Fault-Tolerance Formalism - Database Systems - Operating Systems - Security - Experimental Systems with High Reliability Mechanisms - Object-Oriented Systems - Transaction Processing Systems - Performance and Reliability Modeling - Programming Language Support for Reliable Computing - Real-Time Fault-Tolerance PAPER SUBMISSIONS: Papers must be written in English and printed using at least 11-point type and 1-1/2 line spacing. They should be no more than 20 pages in manuscript, including figures. Authors are requested to submit five copies of their manuscript by March 15, 1994 to: Prof. Richard D. Schlichting Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, AZ 85721, USA +1-602-621-4324 rick@cs.arizona.edu Authors will be notified by June 1, 1994. Final camera-ready copies are due July 9, 1994. AWARDS: The Wing Toy Best Student Paper Award, carrying a monetary award, will be given to the best student paper accepted for the Symposium. A paper is eligible for the award only if (1) it will be presented at the Symposium by a student co-author, and (2) the research it presents is essentially the work of the student co-authors and the involvement of the non-student co-authors was restricted to advising the student co-authors. The detailed Award rules will be provided to the authors of the accepted papers. TUTORIALS: Persons interested in teaching a half-day or full-day tutorial on topics related to the theme of the symposium are encouraged to submit a proposal with a brief syllabus by March 15, 1994 to: Dr. Devesh Bhatt Honeywell Systems & Research Center 3660 Technology Drive MN65-2100 Minneapolis, MN 55418, USA +1-612-951-7316 bhatt@src.honeywell.com SYMPOSIUM CO-CHAIRS: Kane Kim University of California, Irvine Algirdas Avizienis University of California, Los AngelesPlease report problems with the web pages to the maintainer
xTop