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 11 Issue 85

Saturday 8 June 1991

Contents

o DoD News Release on missed Scud intercept at Dhahran
Scott A. Norton
o Thrust reversers
Mary Shafer
o RISKS of Management Attitudes
Tim Steele
o Company BBS eavesdropping
Andy Duane
o Re: Government should have less access?
Michael L. Duerr
Martin Ewing
o Re: Government listening to the airwaves
John Gilmore
Geoff Kuenning
o EFFector Online 1.07: S.266 Loses First Round
Christopher Davis
o Proposed Credit Reporting legislation
Mike Cepek
o Caller-ID and Risks/Benefits of reusing commands
David Lesher
o UUNET sending Usenet tapes to the FBI
Rick Adams
o The Activated Active Badge Project
anonymous
o Info on RISKS (comp.risks)

DoD News Release on missed Scud intercept at Dhahran

Lt Scott A. Norton, USN <norton@manta.nosc.mil>
7 Jun 91 16:25:47 GMT
Here is the DoD News Release that provides some information on the failure of
Patriot batteries to intercept the Scud missile that hit the Dhahran barracks.
-Scott Norton <norton@NOSC.MIL> [Quoted text follows]

 Assistant Secretary Of Defense, Public Affairs, Pentagon, Washington DC
  A/V 225-3886 (912)695-3886
       - - - - - - -
  DEPARTMENT OF DEFENSE NEWS
   WEDNESDAY, JUNE 5, 1991
        * * * * * * * *

 Department of Defense News Editor:  Mr. Frank Falatko

                   - - - - - - - - - - - - - - -
MEMORANDUM FOR CORRESPONDENTS, WEDNESDAY JUNE 5, 1991

REPORT ISSUED ON SCUD MISSILE ATTACK
    The Department of the Army announced today the results of its review of
the investigations pertaining to the Scud missile attack against Dhahran, Saudi
Arabia, on February 25, 1991:

    That evening a Scud missile impacted into a warehouse used by U.S. Forces
as a barracks in Dhahran, Saudi Arabia, killing 28 and -wounding 98 U. S. Army
soldiers.

    Two investigations were initiated shortly after the attack.
One focused on Patriot operations and the other on actions taken at the
barracks that was attacked.

    The investigation of Patriot operations concluded that an inexact computer
software calculation is the most likely explanation as to why the battery did
not effectively detect or track the incoming Scud.  A similar problem of this
nature was first documented on February 20 after analysis of an earlier Scud
engagement.  The four days of continuous operation by the battery, caused by
increased day and night Scud activity, are thought to have compounded this
software problem.  Updated software fixing this problem and containing other
improvements arrived at the battery's location on February 26.

    The investigation of the barracks concluded that Scud attack procedures
were properly followed.  More specifically, upon warning of a potential Scud
attack, soldiers had instructions to go inside or get under cover in either
concrete bunkers or bomb shelters, if available, and to put on helmets and
chemical protective gear.  It was impossible to determine precisely how much
warning time the soldiers ha but it appears that they were alerted
approximately 30 seconds prior to the Scud's impact.  Both U. S. and Saudi
emergency medical response was timely.

    The investigation of Patriot operations was conducted in theater by
officers from the 11th Air Defense Artillery Brigade.  An independent technical

review from the Patriot Project Office at Redstone Arsenal concurred with the
findings of the investigation.

    Six Patriot batteries were located in the Al Jubayl-Dhahran- Bahrain area.
Two were positioned to engage this Scud missile.  One of these batteries was
out of action for repair of a radar receiver.  The remaining battery was
operational and prepared to engage an incoming Scud missile.

    The operational battery was positioned to fire in the automatic mode
against Scuds threatening an area surrounding the Dhahran air base.  Scuds
threatening outside of this protected area but within the Patriot's engagement
capability could also have been engaged manually.  The barracks was located in
this manual engagement zone.  Because the Scud was not effectively detected or
tracked by the radar, engagement in the manual mode was precluded.

    The investigation reconstructed the circumstances of the Scud attack and
evaluated the possibility of Patriot hardware, software, or operator error.

    Based on diagnostic checks conducted before and after the attack, hardware
failure was ruled out.  Operator error was also eliminated as a cause based on
a review of Patriot crew procedures.

    The Army deeply regrets the loss of life and extends its sympathy to the
families of those who died or were injured.


Thrust reversers (Sims, RISKS-11.84)

Mary Shafer <shafer@skipper.dfrf.nasa.gov>
Thu, 6 Jun 91 22:35:42 PDT
Yes, they're still using these two Shuttle Training Aircraft (STA).
One of them was here at Edwards last week, for rehearsal for the
current mission.  JSC will send one (or both, it varies) the day
before the landing.  They'll put it up before landing, to get the
winds aloft for the subsonic portion of the approach and landing.

>To simulate the shuttle's glidepath, you take a G-II up to altitude, ...

I've flown a lifting body approach in a TF-104G Starfighter.  Dirty
up and pull the throttle back to flight idle (no reverser) and drop
like an HL-10/rock/shuttle.  From the backseat it's damn spectacular.

I've seen video/film footage of inflight thrust reverser deployment
for transport aircraft.  This is required for FAA certification of
civil transports.  It's usually a somewhat boring bit of film, since
nothing dramatic happens.  All you really see is the reverser
deploying, which is kind of cute for clamshell reversers.

However, the YF-12 and the SR-71 exhibited a phenomenon known as the "unstart".
Essentially the engine control system (I hesitate to refer to this as a
computer) would get goofed and the inlet would swallow the shock.  The airplane
would yaw violently and lose 10,000 ft.  One of our test pilots likened to it
being broadsided by a train.  The control system was modified and unstarts went
away, much to everyone's relief.

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


RISKS of Management Attitudes

Tim Steele <tjfs@tadtec.uucp>
Sat, 8 Jun 91 15:05:53 BST
When I was working for a British computer company (and major defence
contractor) ten years ago, I had an unfortunate experience.

A friend came to me and said that he had discovered that it was possible to
enter the on-line personnel database with *no* passwords from any terminal in
the building.  I found this difficult to believe, so he demonstrated this to me
in a highly effective manner, retrieving data on several senior employees.  The
personnel records included fields for driving licence endorsements and
confidential manager's assessments of the employee.

I was stricken by conscience, and eventually decided to visit Personnel and
explain what I had been shown without revealing my friend's name.  I urged them
to tighten up their security.

Subsequently, Management decided it would be easier to discipline the guilty
party than to add passwords to the personnel system.  A hunt was started, and
my friend was located on the grounds of above average intelligence and a
propensity to work late (we all scrambled for the door at 5pm!).  He was
severely disciplined and threatened with dismissal.

As you can imagine, I didn't feel too good about it...

The thing that really annoys me is that it *was* a cheap solution...

Another occasion when this came up was during my employment with a large
American computer company some years later.  I discovered that a hacker was
probing our network, getting into workstations and then destroying them by the
use of "rm -rf /" as super user.  The penetration was usually achieved by
logging in as the lp pseudo-user which had no password and had a normal Bourne
shell, then exploiting the world-writable / directory.  Both of these security
holes were included in the Unix distribution produced by that company.

I laid a trap for the hacker, and we eventually obtained water-tight evidence
leading back to a terminal port in an office occupied by one employee.

The evidence was submitted to senior management.  We knew that the Company's
written policy in such matters was to summarily dismiss the employee concerned,
so we assumed the outcome was not in doubt.

The management action taken was to ask the employee whether he was responsible
for any malicious action.  He was not confronted with the evidence.  He denied
any such action, and the matter was dropped.

That company is connected to the Internet...
                                                        Tim


Company BBS eavesdropping

Andy Duane <aduane@urbana.mcd.mot.com>
Fri, 7 Jun 91 9:08:23 PDT
In RISKS-11.80 (not 11.79 as previously cited), an anonymous poster tells of
the chilling effects of people in his company discovering they were being
electronically "eavesdropped" by personnel.

In 11.83 there are some suggestions for how to deal with this.

Well, I'd like to relate a "happy" story about BBS eavesdropping.  My old
company had a long-standing BBS called "graf" (short for "graffiti"). It was a
mostly anonymous company-wide BBS that anyone could read or write to. Most
engineers did both, and much of middle and upper management at least read it.
This was pretty much an electronic suggestion box, although you'd be amazed at
what discussions cropped up from time to time. The articles themselves were
anonymous, although a central encrypted log was kept showing who wrote what.
This log was maintained by "GRAF-man", who was *not* a manager of any type. The
log was only to be used if a serious breach of law or policy was observed, and
this almost never happened. All very nice indeed.

Well, I moved to a new company, and brought the code to GRAF with me. When I
arrived there, the personnel manager informed me that she thought it was a
great idea, but only if I would remove from the code all traces of logging! She
wanted to be sure that it was not possible to trace an author at all.

This BBS was not only a great morale booster among the engineers, it provided a
good way to let your superiors know what you thought without having to sign
your name.

Andrew L. Duane (JOT-7), Samsung Software America, One Corporate Dr.,
Andover, MA   01818          decvax!cg-atla!samsung!duane


Re: Government should have less access? (Gilmore, RISKS-11.80)

Michael L. Duerr <motcid!duerr@uunet.UU.NET>
7 Jun 91 18:31:20 GMT
Remember, the risk here is of the government running open - loop with
surveillance technology.  Harassment is not protected by exclusionary rules.
As for dossiers - by saying the magic words "National Security", the government
can ignore Freedom of Information Act requests.  You would never know that
there is a dossier, only that you get audited every year, get thoroughly
searched at customs every time, etc.

Unless there are meaningful sunlight laws the technology should protect the
citizens from the government.  Current trends like [ constitutionally dubious]
national security preemptions, censorship ( a la gulf war ), excessive fees for
access to government information, new forms government employees must sign
ensuring secrecy in all departments, etc.  highlight a trend toward greater
privacy for the government and less for citizens.  Any invasive technology thus
poses serious problems.

Could it happen here?  Well - would most people even notice if it was?


data over radio (Gilmore, RISKS-11.80)

Martin Ewing <ewing-martin@CS.YALE.EDU>
Wed, 05 Jun 91 14:36:25 -0400
But telephone traffic has gone "on the air" for a long time via microwave
links.  This is becoming less of a problem as optical fiber becomes more
universal, but a classical activity of foreign embassies has been to set up
eavesdropping equipment to intercept microwave traffic passing overhead,
especially in Washington.  There was (and is) no legal protection here, except
that it has always been unlawful to divulge any communication you may have
intercepted from such a common carrier circuit.

At the risk of being flagged in Big Brother's computer, I wonder if there are
publicly documented instances of microwave telephone or data transmissions
being tapped for nefarious purposes, besides the embassy example.


Re: Government listening to the airwaves (Florack, RISKS-11.83)

John Gilmore <gnu@toad.com>
Fri, 7 Jun 91 01:41:42 PDT
> Let's please make sure that in your (IMHO, overblown) concern about government
> monitoring we don't cripple the government's ability to enforce laws which
> allow the day to day operations of telecommunications equipment to be smooth.

Let's enable the microphone in every room (there's one in most rooms already --
in the telephone) so we don't cripple the government's ability to enforce
laws which allow the day to day operations of society to be smooth.

Why should your over-the-air conversations be any less private than those
in your house, business, or car?

> Many two-way services are content specific. There are specific channels for
> just about every type of business on the business bands, for example.
> How would you suggest that these be enforced without routine monitoring?

How about allowing the "owners" of these bands to record conversations
and provide them as evidence in a suit?  Why should we pay the government to
listen to every band, when the band's users are already listening and
are even motivated to report and prosecute regular abusers?

If special equipment is needed to track down the abusers, I'm sure
that commercial services will be glad to do it -- some of them for
a contingency fee that comes out of the proceeds of a successful suit.

> Free speech is not the issue in situations like what I suggest. FOr example,
> the business bands, let's say a taxicab channel, for example, is not the place
> to be discussing political thinking.

Telegraphy was not considered a medium for free speech -- and the laws and
regulations around it definitely and obviously didn't have the First Amendment
in mind -- because who would pay $5/word for free speech in the days of penny
newspapers?  But those regs became the precedent for telephone regulation, and
later radio and TV, and later cable.  Who would suspect that the Fairness
Doctrine, or Federal regulation of the content of signals traveling in local
coaxial cables, would come out of prohibitions on use of private code books in
international telegraphy?  [We're having to fight and pray that the same
precedents are not upheld in cases involving computer communications, or we
lose our speech rights in that medium too.]  See Ithiel de Sola Pool's great
book _Technologies of Freedom_.

>                        The issue as I say, is not free speech,
> but rather, the effective and efficient use of the bandwidth.... a matter for
> the FCC to determine, certainly.

It seems to me that effective and efficient use of the bandwidth would be for
the *users* to determine.  The FCC didn't think ASCII was effective use of
bandwidth in the amateur radio service until the late '70's -- transmit in
Baudot, or lose your license!  FCC's concern is *politics*; users are the ones
who want to have high bandwidth and high reliability of communications.

The Bush Administration thinks so highly of FCC's ability to allocate spectrum,
that it wants to *auction* 200MHz previously reserved for the government,
rather than have FCC parcel it out politically.


Re: Listening? (Eric Florack, RISKS-11.83)

Geoff Kuenning <desint!geoff@uunet.UU.NET>
Thu, 6 Jun 91 03:44:15 PDT
> Many two-way services are content specific. There are specific channels for
> just about every type of business on the business bands, for example.
> How would you suggest that these be enforced without routine monitoring?

Well, what sort of leaps (or perhaps pole-vaults) to mind is that the FCC could
wait for a complaint, and then monitor to verify the complaint.  Note that this
is not "routine monitoring."  Most of the business bands (e.g., taxicabs) are
not going to suffer too severely in the meantime, relative to the U.S.'s
historical and constitutional predilection for freedom and restricted
government even at the expense of inefficiency.

    Geoff Kuenning   geoff@ITcorp.com   uunet!desint!geoff


EFFector Online 1.07: S.266 Loses First Round

Christopher Davis <ckd@eff.org>
Fri, 7 Jun 91 17:42:51 -0400
      EFFector Online|EFFector Online|EFFector Online|EFFector Online
      EFFector Online|EFFector Online|EFFector Online|EFFector Online
      Volume 1                                             Issue:1.07
      Friday                                            June 14, 1991

                    SENATE ANTI-ENCRYPTION BILL WITHDRAWN
            WILL BE REPLACED BY A NEW OMNIBUS CRIME BILL -- S.1241
          SENSE OF CONGRESS LANGUAGE RESTRICTING ENCRYPTION REMOVED

    When Senate Bill 266 was proposed, some of its provisions would have
restricted the rights of individuals to secure online communications
through the use of encryption programs. The specific language was:

           "It is the sense of Congress that providers of
           electronic communications services and manufacturers
           of electronic communications service equipment shall
           ensure that communications systems permit the
           government to obtain the plain text contents of voice,
           data, and other communications when appropriately
           authorized by law."

    Let stand, this language would have a chilling effect on encryption.  It
would inevitably compromise individual privacy in telecommunications.  The
Electronic Frontier Foundation and several other groups determined to oppose
this provision.

    In the last issue of EFFector Online, we reported we would register our
opposition to this clause. In this case, Senator Patrick Leahy (D. Vermont),
who chairs the sub-committee on Technology and the Law --a sub-set of the
Senate Judiciary Committee-- was the key to this issue.

    This week the EFF met with Leahy's staff to present our reasons for
the removal of the language dealing with encryption. Today, we were
informed that the encryption clause has been eliminated from the new
crime bill which replaced the bill originally known as S.266. In
addition, Leahy's sub-committee on Technology and the Law has undertaken
to study the issues of encryption and telecommunications technology.

    To continue this dialogue, Computer Professionals for Social
Responsibility, the Electronic Frontier Foundation, and RSA will be
holding an invitational workshop on privacy and encryption in Washington
later this month.  Following the workshop, a press conference will be
held to announce a set of policy recommendations on cryptography.

   The conference will take place on Monday at 2:00 at the National
Press Club (14th & Pennsylvania Avenue N.W.).  All interested parties
are invited to attend.

               -==--==--==-<>-==--==--==-
      Please direct all mail regarding EFFector Online to:
                editors@eff.org


Proposed Credit Reporting legislation

"Mike Cepek, MGI" <cepek@vixvax.mgi.com>
Fri, 07 Jun 1991 21:44:03 CDT
>From a 7-Jun-91 Associated Press article (c/o Minneapolis Star Tribune):

"Four house members [...] have proposed legislation to update the Fair
Credit Reporting Act of 1970.

"Among their proposals are providing consumers with a free copy of their
credit report on request, requiring prompt correction of errors [isn't this
already required?], requiring credit bureaus to notify consumers after
adverse information is placed on their record and prohibiting the release
of information for marketing lists unless consumers consent."

The article goes on and on about the tribulations of two men after credit
agencies `merged' their records with others with the same name (middle
_initials_ were used, one dropped a Jr.).

One lost his job because his Equifax record was `updated' to indicate `his'
guilty plea to a charge of attempting to purchase cocaine [excuse me, what
is this doing on a _credit report_?].  "Equifax [...] admitted making a
mistake, but said it promptly corrected it."

The second man had bill collectors after him about a $1,776 Discover card
bill -- of course he doesn't have a Discover card.  "Even though it took
nine months to clear his record [...] he [said] he feels lucky. [...]  `If
this had happened four months ago, I probably would still be living in an
apartment,' he said."  (He bought a house and car prior to the problem.)

This happened to me.  It only took me _two months_ to get it fixed.  No,
those 60+ and 90+ payments records aren't mine, I said.  No, I've never
lived in North Dakota ("my" former address).  No, my spouse's name isn't
Kathy (my wife gave me the evil eye about that one).  And come on, wake up
you guys, my middle initial is not `J'! (they did know that).

While I have a personal vendetta to fulfill by assisting this potential
legislation, I ask that other U.S. RISKS readers get involved.  While I don't
have all the details, I would think that any RISKS regular would strongly
support those bits I have mentioned.
                                             -- Michael *K* Cepek


Caller-ID and Risks/Benefits of reusing commands

David Lesher <wb8foz@mthvax.cs.miami.edu>
Sat, 8 Jun 91 8:41:12 EDT
After a long and bitter fight between Bell South and the opposition -
spearheaded by the {state, local, federal} law enforcement community and the
domestic violence groups - the PSC approved Caller-ID in Florida. They mandated
universal free per-call blocking, activated by *67, and per-line blocking for
some LE offices/shelters. (Bell wanted no per-line, and per-call limited to a
narrow list of LE offices.)

But it sounds as if Bell South still wants her pound of salt. I hear they've
ALSO set up *67 for a per-call UNBLOCK on a blocked line. So the cop (who has
NO way of confirming that the line she's using is/isn't line-blocked) dials the
same *67 she uses at home, and guess what. The result (besides an appeal) is
that I hear no one is planning to order the per-line block. Hmmmm.

wb8foz@mthvax.cs.miami.edu                          (305) 255-RTFM


UUNET sending Usenet tapes to the FBI

Rick Adams <rick@uunet.uu.net>
Fri, 7 Jun 91 17:12:24 -0400
    Uunet has revealed that they have sold compiled Usenet traffic
    on tape to the FBI.  FCC men and telco security [people] are
    known to read the Telecom Digest.  God only knows who reads RISKS.

"revealed" is hardly the right word. UUNET sends news to over 800
organizations. Thats never been a secret. We also send news out via tape. There
are two reasons to get a tape. 1) Phone calls are too expensive (E.g. Mayalsia
or Indonesia) or 2) Site security does not allow modems.

In the case of the now legendary "UUNET sending compiled usenet traffic to the
FBI":
    1) We gave them a news feed just like any other customer.
    2) This was the Violent Crime group at Quantico. They're the
       behavioral science folks who track the serial killers
       around the USA. (If you saw "Silence of the Lambs", that
       was the VICAP group at Quantico). These guys are sharp,
       fully professional and completely ethical. One of them
       actively participates with the CERT group.
    3) They got Usenet feeds for the same reason everybody else does.
       -- Once you throw away the 98% crap, you're usually left with
       some really useful source programs and technical information.
       (The FBI employs UNIX wizards too!)
    4) We stopped sending the tapes years ago, when they became concerned
       about possibly picking up a virus from one of the
       programs on the tapes.
    5) They gave me a nifty official FBI coffee mug which is now sitting
       on my desk.

So yes, UUNET has sold USENET tapes to the FBI. Yes, we were paid for this
nefarious service (one coffee mug). Yes, the conspiracy freaks have had a field
day ever since.

The time to start worrying is when the FBI starts getting news and
pretends to be "Quantico Computing Systems" or something. Not when they
do it under their own name.
                                            ---rick

p.s. how come no one noticed the uucp site "stu", which is at the FBI
headquarters building in Washington, DC. (Soon to be West Virginia due to the
most outrageous example of porkbarreling by Sen. Byrd I've seen in years)

p.p.s I know that NSA and CIA employees read Usenet and have for (But I don't
*think* we're sending it to them...)


The Activated Active Badge Project

<Anonymous>
Fri, 7 Jun 91 11:45:28 xxx
Place: Pod 26 Commons
Time: 10:30am, Friday, June 7
Title:    The Activated Active Badge Project
Speaker:  Nicolas Graube    Cambridge EuroPARC

Olivetti's Active Badge are small devices capable of emitting at regular
intervals an infra-red signal which is in turn received by captors placed in
every offices, corridors and public places at EuroPARC. Introducing these
badges is not an easy task as they are immediately perceived as tracking and
logging devices and thus subject to possible misused. I will first reviewed the
BirdDog experiment conducted at EuroPARC whose goal was to introduce active
badges and study users reactions.  Then by following lessons learnt from this
experiment I will introduced a distributed architecture for badges and a more
general usage of these devices. Within the Activated Active Badge project,
badges are no longer considered as tracking devices but are viewed as
contextual multi-functional remote controllers.  The main goal of the project
is to give control to the user both in the specification of its badge semantics
and in the becoming of data generated by its badge. I will introduce a simple
rule based language enabling this specification.  However because the
description of the badge semantics using this language is very much a
programming exercise, I designed a graphical interface enabling the iconic
description of badge activity.  I will conclude by listing possible future
extensions and showing a video of interfaces designed for controlling Active
Badges.

Please report problems with the web pages to the maintainer

Top