| University of Bielefeld - Faculty of technology | |
|---|---|
|
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D. |
|
| Back to Abstracts of References and Incidents | Back to Root |
| This page was copied from: http://catless.ncl.ac.uk/Risks/15.31.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
London Underground train departs driverless with 150 passengers
Voting by Fax
Computer Fax Problems
A study of National Cryptography Policy
"Using McAfee Associates Software for Safe Computing" by Jacobson
New Docs Reveal NSA Role in Digital Telephony Proposal
Re: Computerized Pornography
Re: Lufthansa Airbus Warsaw Crash 14 Sep 93
Re: Mercury passwords can be compromised
Re: United Parcel Service signatures
CFP: 13th Symp. on Reliable Distributed Systems
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 <your name>" (without quotes or brackets) to
listserv@gwuvm.gwu.edu. Back issues of the Alert are available at the
CPSR Internet Library FTP/WAIS/Gopher cpsr.org /cpsr/alert
Computer Professionals for Social Responsibility is a national, non-partisan,
public-interest organization dedicated to understanding and directing the
impact of computers on society. Founded in 1981, CPSR has 2000 members from
all over the world and 22 chapters across the country. Our National Advisory
Board includes a Nobel laureate and three winners of the Turing Award, the
highest honor in computer science. Membership is open to everyone.
For more information, please contact: cpsr@cpsr.org or visit the CPSR
discussion conferences on The Well (well.sf.ca.us) or Mindvox (phantom.com).
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
According 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]
As 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
CALL 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 Angeles
| This page was copied from: | http://catless.ncl.ac.uk/Risks/15.31.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |