22-Apr-87 17:29:49-PDT,19585;000000000000
Mail-From: NEUMANN created at 22-Apr-87 17:29:45
Date: Wed 22 Apr 87 17:29:45-PDT
From: Peter G. Neumann <Neumann@CSL.SRI.COM>
Subject: RISKS DIGEST 4.75
To: RISK@CSL.SRI.COM

RISKS-LIST: RISKS-FORUM Digest  Monday, 20 April 1987  Volume 4 : Issue 75

           FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
  Flight control risks (Peter Ladkin)
  ``More on risky high-g piloting'' (Tom Perrine)
  Checklist stops risks? (Joseph Beckman)
  Radiation risk at airports? (Paul Stewart)
  How to post a fake (Chuq Von Rospach, Rob Robertson)
  Re: Bank Computers (Not ATMs) (Kuhn)
  Correction to Conrail Sale Funds Transfer (Mark Brader)
  "Reliability Theory Applied to Software Testing" (HP Journal)(Rich Rosenbaum)

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>RISKS-i.j.  MAXj:
  Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.)

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

Date: Wed, 15 Apr 87 14:54:23 pst
From: ladkin@kestrel.ARPA (Peter Ladkin)
To: risks-request@csl.sri.com
Subject: Flight control risks

Henry Spencer notes that the flight control on an F16 (etc) does not
prevent the pilot from losing control of the aircraft.  He is correct
to the letter. To my knowledge, there is no aircraft yet built which
is guaranteed to be stall-free, spin-free and tumble-free.

Let me be more precise, and unfortunately more lengthy. I was trying
to convey the idea that because of fly-by-wire design decisions, there
are different risks to flying a new-generation fighter.

An aircraft may enter an accelerated stall at high speed in a sharp turn. An
F16 airframe is certainly capable of this, but is control limited since the
pilot probably isn't. The pilot believes he or she may thus roll and haul
back, strain and black-out, and not have to cope with an accelerated stall
while having no vision.  With real control actuators in the F16, a pilot
would have to be much more sensitive on the stick, and probably couldn't
plan to tolerate routine black-outs. The risks have changed - pilots now
sometimes lose consciousness, and have little or no motor control for up to
a minute when they regain it. That's a dive into the ground from 60,000 feet.

This is rather like the ATM example.  Usually the transaction is finished when 
you remove your card, but not always, it seems. With a real teller it would be.
But a real teller might make a transcription mistake.  The risks have changed.

The Airbus example is relevant here, also. Using computer direction to
maintain maximal angle of attack on a go-around might lead to disaster if in
a microburst rotor, since the winds change faster than the aircraft can
respond (as in the DFW accident). I'm sure the airbus people would have
thought of that - except that we don't yet know what exactly happens in a
microburst, so how can we be assured of the control logic? The computer
controls the aircraft better than a human can follow a flight director, but
a human can improvise, sometimes, in these unknown situations.  The risks
have changed - but maybe I'm preaching to the converted?
                                                           peter ladkin

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

Date: 16 Apr 87 16:47 PDT
From: Tom Perrine <Perrine@LOGICON.ARPA>
To: risks@CSL.SRI.COM
Subject: ``More on risky high-g piloting''

From the "Safety" column in the March 30 Aviation Week and Space Technology,
the magazine-provided abstract follows: 

Northrup Corp.'s F-20A Tigershark prototype fighter aircraft was flying an
authorized practice demonstration at the Goose Bay Airport, Labrador,
Newfoundland, on May 14, 1985, in preparation for performances at the
upcoming Paris air show.  During the final aerobatic maneuver of the 5-min.
flight, the aircraft deviated from the planned profile and entered a shallow
wings-level descent.  The descent continued until the aircraft struck the
ground, killing the pilot, David Barnes.

The Canadian Aviation Safety Board determined that the Northrup pilot became
incapacitated during or following the final high-g pull-up maneuver and did
not recover sufficiently to prevent the aircraft from striking the ground.
Initial portions ran in Aviation Week and Space Technology Mar 23, p. 75;
Mar 16, p. 89.

[[[End of Abstract]]]

This 3rd part of the series presents the conclusions of the CASB.  This is
related to Risks only in that previous contributions have suggested that
pilots were beginning to depend on the computer to save them in GLC
(G-induced Loss of Conciousness) situations and the CASB findings *do not*
support this hypothesis.  In fact, this civilian pilot "had not received
formal aeromedical training pertaining to the GLC phenomenon and no evidence
was found that GLC training was required prior to participation in high-g
demonstration flights."

There were also pilot medical conditions and other contributing factors.  It
would seem that this was a training and human risk, rather than a
computer-related risk.
                                        Tom Perrine

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

Date:  Fri, 17 Apr 87 08:06 EDT
From:  Beckman@DOCKMASTER.ARPA
Subject:  Checklist stops risks?
To:  RISKS@CSL.SRI.COM

1.  A couple of weeks ago, my VCR started "malfunctioning."  It would turn
the TV screen to noise whenever I pushed the TV/VCR button to TV (it does
not record without the "TV" being "on"), and so would not record.  It also
did not play back.  I got a picture (very muddy) and not much sound.  Since
my son (age 2.5) had been "playing" with it the day before, I tried to find
out what he had done (if anything).  I checked the connections, a few
buttons in the "control panel" in front, the channel on the front (with
cable, you just leave it on channel 3), but could find nothing wrong.  I did
not look in the manual for instructions on initial startup.  The problem?
The channel select IN BACK, a small switch which selects either channel 3 or
4 had been switched to 4.

Last week, my radio in the car starting "malfunctioning" (the normal stations 
were not coming in, etc).  I still had not learned the VCR lesson, and it
took me several days to find out he (my son again) had hit the FM/AM button.

If I had a simple checklist, I would have easily and quickly solved both of
these "problems." Now I am wondering about more complicated systems
(airplanes, power plants, etc.).  What kind of things are on their
"checklists"?  The simple variety (check fuel gauge), or more elaborate items?

Joseph
                      [You forgot that your offspring is very resilient.  PGN]

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

Date: Mon, 20-Apr-87 00:40:59 PDT
From: beach!paul@rand-unix.ARPA (Paul Stewart)
Subject: Radiation risk at airports?
To: risks@csl.sri.com

   On Saturday, April 18, the major wire and news services carried a story,
attributed to the New York Times, saying that the FAA was about to start
testing of a prototype neutron beam-based system for detecting the nitrogen
in explosives that might be in luggage/cargo loaded into plane cargo holds.
This is a computer-based system that bombards luggage or other cargo with a
"beam of slowed neutrons" and uses a computer system to analyze the
signature of the resulting gamma radiation emissions to characterize for the
potential presence of explosives.

   The Associated Press inaccurately suggested that the manufacturer of this 
equipment was a firm named "Thermedics."  The actual NYT article gives much 
more detail and accurately names the manufacturer as "Science Applications
International Corp." of Sunnyvale.

   Some months ago, when this technology was originally mentioned in the
press, there was some discussion of the radiation problems inherent
with this sort of technology.  While one would assume care would be
used to make sure animals traveling as cargo are not subjected to
a neutron beam, the problem of secondary radiation effects on the
clothes, foods, medications, and everything else that travels as
cargo/luggage seems to be glossed over by the press.  While normal
X-ray technologies do not produce secondary radiation at conventional
power levels, neutrons are extremely energetic and in fact this
explosive detection system appears to be depending on secondary
radiation for its very operation!

   When this system was first discussed in the press some months ago,
there was mention of the problems of cargo and luggage becoming
"slightly radioactive" as a result of being subjected to the "slowed
neutron beam."  The current discussion in the press seems to be avoiding
this issue entirely, instead mentioning that the people operating
the equipment will not be subjected to more than "government standards"
for radiation exposure (many persons seem to feel that these standards
allow far too much exposure as it is).

   The question then, for anyone who understands this technology or knows
about Science Applications International, is: what will happen to luggage,
cargo, etc., possibly including foods and other items that can be ingested
or will be in close proximity to persons for long periods of time, after
passing through such neutron beam systems once or possibly many times in the
course of complex or multiple trips?  Are airline passengers to be subjected
to the radioactive luggage and cargo simply because the emission levels meet
"government standards"?  Will the frequent traveler be at greater risk than
the occasional traveler?  What is the real story about these systems?

     In case you're wondering who will be the first guinea pigs for this
technology, it's the folks in the SF Bay area.  San Francisco International
(SFO) is slated to get the first prototypes of these devices sometime quite
soon for at least a 4-week trial.  The equipment is then to be tested at
other major airports and the FAA hopes to have it in widespread use within 2
years.  Apparently the prototypes to be tested are "improved" versions of an
earlier model that required 30 seconds per test--the new equipment bombards
the target material for 6 seconds (possibly longer if the typical conveyer
and luggage problems cause clogs on the transport system).  Of the two
prototypes, one supposedly uses a continuous neutron emitter based on an
internal chunk of some radioactive material, while the other uses a
"turn-offable" system for generating the neutrons.

   Can anyone out there shed some light on the risks associated with this
technology?
               [The computers in this system may or may not present risks, 
               e.g., if the computers are involved in control, or if the 
               signature analysis is faulty.  In any case, the risk issues
               are interesting enough to warrant some KNOWLEDGEABLE
               discussion here.  Let's avoid SPECULATIONS, PLEASE.  PGN]

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

Date: Sat, 18 Apr 87 10:10:56 PDT
From: sun!plaid!chuq@seismo.CSS.GOV (Chuq Von Rospach)
Message-Id: <8704181710.AA11269@plaid.sun.com>
To: cbosgd!mod-back@seismo.CSS.GOV
Subject: How to post a fake

To: darrell@beowulf.ucsd.edu, mod-back

    I'm curious: how can you fake a posting without being root?  When I post
    anything to mod.os (er, excuse me, comp.os.research) I'm always listed as
    the sender.  Not wanting to be the bad guy I've never tried to crack it,
    but I am curious as to the hole that causes the problem.

Darrell asks an interesting question, and I might as well let everyone know
while I'm at it.

As background, be aware that USENET has a major security hole, in that there
is no way for the program rnews to know where a message came from.  It has
to implicitly trust the information in the header of the message.  While
uucp does site verification across the net, that information is not passed
along through uux to the executed program on the other side.  It has to
trust the data it gets.

This leads to a trivial hack for creating bogus and untraceable messages.
Take an existing message (I borrowed this one from mod.announce):

	Path: sun!cbosgd!mark
	From: mark@cbosgd.ATT.COM (Mark Horton)
	Newsgroups: mod.announce,news.announce.important
	Subject: mod.announce is being renamed news.announce.important
	Message-ID: <3525@cbosgd.ATT.COM>
	Date: 13 Apr 87 15:09:20 GMT
	Organization: AT&T Bell Laboratories, Columbus, Oh
	Lines: 9
	Approved: mark@cbosgd.MIS.OH.ATT.COM
	Xref: sun mod.announce:24 news.announce.important:1

This is your template. Now, change the header lines to fit, and delete the
Xref line:

	Path: cbosdg!mark
	From: mark@cbosdg.ATT.COM (Mark Horton)
	Newsgroups: mod.announce
	Subject: Newgroup renaming is a failure, film at 11.
	Message-ID: <3.14159@cbosdg.ATT.COM>
	Date: 1 Apr 87 00:00:00 GMT
	Organization: The Backbone Cabal, Inc.
	Lines: 9
	Approved: mark@cbosdg.MIS.OH.ATT.COM

Don't worry about the # of lines, inews will be nice enough to adjust it for
you.  Store that in a file, add the message body to it, and execute:

	% /bin/rnews < file

rnews will read it just as if it had come over the network, and install it.
It believes everything you said in the header.  When it passes it along, the
Path: becomes "sun!cbsogd!mark" and it gets passes along just like a real
message.  The only place where this is traceable is the Path variable,
because you can see that my site is at the beginning of the list of real
paths.  You can avoid this in a couple of ways if you want to be real
sneaky:

	o the kremvax syndrome:  instead of having a single address in the
	path, put in a bunch:

	    Path:  kremvax!nsacyber!prarie!wobegon!himom!cbosdg!mark

	depending on your ingenuity, you make make it almost impossible to
	tell where the message joined the net for real.

	o drop out of the loop:  even more fun, rather than execute rnews on
	YOUR site, execute it on someone else's.

	    % uux - -z ihnp4\!rnews < file
	
	the Path is now "ihnp4!cbosdg!mark" and your own site is nowhere to
	be seen.  Completely untraceable, unless someone wants to compare
	uucp's LOGFILE entry times with news 'log' entries and backtrack.
	Which assumes that they figure out it is happening before they flush
	the logs.  And that they have the time, and care.

That's how you forge messages.  And as long as the uucp links exist, there
is no way to fix this, because a vital piece of information isn't passed out
of uucp.

The possibilities are endless, of course.  You can not only post April
Fool's messages, but post messages FOR people that they can never prove they
didn't post.  completely untraceable.  You can change your name, your
machine, your religious background, all untraceable.  Possibly even skip out
on child support, if you find the right control message.  

Kids, don't try this at home!  These people are paid professionals, and know
the risks involved... (grin)

chuq (next week, how to kick a site off the net with cancel messages!)

   [For those of you who never saw the KREMVAX 1984 April Fools' Day hoax, 
   see ACM SIGSOFT Software Engineering Notes. July 1984. vol 9 no 4.  PGN]

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

Date: Mon, 20 Apr 87 14:40:47 EST
From: philabs!rob@briar(Rob Robertson)
To: cbosgd!mod-back@seismo.CSS.GOV
Subject: faking news postings

The only place you can be traced using chuq's "posting techniques" is the
log files.  In the `uux - -z ihnp4!rnews < file` example, the machine and
user name will appear in ihnp4's LOGFILE or HDB's uucico, and uuxqt logs.

I'm not sure but have a funny feeling one can trace the user (by logs) if he
posts it on his machine, beside having his machine on the path list.

The brahms people did a good job of tracking down a person faking articles
by using log files.
                                        rob

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

Date: Wed, 15 Apr 87 15:29:23 est
From: kuhn@ICST-SE (Kuhn)
To: risks@sri-csl.ARPA
Subject: Re: Bank Computers (Not ATMs)

> 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...

This may be a people problem rather than a software design problem.

I spent the first three years of my career writing communications
interfaces for ATMs for one of the major computer vendors.  In the process,
I became familiar with the computing systems of several Washington, D.C. 
banks.  For each transaction type, there is a "correction"
transaction code that will reverse the effects of its corresponding
"normal" tran code.  This follows manual accounting procedure that requires
errors to be explicitly backed out by a separate entry rather than simply
erased.  At least two of the banks that I did work for monitored their 
tellers to keep track of who made errors, when, what kind of error, etc.
If Ken Ross's bank has a system like this, and the tellers are aware of it,
they might prefer not to use a correction transaction that will show up on
a report to their supervisor.

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

Date: Tue, 14 Apr 87 10:02:59 EST
From: msb@sq.com (Mark Brader)
To: neumann@csl.sri.com
Subject: Correction to Conrail Sale Funds Transfer (RISKS 4.72)
ReSent-To: RISKS@CSL.SRI.COM

> [I'm surprised that someone was smart enough to know about the $1
> billion problem before it really did "blow a fuse".  Who knows where
> the $600,000 million might have ended up!...   (Chuck Weinstock)]
          !!!!

Risks of thinking of UK billions in a US story?  This is the second error
of this off-by-000 type to make it to the net in a week or two (the last
one was in sci.astro)...
                           Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb

   [Fortunately Chuck's extra zeroes were detectable from context...  PGN]

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

Date: Wednesday, 15 Apr 1987 10:18:21-PDT
From: rosenbaum%boehm.DEC@decwrl.DEC.COM  (Rich Rosenbaum)
To: risks@csl.sri.com, rosenbaum%boehm.DEC@decwrl.DEC.COM
Subject: "Reliability Theory Applied to Software Testing" in HP Journal

The April 1987 issue of the Hewlett-Packard Journal contains a short
(four page) article entitled "Reliability Theory Applied to Software Testing."

From the abstract:
    The execution-time theory of software reliability is extended to
    the software testing process by introduction of an accelerating 
    factor.   It is shown that the accelerating factor can be determined 
    from repair data and used to make prerelease estimates of software 
    reliability for similar products.

The article describes how the model was applied to the firmware for two
HP terminals.

(Subscriptions to the HP Journal are available without charge from
Hewlett-Packard Journal, 3200 Hillview Avenue, Palo Alto, CA  94304).

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

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