14-Apr-87 21:59:44-PDT,14192;000000000000 Mail-From: NEUMANN created at 14-Apr-87 21:58:35 Date: Tue 14 Apr 87 21:58:35-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.74 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Tuesday, 14 April 1987 Volume 4 : Issue 74 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Re: In-flight control computers (Henry Spencer) Trojan Horse alert (Al Stangenberger) The Limits of Software Reliability (Brian Randell) Re: Conrail Sale Funds Transfer -- and a 747 overflow (Henry Spencer) Re: VDT related skin cancer? (Henry Spencer) Re: Open University Fire (Henry Spencer) DES Second Review Notice [on the RISKS OF STANDARDS] (David M. Balenson) Bank Computers (Not ATM's) (Ken Ross) The Marconi Affair (Brian Randell) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Mon, 13 Apr 87 20:18:20 EDT From: utzoo!henry@ai.toronto.edu To: CSL.SRI.COM!RISKS@ai.toronto.edu Subject: Re: A different RISK? (in-flight control computers) > The risk is that a pilot may plan on losing some brain function to > g-forces, without risking that the plane will go out of control in the > maneuver. This possibility is entirely due to the presence of the > flight control computer... Not very plausible at the current state of the art. The flight control computers are *not* capable of preventing the aircraft from going out of control; they merely prevent one or two specific types of failure (e.g. breaking the aircraft) that are so clearly undesirable that they can be unquestionably ruled out. In fact, because the problem has gotten a lot more visible of late, serious consideration is now being given to *awarding* the flight-control computers such powers, to save the aircraft and the pilot! The tentative intent is to sense unconsciousness in some manner, signal the pilot that the computer thinks he is unconscious, and if this brings no response, to take over and restore (at least) level flight. Nobody, repeat nobody, is suggesting that the computer try to continue the maneuver the pilot was attempting. > ...The F-20 has crashed twice in airshow routines, after the same potential > 9g pull-up maneuver... Several other crashes, such as that of the British Aerospace attack-configured Hawk prototype, have been tentatively attributed to G-LOC (G-induced Loss Of Consciousness). And there is considerable suspicion that it may account for other unexplained crashes of very-high-performance fighters in recent years. What is new about the recent fighters is that they can get into high-G situations much more suddenly than older planes could. In older fighters, loss of blood flow to the brain was gradual, and symptoms like tunnel vision could be relied on as warnings. The new fighters can pile on the Gs so quickly that blood flow cuts off almost instantaneously, leaving the brain running on stored oxygen for a moment and then suddenly losing consciousness when that runs out. > Were the flight control computer not to assure maneuvering within the > envelope in the event of an extreme g maneuver, no pilot would risk > loss of control through impaired function, unless in combat. "Within the envelope" does not equal "under control", as the F-20 pilots assuredly knew. I find it extremely implausible that they deliberately risked loss of control by relying on the computers; the computers (well, actually, the programs) aren't that good and the consequences of going out of control can be too final. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Tue, 14 Apr 87 11:41:50 PDT From: forags%violet.Berkeley.EDU@berkeley.edu To: risks@csl.sri.com Subject: Trojan Horse alert Yet another Trojan horse is loose, alas. Several related messages have circulated on comp.sys.ibm.pc about this one. - Al Stangenberger, Forestry, U.C. Berkeley > From: w8sdz@brl-smoke.ARPA (Keith B. Petersen ) > Newsgroups: comp.sys.ibm.pc > Subject: Re: Numerous requests for ARC.EXE > Date: 9 Apr 87 02:46:14 GMT > Organization: Ballistic Research Lab (BRL), APG, MD. > ARC513 is a trojan horse. The latest version of SEA's ARC is ARC520 > and it's available from SIMTEL20 as PD:ARC520.COM. ------------------------------ From: Brian Randell Date: Tue, 14 Apr 87 08:46:01 gmt To: Neumann@csl.sri.com Subject: The Limits of Software Reliability ReSent-To: RISKS@CSL.SRI.COM The "Subject:" field is the title of a paper, by R.L. Enfield, in Technology Review 90,3 (April 1987), pp.36-43. The paper is worthwhile as a readable account, for a general audience. (The author is stated to have a led a study of the fault tolerance of the programs used in the Aegis ship combat system.) ------------------------------ Date: Mon, 13 Apr 87 20:18:13 EDT From: utzoo!henry@ai.toronto.edu To: CSL.SRI.COM!RISKS@ai.toronto.edu Subject: Re: Conrail Sale Funds Transfer -- and a 747 overflow > The sale of Consolidated Rail Corp. almost blew some fuses at the > Treasury Dept. Because Treasury's computers can only handle single > transactions of up to $1 billion... This is reminiscent of the famous, possibly apocryphal, disaster that hit the airline reservation systems when the first 747s entered service. It was the first airliner that could carry more than 255 passengers... Henry Spencer @ U of Toronto Zoology ------------------------------ Date: Mon, 13 Apr 87 20:31:31 EDT From: utzoo!henry@ai.toronto.edu To: CSL.SRI.COM!RISKS@ai.toronto.edu Subject: Re: VDT related skin cancer? To keep some perspective on this, note that there is no unusual incidence of skin cancer among TV program directors, who also spend their lives staring at monitors at close range -- often older, less-well-shielded monitors. > The surgeon asked whether it was possible to get a screen with lead shielding Add-on shields exist, I believe. It is not clear that they are worthwhile. Modern monitors have to meet quite severe X-ray emission limits. Consider having the X-ray output of your display measured first. Somebody at CMU ought to be equipped to do this. > Would the workstations emit more radiation, from their larger screens, > than the PC or terminals? There isn't *necessarily* any correlation with screen size. X-ray energy is related to beam accelerating voltage; intensity is proportional to beam current. A bigger screen will need higher current to get the same brightness over a larger area, but will also spread the emissions out more. At first glance I suspect that size won't make much difference overall. Voltage is chosen by several criteria, but I don't think size has a lot to do with it. I am not an expert on CRT design, mind you. > Are some brands better shielded than others? Different brands using the same monitor will be similar, and it's not always easy to find out who Sun (for example) buys monitors from. I would expect to see little variation in any case. > Would some different placement angle help lower the dosage hitting my face? Probably not. Distance will make a difference, as will shielding (even a sheet of glass -- soft X-rays are not very penetrating). Don't overlook other possible causes: chemical emissions, acceleration of dust particles by static electricity, or sheer chance. Granted that the doctor said it was unusual; many unusual things happen every day. Henry Spencer @ U of Toronto Zoology ------------------------------ Date: Mon, 13 Apr 87 20:18:03 EDT From: utzoo!henry@ai.toronto.edu To: CSL.SRI.COM!RISKS@ai.toronto.edu Subject: Re: Open University Fire > ... eventually [the loss of work] seems to have come down to a couple of > months as most people had personal back-ups of critical data!! It should be noted that this isn't invariably true. When U of T had a major fire ten years ago, far too many things -- including some valuable software products -- existed only in one building, the one that had the fire. We were lucky: most of the computer facilities received only minor water and smoke damage. (In fact, the Unix system stayed up through it all, going down only when the power to the whole building was cut, after the fire was largely under control!) An awful lot of people suddenly became much more conscientious about offsite backups (and fire safety in general) after that. I do wonder how long the effect lasted, though. The building has been rebuilt, and now has many more computers in it. How many of them have complete offsite backups? Henry Spencer @ U of Toronto Zoology ------------------------------ Date: Fri, 10 Apr 87 14:46:53 EST From: David M. Balenson To: risks@csl.sri.com Subject: DES Second Review Notice [on the RISKS OF STANDARDS?] [Please contact David if you want a copy of the notice. The notice itself did not seem suitable for RISKS, but the risks associated with encryption standards was sufficiently relevant to post this message. PGN] For your information, there is a copy of the Federal Register Notice regarding the second review of Federal Information Processing Standard (FIPS) 46, Data Encryption Standard (DES). Written comments are solicited by June 4, 1987. The more comments we receive, the better NBS will be able to take a stance regarding the future of DES. David M. Balenson (DB) [balenson@icst-ssi.ARPA] Security Technology Group / Computer Security Division National Bureau of Standards, Technology A216, Gaithersburg, Maryland 20899 (301) 975-2910 ------------------------------ To: RISKS@csl.sri.com Subject: Bank Computers (Not ATM's) Date: Sun, 12 Apr 87 14:00:39 +1000 From: Ken Ross A little while ago, I went to the bank to withdraw $1200 to buy a saxophone. I filled in a withdrawal form and presented it to the teller. He punched the data into his terminal, debiting my account $1200. He then asked what denomination notes I would like. "Unfortunately," he said, "we're out of 50's and 100's." (Here in Australia, we have notes with the following denominations: $100, 50, 20, 10, 5 and 2. Smaller denominations are in coins.) I did not want to carry sixty $20 notes around with me, and I didn't want a bank cheque either. I asked him to "undo" the transaction, and said I'd come back later. The teller assured me that the only way that it could be done would be to redeposit the $1200 into the same account. So, that is what happened. In the state of Victoria (where the story takes place) there is a state tax of 3 cents in every hundred dollars on deposits. Thus the net effect of the whole affair was that I paid 36 cents tax. I didn't bother pursuing the matter; a postage stamp costs 36 cents. However, there is a potential risk here in the definition of when a transaction has occurred. I am not a lawyer, but I suspect that legally a transaction is not complete until both parties involved are "satisfied". Hence the withdrawal of the money was not complete at the stage when the teller informed me of the unavailability of high-denomination notes. As I could reasonably expect to get high-denomination notes, I should have been able to abort the transaction at this stage. But, because it had been entered on the computer, the transaction had been completed as far as the bank was concerned. If the computer software had been better designed then there should have been a mechanism to abort the transaction right up until the customer leaves. I do not think that a feature like this would cause any further problems, although I am not familiar with bank procedure. UUCP: {seismo,mcvax,ukc,ubc-vision}!mulga!kar CSNET: kar%mulga.oz@australia [Even though the case is small peanuts (or eucalyptus pods?), it illustrates a general problem: the need for a complete transaction UNDO that leaves NO adverse side-effects. It is not really so much a case of an improper atomic action. On the other hand, the bank might take the attitude that TWO transactions were required, and therefore it needed to charge for BOTH! PGN] ------------------------------ From: Brian Randell Date: Tue, 14 Apr 87 09:55:13 gmt To: Neumann@csl.sri.com Subject: The Marconi Affair [Follow-up on RISKS-4.72] ReSent-To: RISKS@CSL.SRI.COM The essence of the latest Computer News story is that a mysterious Ministry of Defence department has begun an investigation into the affair. ``The MoD is adamant that the investigation involves its own "Serious Crimes Squad". It also suggests the enquiries involve alleged fraud on defence contracts. Yet MPs, and even MoD press officers were at first unaware of the existence of the squad. A Ministry of Defence spokesman said: there is nothing sinister. The Serious Crimes Squad of the Ministry of Defence was first mentioned in the Police Almanac 10 years ago. But library files do not show that the squad has been involved in any previous allegations of fraud in defence contracts.'' (The story goes on to mention that the investigation is based at Portsmouth, where Sharif, who was found hanged, is known to have worked for Marconi Underwater Systems.) ------------------------------ End of RISKS-FORUM Digest ************************ -------