Text File

Subject: RISKS DIGEST 15.36 REPLY-TO: risks@csl.sri.com

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 risks@csl.sri.com, 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 risks-request@csl.sri.com (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 bitftp@pucc.Princeton.EDU 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 risks-request@CSL.SRI.COM .

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

------------------------------

Date: Sun, 26 Dec 1993 05:15:41 GMT From: cantillo@world.std.com (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 <pbl@compsci.stirling.ac.uk> 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 <pbl@compsci.stirling.ac.uk> 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: Bob_Frankston@frankston.com 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: rdd@cactus.org (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 rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd

------------------------------

Date: Thu, 23 Dec 1993 10:22:35 +0100 From: Andrew Beattie <andrew@tug.com> 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 <gong@csl.sri.com> 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: erwin@trwacs.fp.trw.com (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: herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com

[Yes, Thanks. PGN]

------------------------------

End of RISKS-FORUM Digest 15.36 ************************