11-Apr-87 14:40:23-PDT,20456;000000000000
Mail-From: NEUMANN created at 11-Apr-87 14:39:03
Date: Sat 11 Apr 87 14:39:03-PDT
From: RISKS FORUM    (Peter G. Neumann -- Coordinator) <RISKS@CSL.SRI.COM>
Subject: RISKS DIGEST 4.73 
Sender: NEUMANN@CSL.SRI.COM
To: RISKS-LIST@CSL.SRI.COM

RISKS-LIST: RISKS-FORUM Digest  Saturday, 11 April 1987  Volume 4 : Issue 73

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

Contents:
  Unintentional information dissemination (George W. Dinolt)
  Computers & Personal Privacy (Steve Thompson)
  Air Traffic Control in the UK (Lindsay F. Marshall)
  Air Traffic Control in the USA (PGN)
  Re: "Inherently safe nuclear reactors" (Jim Carter)
  Submarine reactor safety (Jim Hunt)
  Re: A different RISK? (in-flight control computers) (Ronald J Wanttaja)
  Risks"-taking" of in-flight control computers (Eugene Miya)
  Software Risks with Cable TV (Walt Thode)
  The UNIX rwall problem ["My Broadcast"] (Jordan K. Hubbard) 

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: Thu, 9 Apr 87 14:05:51 MST
From: dinolt@Ford-wdl1.ARPA (George W. Dinolt)
To: risks@csl.sri.com
Subject: Unintentional information dissemination

I thought the following article would be of interest to RISKS readers.  
The risks of people disposing of equipment who are unfamiliar with the
technology used there in can lead to all sorts of interesting problems.  GWD

From COMPUTER CURRENTS, Vol 4 #22, 7 April 1987, p68  from the NEWSBYTES
UK section by Steve Gold,

            BARGAIN COMPUTER HOLDS STATE SECRETS

OXFORD, UK - Irangate had nothing on this one.  The "London Times"
revealed last month that an Oxford student got more than he bargained
for when he bought a second-hand computer for 45 pounds ($68) at WS
Surplus Supplies in his home town.
     Upon booting the used 64K CP/M computer, Mark Storer found an
array of expensive programs available, as well as more than 1,500
files still intact on the machine's 40Mbyte hard disk.  When he peeked
at the files, Storer realized the computer's origin - The Royal
Signals and Radar Establishment in Malvern, Worcestershire.  
     Aside from being a Ministry of Defense establishment, the Malvern
site carries out some very hush-hush research into the kind of things
we can't print.  Suffice it to say that the files included lists of
base personnel, their job descriptions and personal history, and a
full inventory, with costs, of the base since 1980! 
     "They effectively let me walk inside the base and look through
their files," said Storer, talking to the press of his find.
"NewsBytes UK" understands that the machine has now been returned to
the Defense Ministry and that a full investigation is under way.

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

Date:         Thu, 09 Apr 87 01:46:43 EDT
From:         Steve Thompson <THOMPSON%BROWNVM.BITNET@wiscvm.wisc.edu>
Subject:      Computers & Personal Privacy
To:           Risks Forum <RISKS@CSL.SRI.COM>

From the Friday, 27 March 1987 edition of *The Providence Journal*:

        Union official sues Journal for probe into background

PROVIDENCE - The interim administrator of the Providence Newspaper Guild is
suing the Providence Journal Co. and Equifax Inc.  for $1,050,000, alleging
that they illegally used computerized personal information about her as part
of an investigation into her background.

In a suit filed Monday [ 23 March ] in U.S.  District Court, Susan Zucker,
the interim administrator, said that the newspaper employed Equifax to
conduct an investigation aimed at providing information on her "character,
general reputation, personal characteristics, financial characteristics,
mode of living, strengths and weaknesses, estimated net worth, financial
difficulties, home surroundings and credit record."

Zucker asserts that Equifax submitted a report containing such information
to the Journal company.

She said both companies violated federal law governing how such information
may be used, because she was never an employee of the Journal Company nor a
candidate for employment, and because she never gave the newspaper nor
Equifax permission to review her background.

        [ Neither of the companies would comment. ] ....

I found this notable not only because of the alleged misuse of computerized
records, but 1) because of how much information about details of the case
was not reported, and 2) that the charged newspaper printed the article at all.

Stephen W. Thompson, User Services Specialist, User Services
Brown U., Box P, Providence, RI  02906  USA         (401) 863-3619        

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

From: "Lindsay F. Marshall" <lindsay%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Date: Fri, 10 Apr 87 08:50:55 gmt
To: risks@csl.sri.com
Subject: Air Traffic Control in the UK

A recent report claims that the system installed at West Drayton (which
controls Heathrow) fails several times a month. The hardware was installed
in 1971 and the only other working version of it (in the UK) is in the
Science Museum!! The report says that if the computer were a plane it would
have been grounded years ago and that the CAA are not even handed about this
situation. (They do admit that the near misses that occur are mostly due to
operator error). A spokesman from the CAA has refuted these claims stating
that there have been only two failures in 3 months due to software and one
failure due to a faulty power supply. He also claimed that the hardware was
not obsolete but that it was due for replacement in two years time.

The report was produced from confidential interviews with air traffic
controllers by the Institute of Medicine and Avionics (??????)

Sorry if this is a bit vague - it's second-hand information.   Lindsay

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

Date: Sat 11 Apr 87 14:32:21-PDT
From: Peter G. Neumann <Neumann@CSL.SRI.COM>
To: RISKS@CSL.SRI.COM
Subject: Air Traffic Control in the USA 

I noted two items recently of interest here.

1. Operational errors by U.S. air traffic controllers increased by 18
percent in the three month period that ended March 26, as compared with the
same period a year earlier...  Many of the errors appear to be caused by
poor cmmunication, lack of coordination and ineffective use of equipment.
[From an internal FAA message from Keith Potts, associate administrator
for air traffic control, SF Chron, 9 April 1987]

2.  Air near-misses were up 29% in 1985 (758) over 1984 and up 42% in 1986
(839) over 1984.  [PBS, 9 April 1987]   Another source cited 866 near air
collisions in 1986, with 497 near-misses on the ground.  It also noted that
the shortage of controllers had resulted in their being paid overtime three
times as much as previously...  [SF Chronicle, 10 April 1987]

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

Date:           Thu, 9 Apr 87 12:25:08 PDT
From:           Jim Carter <jimc@CS.UCLA.EDU>
To:             risks@csl.sri.com
Subject:        Re: "Inherently safe nuclear reactors" (RISKS-4.71)

In RISKS 4.72 Phil Ngai <{ucbvax,decwrl,hplabs,allegra}!ampcad!phil} writes
about reactivity control in American nuclear submarine reactors.  In
addition to those, all NRC-licensed reactors have the negative temperature
coefficient of reactivity he describes.  Also, when pressure is lost the
boiling in the core greatly reduces reactivity.  It also ensures heat
removal with the coolant pumps out of action, provided the vessel and
pipes are full of water.  Kraftwerk Union even has a natural convection
reactor without any pumps.  These are good examples of inherently safe
systems, provided water flood can be assured, as in a bathtub design.

Flooding a naval reactor with seawater would shut it down since the
chlorine in the water absorbs neutrons.  I believe that river water would
not give a sure shutdown unless the pollution level was quite high.  In
commercial reactors there are large reserves of water loaded with borate,
a strong neutron absorber, to be actively injected into the core.  Active
injection is not inherently safe.  A bathtub would be better.

James F. Carter            (213) 206-1306
UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024-1600
UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc  ARPA:jimc@CS.UCLA.EDU

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

Date: Fri, 10 Apr 87 15:50:24 PST
From: c9b-rd%dorothy.Berkeley.EDU@berkeley.edu (Jim Hunt)
To: RISKS@csl.sri.com
Subject: Submarine reactor safety

From RISKS 4.72:  (_The Hunt for Red October_, and _Submarines_) ...

The author of "..Red October" has never been underway on a US submarine.  He
has talked to a lot of people, and taken a civilian tour certainly.  He
makes a great yarn, and invents some plausable explanations, but (unless
someone PUT IN those gross errors I noted) he guessed it all.  The reactor
coolant is regulated to within a few degrees, and in operation is held much
more closely than that, with some variation, soon corrected, upon a change
in bell (speed order).  It may be that the author knew this, since it is
obvious that thermal stress is undesirable, but needed a way to have a core
meltdown for plot reasons. (there is also NO installed way to flood the RC,
submarines BARELY float as it is) Since this is not in line with comp.
risks, the subject should be dropped from this forum.  I would like to offer
my services as a source of correct information in the future.  I won't give
away secrets, but it will be the truth.  If you, or anyone else has
questions on the errors in that book, or US attack submarines in general,
feel free to write to me.  This is not the first time I have gagged on a
statement on submarine operations or equipment as posted in this group.

Jim Hunt hunt@ucbcory.Berkeley.EDU hunt@ucbcory.BITNET (Ex. ET2(SS) )

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

Date: Fri, 10 Apr 87 10:48:39 pst
From: ucbcad!ames!uw-beaver!ssc-vax!wanttaja@ucbvax.Berkeley.EDU (Ronald J Wanttaja)
To: uw-beaver!CSL.SRI.COM!RISKS
Subject: Re: A different RISK? (in-flight control computers) (RISKS-4.72)

I don't see this as a risk that can be eliminated without a whole lot of
sensing and evaluation of the pilot's real-time condition.

The G-limits programmed in operate on the assumption that the pilot is
actively helping keep himself concious... there are physical acts a pilot
can take under that will help keep him concious while undergoing Gs.  In 
the Candian F-20 crash, the report mentioned that the pilot had flown the
sequence several times that day, and that he was probably somewhat
fatigued.  It speculated the pilot may have not been as enthusiastic with
his anti-G straining, and the G-induced loss of conciousness resulted.

Obviously, the flight computer needs to sense the pilot's physical state,
and back off the Gs if the pilot shows signs of going under.  Fighter
pilots are not going to like this, of course, since it takes an element of
control out of their hands.  The problem of how to hook up the appropiate
sensors to the pilot, while allowing him full freedom of movement and
quick, *gentle* disconncection during ejection, is left as a problem for
the reader...
				 Ron Wanttaja (ssc-vax!wanttaja)

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

To: risks@csl.sri.com
Subject: Risks"-taking" of in-flight control computers
Date: 09 Apr 87 10:39:10 PST (Thu)
From: eugene@ames-nas.arpa

Peter Ladkin writes:
>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 ... leads pilots to enter maneuvers in which
>they do in fact lose consciousness, inadvertently.

I think the causality is blurred in this example.  I think this is more a case
of risk-taking overriding risks (trying).  High performance aircraft like the
F-16 are actually capable of even greater G turns.  We have an aircraft name
the HiMAT which I think will take a 20G, but it is a remotely piloted vehicle. 
When you use words like "due to" and "leads," these are implications against
the computer when in fact pilots are pushing their bodies' envelopes and not
the plane's envelope.  [The computer "made me do it"?]

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

See Top Gun.  Try also "simulated combat."  I don't vouch for the realism
of the movie only the personalities of this type of flyer (push the limits).
Remember, the computer is NOT programmed to take the controls
from the pilot in event of backout, and it's not clear to me that it
should [Pilot's associate for pilots out there?].

I decided to comment about this note because it was from Peter (a known
risk-taker) when some friends and I met him (we went to do the same rock
[climb] down in Pinnacles Natl. Mon. [separate parties]).  I think
the situation is somewhat like putting a computer on own's back which
prevents one from climbing above some rating (while trying to push one's
skill ever higher).
                                        --eugene miya

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

Date: 10 April 1987 0751-PST (Friday)
From: thode@nprdc.arpa
To: risks@csl.sri.com
Subject: Software Risks with Cable TV

Cable TV risks attributed to software, and subsequent risks of bodily harm --
From the San Diego Evening Tribune (TV/Radio critic's column), April 9, 1987:

  Pay per view.  It's as important to some people as their telephones, and
  when it doesn't work as well, they get very unhappy.

  Like Monday night when the Sugar Ray Leonard - Marvin Hagler
  middleweight title fight live from Las Vegas went down for the count in
  thousands of San Diego households.  In what Cox Cable general manager
  Robert McRann calls "a software problem...a programming mixup," 4,510
  customers missed part or all of the fight after they paid $30 to $40 for
  pay-per-view coverage.

  People got so upset that Cox had to call the cops when some 300
  frustrated people began milling around the lobby at Cox's Euclid Avenue
  headquarters.

Apparently all ended relatively well.  No violence was reported, and Cox
customers got refunds and/or vouchers for future cable pay-per-view
events.  Cox spokespeople asserted that this was their first serious
problem in over two years of pay-per-view baseball games, movies, and 
other special events such as the recent Wrestlemania, for which over
10,000 people (!) signed up. 

--Walt Thode (thode@NPRDC)

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

Date: Thu, 2 Apr 87 10:45:46 PST
From: jkh@violet.Berkeley.EDU (Jordan K. Hubbard)
To: hackers_guild@ucbvax.Berkeley.EDU, tcp-ip@sri-nic.arpa
Subject: My Broadcast [The UNIX rwall problem]

     [The following message was submitted to RISKS by 6 different people.
     I initially thought it might already have been widely circulated, but 
     its repeated receipt has led me to include it here anyway.  PGN]

By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have replied to
every one (either with a form letter, or more personally when questions were
asked). The intention behind this effort was to show that I wasn't
interested in doing what I did maliciously or in hiding out afterwards and
avoiding the repercussions. One of the people who received my message was
Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he
wasn't exactly pleased.  (I hear his Interleaf windows got scribbled on)

So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"

I will attempt to explain.

I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man[ual] page said:

  ...

     Any of three fields can be empty, in which case it signifies
     a wild card.  Thus

                universal (,,)

     defines a group to which everyone belongs.  Field names that ...
  ...


Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.

Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.

Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?

All of this has raised some interesting points and problems.

1. Rwall will walk through your entire hosts file and blare at anyone
   and everyone if you use the (,,) wildcard group. Whether this is a bug
   or a feature, I don't know.

2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
   who you are as long as you're root (which is trivial to be, on a work-
   station), I have to wonder what other RPC services are open holes. We've
   managed to do some interesting, unauthorized, things with the YP service
   here at Berkeley, I wonder what the implications of this are.

3. Having a group called "broadcast" in your netgroup file (which is how
   it comes from sun) is just begging for some novice admin (or operator
   with root) to use it in the mistaken belief that he/she is getting to
   all the users. I am really surprised (as are many others) that this has
   taken this long to happen.

4. Killing rwall is not going to solve the problem. Any fool can write
   rwall, and just about any fool can get root priviledge on a Sun workstation.
   It seems that the place to fix the problem is on the receiving ends. The
   only other alternative would be to tighten up all the IMP gateways to
   forward packets only from "trusted" hosts. I don't like that at all,
   from a standpoint of reduced convenience and productivity. Also, since
   many places are adding hosts at a phenominal rate (ourselves especially),
   it would be hard to keep such a database up to date. Many perfectly well-
   behaved people would suffer for the potential sins of a few.

I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!

Jordan Hubbard, jkh@violet.berkeley.edu, (ucbvax!jkh)
Computer Facilities & Communications, U.C. Berkeley

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

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