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

RISKS-LIST: RISKS-FORUM Digest  Wednesday 8 May 1991  Volume 11 : Issue 64

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

  Contents:
Cable Zapping (John Sullivan)
Fences, trojan horses, and security (Bob Estell)
More on Almost Humorous Fly-by-Wire Glitch (Mary Shafer)
Old cases of Telco tieup and grade hacking (George Malits)
Re: Changing class grades (Adam Engst)
9th Federal Reserve Bank Drowned (Brinton Cooper)
Denise Caruso reports on new anti-encryption bill: S.618 (John Gilmore)
S.618 via FTP & mail server, instead of flooding Washington (Brendan Kehoe)
NYTimes article on E.F.F and John Barlow (John Sullivan)
Re: Disclosure of customer information (Steve Bellovin, Lauren Weinstein)
Re: The means justify the ends? (piracy probe) (Henry Spencer)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others ignored!  REQUESTS to RISKS-Request@CSL.SRI.COM.  For
 vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, 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 essential.  "CRVAX.SRI.COM" = "128.18.10.1".
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
 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: Wed, 8 May 91 13:08:50 CDT
From: sullivan@poincare.geom.umn.edu
Subject: Cable Zapping

An earlier RISKS had excerpts from an April 25 NYTimes article about American
Cablevision 'zapping' chips inside illegal cable hookups.  Not included were
quotes at the end of the article from some customers who claimed they had only
regular cable service, but had been zapped anyway.  I don't know the laws
governing cable service, but it would disturb me if, say, the phone company
started sending destructive signals down the phone lines.  Perhaps, though,
you're allowed only to connect the cable company's own equipment to your cable.
Otherwise, the cable company sounds just as bad as Prodigy.

I basically feel I have a right to sense my environment.
Though the common disregard for speeding laws is disgraceful, I
believe radar detectors must be legal.  I am bothered by
claims that decoding satellite TV signals is illegal: though of course
I could not resell copyrighted programming, if someone broadcasts
radiation at me, and I'm clever enough to decode it, that should
be allowed.  Cable TV is different, though, since I have
signed an agreement with the cable company to get a hookup.

John Sullivan, Geometry Center       sullivan@geom.umn.edu

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

Date: 8 May 91 14:28:00 PDT
From: "351M::ESTELL" <estell%351m.decnet@scfb.nwc.navy.mil>
Subject: Fences, trojan horses, and security

Just yesterday, I saw a video tape "movie" (docudrama?) offered by the NIS 
(Naval Investigative Service) on "human intelligence."  (It is "security and 
safety awareness week here.)

The points I'd like to pass on, in reply to Rick Smith's posting about "trojan 
horses" are: (1) NIS still believes that "trojan horses" are a SERIOUS threat 
to government RDT&E labs; i.e., "moles" as well as employees who are angry, 
frustrated, broke, greedy, or stupid.  The FBI, et al agree with this opinion.
(2) One reason that the threat is NOT more serious (i.e., that the damage
is usually limited) is that we've made serious efforts to reduce the risks.

Yes, it is hard to spot a trojan horse (or virus, etc.) in a software package.
It is also hard to spot a spy in a crowd.  For the last several years, they
have abandoned wearing trench coats, carrying daggers and magnifying glass, and
speaking in obvious accents.  True, the physical analogy is limited; every
analogy is.  (That's true by definition of "analogy.")  But the typical
computer security person still has things to learn from it.
                                                                  Bob

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

Date: Mon, 29 Apr 91 20:10:10 PDT
From: Mary Shafer <shafer@skipper.dfrf.nasa.gov>
Subject: More on Almost Humorous Fly-by-Wire Glitch (RISKS-11.61)

Joseph Nathan Hall (jnh@eceugs.ece.ncsu.edu) writes:

      From the pages of Popular Science, April 1991:

   "...Spectators at the first flight of Northrop's [YF-23] prototype
   noticed its huge all-moving tails--each larger than a small
   fighter's wing--quivering like butterfly wings as the airplane
   taxied out to the runway.  Test pilot [Paul] Metz says this
   occurred because the early generation flight-control software
   didn't include instructions to ignore motions in the airframe
   caused by pavement bumps.  The answer, he adds, is inserting lines
   of computer code that tell the system not to try to correct for
   conditions sensed when the fighter's full weight is on its nose gear."

Talk about a pack of slow learners.  I remember sitting in the control room
watching the AFTI/F-16 waving its canards and tail at every expansion joint in
the taxiway.  They finally stopped it with a squat switch.  But I shouldn't
criticize the YF-23 team too much, because the X-29 didn't have one originally,
either.

   I'll grant that in the 1990s we can analyze wind-tunnel tests in a
   few hours (or less) and can even simulate untested airframes with
   some success.  In the 1950s pilots frequently flew prototypes
   before the final results of early wind-tunnel tests were completely
   analyzed--a process that sometimes took weeks or months.  But am I
   alone in thinking that in some respects it takes more chutzpah to
   test-fly one of these modern fly-by-wire wonders?  <shudder

What do you think they do, drop in a computer and tell the pilot to take it
around the pattern a couple of times?  No wonder everyone's so goosy about
fly-by-wire.  We're talking about V&V here--verification and validation.

The very least they will do is hot-bench testing, with all the hardware in
place and the best aerodynamic model in a computer.  They may well have had an
iron bird, although I doubt it.  The B-2 maybe, but not the YF-23, in my
opinion.  The iron bird for the F-8 Digital Fly-by-Wire (DFBW) was an F-8C
airframe, with the wing tips removed and the engine gone.  The hydraulic
system, the actuators, the surfaces, the FCS computers--all the "real"
hardware, with the aerodynamics in a computer.  I don't think there were iron
birds for the F-16 or F-18, since our experience with the F-8 DFBW indicated
that it was at best an act of supererogation and at worst a red herring.  We
spent months trying to take care of a problem that turned out to be unique to
the iron bird itself.

The X-29, 30-per-cent statically unstable little beast that it is, didn't have
an iron bird and it was a great deal more experimental than the YF-23.  Nor did
the HiMAT or the Shuttle.

A good FCS is sufficiently robust that it can deal with variations in the
stability and control derivatives.  In general, the initial FCS will be tuned
when the derivatives are determined during the envelope expansion that is the
first part of the flight program.  We have a pretty good idea just how good or
bad a particular derivative from the tunnel tests is and we can make worst-case
assumptions based on the historical error margins.  This is called parametric
variation.  I was involved in just such an assessment for the Space Shuttle
back in the mid-70s.

There is an interesting example of FCS robustness from the Shuttle.  Rolling
moment due to yaw jet is not only twice the predicted magnitude, it has the
opposite sign.  The FCS was sufficiently robust to deal with this, although
hand-flown roll reversals replaced the preprogrammed ones until the FCS was
refined after STS-5.

I've asked our pilots about this and they don't think that it takes anything
more from the pilots to fly modern FBW aircraft.  The F-8 DFBW, the first
digital FBW airplane, was, they say, a little more exciting, because it had no
reversion mode.  But modern FBW is no big deal.  One of them does admit to
being a little nervous about the forward-swept wing on the X-29, though.

Mary Shafer  shafer@skipper.dfrf.nasa.gov  ames!skipper.dfrf.nasa.gov!shafer
           NASA Ames Dryden Flight Research Facility, Edwards, CA

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

Date: Mon, 6 May 91 18:19:25 EDT
From: malits@apache.sw.stratus.com (George Malits)
Subject: Old cases of Telco tieup and grade hacking

1) on the topic of a computer failure at the fed reserve, RISKS-11.62.
Consider this.  In the mid 70's sometime, a disgruntled x-employee of the phone
company started a number of wastepaper basket fires in various telco
facilities.  He got lucky at Irving place and destroyed a switching facility.
A goodly chunk of Manhattan was without phone service for several MONTHS.  What
would the effect have been if he had chosen a different facility?  Like one
that serviced Wall St?

Let me tell you what I remember.  The year would be in the 74-76 range and the
facility attacked was the telco building on Irving place in Manhattan (around
15th and second).  In any case, it was quite the fire and the switch was
rendered scrap.  What we (the telephone dialing public) found out was that
these switches are normally custom built and ordered years in advance.  The
solution was to ship whatever switch was under construction to Manhattan and
"make it fit".  This also involved shipping the people building the switch to
Manhattan so that they could continue to build the second half while other
tech's were installing the first half.  Meanwhile, no phones.  Small business
men were using CB to communicate with friends/family outside of the affected
area who would then relay the call.  Telco set up banks of microwave link phone
booths at certain street corners but....In any case, the key limiting factor
turned out to be the space available in the cable lockers in the basement.
They were so cramped that only one or two techs could work at a time.  Also,
it was so hot down there that they worked REAL SHORT shifts.  Their progress
was of course a hot topic in the news.  I remember that there was some key
piece of diagnostic equipment (?) and that something like 3 of the 5 units in
the US were in use in Manhattan.  I don't have any good references for further
details (I read about it in the Daily News at the time) but it was quite a big
tadoo so I suspect that it would have been covered in some journal or other.

2) Computer hacking of grades, RISKS-11.62.  Back at Columbia, in the mid 70's,
several prof's kept a list of the various test grades on line.  This was a
completely "unofficial" set of grades for their own use.  We discovered it and,
from looking around the directory a little, figured out that they were
computing "the curve" from this file and thus assigning final grades for the
class.  After MUCH discussion, we decided that the way to turn this to our
advantage was to either add non-existent students who did very poorly on all of
the tests or to lower the grades of real students that we didn't know/like.
The idea was to lower the curve but leave our own grades unaltered (no smoking
gun).  In the end, we whimped out but I did add one line to the file that said
"do you know how tempted I was to change this file".  I figured I'd give the
prof something to think about.

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

Date: Mon, May 6, 1991 7:24:42 PM
From: Adam Engst <ace@tidbits.UUCP>
Subject: Re: Changing class grades (RISKS-11.62)

>    Concannon, a database specialist at the university's statewide computer

Does anyone have any more information about this case? It strikes me as a
little odd that this guy would have changed a random student's grades so
radically. It seems more likely that there was some collusion present between
Concannon and the student, at which point the management sorts might want to
think about the why and how such collusion, if indeed present, became possible.
No mention is made of what happened to the student, if anything, which would
clear up my question slightly. Somehow I doubt that database people are
recompensed handsomely enough in general to prevent the occasional incident of
bribery in whatever form.

Just curious ... Adam Engst, TidBITS Editor

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

Date:     Wed, 8 May 91 17:52:12 EDT
From: Brinton Cooper <abc@BRL.MIL>
Subject:  TMPLee: 9th Federal Reserve Bank Drowned

TMPLee@DOCKMASTER.NCSC.MIL reports

"On Monday April 8 the computer center at the Minneapolis Federal Reserve Bank
was flooded out of commission by a broken air-conditioning cooling water pipe
in the ceiling.  [I'll ignore the RISKs of such a design; the point of this
note is something else.]"

Let's not ignore this and similar risks.  In an effort to minimize the risks to
the environment, we are strongly urged not to use Halon to extinguish computer
room fires.  This puts us back to sprinkler (water) systems.  The advantage to
Halon was that it was unlikely to do secondary damage to the installation;
water has no such feature.

Now what?   _Brint

    [To stave off discussion on halon itself, let me point out to new RISKSers
    that we have had numerous discussions in RISKS in the past:
RISKS-5.28
  Halon (Dave Platt, Steve Conklin, Jack Ostroff, LT Scott Norton, Scott Preece)
RISKS-6.79
  Risks of Halon to the environment vs. risks of other fire protection
    (Dave Cornutt)
RISKS-6.87
  Halon environmental impact citation (Anita Gould)
RISKS-6.89
  Halon environmental impact citation (Jeffrey R Kell)
RISKS-7.03
  Halon (Romain Kang)
RISKS-7.04
  Halon agreement and the ozone models (Rob Horn)

     Just in case you really want to get gassed on this subject.  PGN.]

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

Date: Mon, 6 May 91 11:54:15 PDT
From: gnu@toad.com (John Gilmore)
Subject: Denise Caruso reports on new anti-encryption bill:  S.618

Denise Caruso wrote a great piece for her "Inside Technology" column of the
Sunday, 5 May 1991, SF Examiner, on page E-14.  It concerns the attempts
to outlaw encryption and why that is a bad idea.  She claims that there
is a second bill that has had anti-encryption stuff quietly slipped into it
last week by the FBI: S.618, "The Violent Crime Control Act of 1991".

I'll quote her closing paragraph to encourage you to get and read it all:

	"I want crime to stop.  I want terrorism to stop.  But do we
	want to secure the networks or not?  I have *never* seen
	evidence that power in the hands of government authority
	didn't corrupt.  I have never heard of a compromise-able
	network that didn't get compromised.  With increasing reliance
	on computer-based networks, back doors for law enforcement (or
	whoever else figures it out) make me afraid.  I don't think
	they're a good idea."

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

Date: Wed, 8 May 91 14:39:26 -0400
From: Brendan Kehoe <brendan@cs.widener.edu>
Subject: S.618 via FTP & mail server, instead of flooding Washington

  Senate bill S.618 is available via anonymous FTP from:
	ftp.cs.widener.edu [192.55.239.132]
  in the file
	pub/cud/law/bill.s.618
  as part of the Computer Underground Digest archives.
  It's about 227k, so please try to do it after 5pm EDT.

  Hopefully this will save the taxpayers a few dollars.

     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone

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

Date: Wed, 8 May 91 13:20:49 CDT
From: sullivan@poincare.geom.umn.edu
Subject: NYTimes article on E.F.F and John Barlow

The New York Times Magazine, April 21, 1991, had an article "In Defense of
Hackers" by Craig Bromberg.  The article is based substantially on discussions
with John Barlow (founder of EFF), pictured as an "electronic cowboy".  The
cases discussed (including rtm, Craig Neidorf's 911 memo, and Steve Jackson
Games) are familiar to risks readers, but it is nice to see a well-reasoned
discussion in the mainstream press.

John Sullivan,  Geometry Center      sullivan@geom.umn.edu

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

Date: Wed, 08 May 91 15:28:13 EDT
From: smb@ulysses.att.com
Subject: Re: Disclosure of customer information (AT&T)

Lauren relates a story of someone posting confidential information based on
internal AT&T data.  So what?

As noted, misuse of such data is already against the rules.  It is quite likely
that the individual will be disciplined, possibly even fired.  I don't see that
there would have been any greater protection if a Federal law were involved.
If someone chooses to act unethically, rules, at whatever level, won't stop
them.

Talking about inadequate technical protection of data doesn't wash in this
case.  I haven't seen any evidence that the employee in question wasn't
authorized to retrieve that data -- maybe that person did have legitimate
access to that database.  This is not a situation where an outsider called up,
and was able to bluff or hack a way in.

Ultimately, security rests on people.  The most sophisticated technical means
in the world provide no protection against a suitably-placed, suitably-skilled,
dishonest person.  Organizations that care about security know this, of course;
critical objects (large sums of money, missile launch systems, etc.) are
protected by at least two individuals.  But for routine access, it would be
crippling to the organization to do that, and I don't think that that's
fixable.
 		                 --Steve Bellovin

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

Date: Wed, 8 May 91 13:31:33 PDT
From: lauren@vortex.com (Lauren Weinstein)
Subject: Customer Info Disclosure (AT&T)

I think Steve may have partially misinterpreted the thrust of my recent
message.  In no way did I mean to imply that a "technical" problem was at the
heart of the recent AT&T customer information disclosure.  In this particular
case, it is clear that a "people" (and possibly a policy) failure occurred.
Whether or not the employee in question had a legitimate "need to know" the
information in question, and so whether or not he *should* have had access to
the data, are important questions, however.

The reason I brought up the related issues of automated account interrogation
systems and the like is that information privacy is based on the triad of
policies, people, and technology.  No one element stands alone.  The current
lack of adquate standards relating to all of these areas is resulting in far
too much information being passed around, both within and between
organizations, without adequate controls.  Failure or inadequacy of elements in
any leg of the triad can have significant negative results as far as the end
effects are concerned.

A key point that technologists need to be concerned about is that the available
technology may result in policy and people failures that are much more
far-reaching than might have occurred without the speed and finality that these
systems allow.  One obvious example among the multitude: A single "people"
error in a credit entry, propagated through credit bureau databases through
lack of adequate policy controls and checks, can cause an individual incredible
hassles--or much worse.

More and more, the transactions of our lives are being viewed as the raw data
of targeted marketing.  The telcos and long distance carriers would like to
market calling pattern data to businesses who would use that information to
"target" customers of interest.  The credit card companies use customer buying
information to cross-promote other merchandise through outside firms.  Even if
you view these particular cases as relatively "innocuous" (though I would
disagree with you!)  these are but the tip of the iceberg.

The issues related to customer information collection and the subsequent access
to, marketing of, and use of that data for purposes that the customers might
not even imagine, need to be addressed as broadly as possible.  Attempting to
deal with them purely from the standpoint of one or two legs of the triad won't
work.  The policies, the people, and the technology must all be considered, and
where appropriate, minimum standards for the handling and control of this
information must be mandated by law.

As others have pointed out, it starts to look more and more like the proverbial
Big Brother won't necessarily be a government entity (at least in this
country).  Rather, it might be Big Brother, Inc.
                                                        --Lauren--

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

Date: Sun, 5 May 91 00:45:37 EDT
From: henry@zoo.toronto.edu
Subject: The means justify the ends? (piracy probe)

>  The evidence was obtained by a consultant employed by DEC at attend
>  a Syntellect training course in February. He copied it's system
>  software which was later examined by DEC. [...]
>
>... Surely the consultant ... didn't ask for permission to copy their
>system? In which case, is the evidence not inadmissable by virtue of
>being gained by illegal means?

What law has been broken?  That wasn't *their* software.  You don't own the
licensed software running on your system; if you inspect the license agreements
carefully, you will find that the authors retain ownership, and you have bought
only the right to use it.  You are usually required to protect it from
unauthorized copying, but copying done by the owner's representative, with or
without your knowledge, hardly qualifies.

                            Henry Spencer at U of Toronto Zoology utzoo!henry

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

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