The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 4 Issue 74

Tuesday, 14 April 1987

Contents

o Re: In-flight control computers
Henry Spencer
o Trojan Horse alert
Al Stangenberger
o The Limits of Software Reliability
Brian Randell
o Re: Conrail Sale Funds Transfer -- and a 747 overflow
Henry Spencer
o Re: VDT related skin cancer?
Henry Spencer
o Re: Open University Fire
Henry Spencer
o DES Second Review Notice [on the RISKS OF STANDARDS]
David M. Balenson
o Bank Computers (Not ATM's)
Ken Ross
o The Marconi Affair
Brian Randell
o Info on RISKS (comp.risks)

Re: A different RISK? (in-flight control computers)

<utzoo!henry@ai.toronto.edu>
Mon, 13 Apr 87 20:18:20 EDT
> 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


Trojan Horse alert

<forags%violet.Berkeley.EDU@berkeley.edu>
Tue, 14 Apr 87 11:41:50 PDT
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:<MSDOS.ARC-LBR>ARC520.COM.


The Limits of Software Reliability

Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Tue, 14 Apr 87 08:46:01 gmt
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.)


Re: Conrail Sale Funds Transfer -- and a 747 overflow

<utzoo!henry@ai.toronto.edu>
Mon, 13 Apr 87 20:18:13 EDT
> 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


Re: VDT related skin cancer?

<utzoo!henry@ai.toronto.edu>
Mon, 13 Apr 87 20:31:31 EDT
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


Re: Open University Fire

<utzoo!henry@ai.toronto.edu>
Mon, 13 Apr 87 20:18:03 EDT
> ... 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


DES Second Review Notice [on the RISKS OF STANDARDS?]

David M. Balenson <balenson@icst-ssi.ARPA>
Fri, 10 Apr 87 14:46:53 EST
   [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


Bank Computers (Not ATM's)

Ken Ross <munnari!mulga.oz!kar@seismo.CSS.GOV>
Sun, 12 Apr 87 14:00:39 +1000
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]


The Marconi Affair [Follow-up on RISKS-4.72]

Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Tue, 14 Apr 87 09:55:13 gmt
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.)

Please report problems with the web pages to the maintainer

Top