The Risks Digest, Volume 15, Issue36

Peter G. Neumann

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 15: Issue 36

Sunday 2 January 1994

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
Info on RISKS (comp.risks)

risks of high pitched tones

"Lance J. Hoffman" <hoffman@seas.gwu.edu>

Sun, 26 Dec 1993 10:07:07 -0500 (EST)

>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   hoffman@seas.gwu.edu

Can SETI signals bear viruses?

Brandon A Cantillo <cantillo@world.std.com>

Sun, 26 Dec 1993 05:15:41 GMT

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]

Report on Strasbourg A320 Crash emphasises HCI

Dr Peter B Ladkin <pbl@compsci.stirling.ac.uk>

22 Dec 93 21:10:28 GMT (Wed)

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

Be careful not to let your engine control computers overheat.

Dr Peter B Ladkin <pbl@compsci.stirling.ac.uk>

22 Dec 93 21:20:52 GMT (Wed)

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

LapLink Wireless

<Bob_Frankston@frankston.com>

Thu, 23 Dec 1993 02:36 -0400

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.

Re: Airport lessons for InfoSec (Kabay, RISKS-15.35)

Robert Dorsett <rdd@cactus.org>

Wed, 22 Dec 93 21:58:55 CST

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  rdd@cactus.org  ...cs.utexas.edu!cactus.org!rdd

Re: "Re-Chipping" Stolen Mobile Phones

Andrew Beattie <andrew@tug.com>

Thu, 23 Dec 1993 10:22:35 +0100

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

Re: "Re-Chipping" Stolen Mobile Phones (Brian Randell)

Li Gong <gong@csl.sri.com>

Wed, 22 Dec 93 14:02:20 -0800

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

An Exception

Harry Erwin <erwin@trwacs.fp.trw.com>

23 Dec 1993 00:35:33 GMT

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: herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com

   [Yes, Thanks.  PGN]

Report problems with the web pages to the maintainer