Subject: RISKS DIGEST 15.36
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Sunday 2 January 1994 Volume 15 : Issue 36
HAPPY NEW YEAR! [The RISKS winter slowdown will continue for two more weeks.]
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Risks of high pitched tones (Lance J. Hoffman)
Can SETI signals bear viruses? (Brandon A Cantillo)
Report on Strasbourg A320 Crash emphasises HCI (Peter B Ladkin)
Be careful not to let your engine control computers overheat. (Peter B Ladkin)
LapLink Wireless (Mark Eppley via Bob Frankston)
Re: Airport lessons for InfoSec (Robert Dorsett)
Re: "Re-Chipping" Stolen Mobile Phones (Andrew Beattie, Li Gong)
An Exception (Harry Erwin)
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
Contributions should be relevant, sound, in good taste, objective, cogent,
coherent, concise, and nonrepetitious. Diversity is welcome, but not
personal attacks. CONTRIBUTIONS to
[email protected], with appropriate,
substantive "Subject:" line; others may be ignored! Contributions will not
be ACKed; the load is too great. **PLEASE** include your name & legitimate
Internet FROM: address, especially .UUCP folks. If you cannot read RISKS
locally as a newsgroup (e.g., comp.risks), or you need help, send requests
to
[email protected] (not automated). BITNET users may subscribe
via your favorite LISTSERV: "SUBSCRIBE RISKS".
Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, 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 vital. CRVAX.SRI.COM = [128.18.30.65];
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
WAIS and
[email protected] are alternative repositories.
IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it
via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail
[email protected] .
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: Sun, 26 Dec 1993 10:07:07 -0500 (EST)
From: "Lance J. Hoffman" <
[email protected]>
Subject: risks of high pitched tones
>From the Washington Post, Dec. 26, 1993:
>From "1993: The year of the weird" (page C3)
The Syracuse Herald-Journal reported in January that its telephone hotline,
featuring excerpts of the presidential debates last fall, was succeesful
except for one glitch: Ross Perot's voice sometimes hit a pitch that mimicked
a certain telephone tone that automatically shut down the whole system.
Professor Lance J. Hoffman, Department of EECS, The George Washington
University, Washington, D. C. 20052 (202) 994-4955
[email protected]
------------------------------
Date: Sun, 26 Dec 1993 05:15:41 GMT
From:
[email protected] (Brandon A Cantillo)
Subject: Can SETI signals bear viruses?
I wonder if there are any protocols in place or even proposed for
"quarantining" signals detected by SETI programs against the possibility of
viral infections in software? If Turing machines are a universal feature of
mathematics, might not a malicious or possibly just careless civilization be
transmitting open or disguised programs that could conceivably wreak havoc
among our delicate infosystems? Has anyone thought of this possibility and its
implications? Or has this subject been done to death already and I've missed
it? If so any pointers to the info at any archive site gratefully appreciated.
If not, surely it merits some serious discussion? After all, we were so afraid
of biological contamination the first few Apollo crews were in isolation for
days until we determined that there was no danger. We should have the same
concern for informational "contamination" today, since so much of our
civilization depends on Turing machines.....
["Just careless" would seem unlikely if they were an advanced civilization.
There is always a possibility that an unanticipated signal might do
something strange to a system. There are lots of cases of electromagnetic
interference in the RISKS archives, for example. But if everything in
SETI is interpreted properly as pure DATA, you don't need to worry.
BTW, if we had tapes long enough for the Turing machines, they might be
able to reach to distant planets. PGN]
------------------------------
Date: 22 Dec 93 21:10:28 GMT (Wed)
From: Dr Peter B Ladkin <
[email protected]>
Subject: Report on Strasbourg A320 Crash emphasises HCI
Flight International, 22/12/93-4/1/94 p11 contains an article on the report of
the commission of inquiry into the Jan 1992 Strasbourg A320 crash. Details and
comments on the preliminary findings have appeared in RISKS before. E.g. see
RISKS-14.01 (Mellor) on a rumor of a possible transient fault in the FMGS.
The crew set up an unusually high rate of descent (3,300 ft/min) instead of
the usual 800 ft/min (the final approach fix is only at 1,500 ft above ground
level). FI's report focuses on the crew training and the interface problems
highlighted by the report.
"The commission concluded that the crew's "below-average" performance
contributed to the accident and that the low combined time on type of the two
pilots (162h captain/61h co-pilot) caused a lack of familiarity with the
equipment on the A320's flightdeck, which has "...increased the risk factor".
[...]
From the moment of descent until impact, says the report, the
aircraft's high descent rate was adopted and maintained. The commission
observed that the "vertical navigation" was left entirely to the automatic
systems and the crew appeared to ignore all the clues available to them about
their abnormally high descent rate.
The commission says that the reason for the crew's descent mode
selection is not proved beyond all doubt, but that the most probable
explanations are a confusion as to which descent mode - vertical-speed (VS) or
flight-path-angle (FPA) - was set, having either forgotten to set it or having
set it incorrectly.
The ergonomic design of the descent-more selector is criticised for
being too easy to misread or mis-set. Airbus states that a design improvement
[..] has already been certificated and incorporated into all new A320s since
November 1993. A retrofit package will be available for fitting from January
1994.
The many recommendations in the report concentrate heavily on the need
for regulation to ensure pilot training and procedures improvements, together
with a need to monitor and standardise symbology development in modern
flightdeck displays."
Peter Ladkin
------------------------------
Date: 22 Dec 93 21:20:52 GMT (Wed)
From: Dr Peter B Ladkin <
[email protected]>
Subject: Be careful not to let your engine control computers overheat.
Flight International, 22/12/93-4/1/94, p11.
"Dangerous overheating in an Airbus Industrie A320 engine-starter unit led to
complete in-flight engine-control failure [..].
The starboard [engine ....] suddenly wound down to idle power at
4,000ft (1,200m) in the climb from London Heathrow on 13 December, 1992.
Reversion to manual control had no effect because the circuit breakers
for the full-authority digital engine control (FADEC) and engine-interface
unti had tripped and would not reset. THe aircraft returned safely to
Heathrow. [...] Temperatures reached 400\degC inside the engine cowl,
damaging the FADEC wiring. The AAIB says that the engine wind-down was
probably caused by short-circuiting, which gave false signals about
thrust-reverser position.
In October 1989 a similar [..] event led to the issue of the 1991
Service Bulletin. A Bulletin issued after the incident was not applied to the
[aircraft in this report]. The AAIB recommends making it mandatory."
Peter Ladkin
------------------------------
Date: Thu, 23 Dec 1993 02:36 -0400
From:
[email protected]
Subject: LapLink Wireless
To: Bob Frankston "Robert M. Frankston / MCI ID: 100-7411"
From: Mark Eppley / MCI ID: 296-7039 @ mci
Date: 12-23-93 01:55:00 EST (12-23-93 02:19:57 EST)
Subject: RE: From Risks Digest
It is called LapLink Wireless. Uses FM phase lock loop radio transceivers
we developed and licensed to National Semiconductor. He is way off
base. 2 levels of security exist as well as compression/encryption of
packets flying through the air.
------------------------------
Date: Wed, 22 Dec 93 21:58:55 CST
From:
[email protected] (Robert Dorsett)
Subject: Re: Airport lessons for InfoSec (Kabay, RISKS-15.35)
Of course, another take on this situation (and equally applicable to the
computer world) is that the security culture mainly benefits its vendors and
overseeing bureaucracy: that the slipshod techniques are merely there to
reassure a naive public that the airlines and their government are doing
something with respect to an issue that gravely concerns many: but evidence
had repeatedly shown--even at the peak of "red scares"--that these measures
tend not to deter the high-risk attackers (or even catch very many of the
low-risk attackers, as the estimated ~30,000 security violations/year
testifies). EVEN when conducted according to specification.
Metal detectors are manned by poorly trained, low-cost personnel, and provide
a single point of entry that is easily subverted. Similarly, badges are
ineffective, and door combination locks are easily compromised. But they do
show the public that "something is being done." So when hijackings to
Cuba became embarrassing, checkpoints appeared; when bombings occur, the
call for outrageously expensive explosives detectors goes up; when an airline
employee kills the flight crew of an airplane, the employees are treated
like criminals (every airline pilot in the United States must pass through
the same security checkpoints as the passengers, for instance: in Russia,
they ARM their pilots :-)).
This is all visible to the public, and may provide (as with computer security)
some level of deterrence for *honest* individuals, but overall, the results
are mixed, at best. Countries that do security right (such as Israel) do it
very slowly, and very expensively; countries that want their cake and be
able to eat it too (profitable security; the closest analog may be network
security), resort to symbolic measures, largely ineffective--but which help
sell a notion that "something is being done."
So, as with computer security, perhaps the real question to ask is whether
the symbolism--for all its faults--is really worth it. I don't particularly
relish the prospects of living in a police state, myself. Actually, I *did*
live in one, for over ten years. Sure, you can go to sleep with the front
door wide open, but such societies take their toll in much more profound,
disturbing ways than petty violence.
Robert Dorsett
[email protected] ...cs.utexas.edu!cactus.org!rdd
------------------------------
Date: Thu, 23 Dec 1993 10:22:35 +0100
From: Andrew Beattie <
[email protected]>
Subject: Re: "Re-Chipping" Stolen Mobile Phones
I have had a keen interest in this problem since my portable was stolen
from my car. This is what I have since learnt:
Re-Chipping is a misnomer. All modern cellphones can have *soft* Electronic
Serial Numbers (ESNs) and phone numbers. On my NEC P3, these can be changed
without even removing the cover.
The real thief is the airtime company. They leave me with two choices:
1) Pay UKP137.00 to get out of my airtime contract. (3 months line rental,
plus UKP50.00 disconnection +tax)
2) Buy a new phone. They have a whole department to sell theft-replacement
phones. The prices for phones sold without a new airtime contract are *much*
higher than those sold with a contract.
The reality is that people generally only upgrade their phones when they get
stolen, so it is in the interest of the airtime providers to sell phones
with a high "black" value.
The entire trade in stolen phones could be stopped by the simple expedient
of using *hard* ESNs and dipping the circuitry in epoxy.
Andrew
------------------------------
Date: Wed, 22 Dec 93 14:02:20 -0800
From: Li Gong <
[email protected]>
Subject: Re: "Re-Chipping" Stolen Mobile Phones (Brian Randell)
The rechipping is a service provided even by the Taiwan government, at
about NT$4000 (about US$160) a pop. Lots of people who are legally
registered and paying customers buy cell phones from the US and rechip
them to use in Taiwan. The reason is quite legitimate -- the cost of
buying a cell phone in Taiwan is exceedingly high. Presumably, by
providing this service, the Taiwan government gets fees that would
have gone into phone dealers' pockets.
Li Gong, SRI International
------------------------------
Date: 23 Dec 1993 00:35:33 GMT
From:
[email protected] (Harry Erwin)
Subject: An Exception
I was a little surprised my comment got posted, since I was basically
interested in the moderator's opinion on why software typically had so many
problems. BMDSTP project was unusual in being successful, and I was looking
for some comparably successful projects. Lauren Wiener asks some sharp
questions:
1. What was the purpose of the software?
This was the Site Defense Program, which was to build software for the
ballistic missile defense system that followed Safeguard. It was also the
testbed for Modern Programming Practices, and Barry Boehm was involved.
ALTHOUGH the management was good, it was not particularly better than
management I've worked with since. The BMDSTP managers did take a
proactive stance, trying not to be blindsided by problems, and they were
always willing to listen to their engineers.
This program was redirected in midstream in response to the ABM pact, and
instead went to Kwajalein as a tracking and data collection tool for the
phased array radar out there. It ran on a pair of CYBER 7000 machines. It
worked, and it worked well.
2. Was the product actually used in real-world situations, as opposed to
testing?
Hard to answer. It ended up a component of a test system, but it was not
under test there. It certainly met its requirements.
3. Were the acceptance tests specified in advance? Were they available to
the developers to use as they developed the software?
Yes, we were very careful to get the required performance envelope and
functional requirements defined in detail, and we ran off-nominal stress tests
against those requirements. The real-time operating system was specified
top-down, with performance requirements as well as functional requirements,
and we built an automatic testing system that validated the RTOS and DMS for
each delivery. I've not seen anything since like the way that process was
managed. Most programs address performance and reliability late, if ever, and
we addressed it from the beginning. As Tom Bell puts it: "Pay me now or pay me
later. It'll cost more later." We paid up front.
I'm very interested in why this one program worked so well. I've been
observing the FAA Advanced Automation Program for the last three years and
trying to understand the difference between my experience on the BMDSTP and
their current experience. My impression is that there is a non-linear
relationship between the effectiveness of technical management and the success
or failure of a software project. If the software is just slightly too hard
for the management team, they fall behind and spend their time playing
catch-up and responding to surprises. If they are able to get their arms
around the system early, on the other hand, they can keep ahead of the
problems and control things much more effectively. There's not that much of a
difference between most managers and engineers that I can identify, so I
suspect it's the nature of the software development problem to be like that.
Does that help?
Harry Erwin Internet:
[email protected] or
[email protected]
[Yes, Thanks. PGN]
------------------------------
End of RISKS-FORUM Digest 15.36
************************
