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 18 Issue 41

Thursday 5 September 1996

Contents

o China screens out Internet "Spiritual Pollution"
Edupage
o AOL curbs incoming spams
PGN
o AOL denial of service
Joe J. Birsa
o Warning on the use of GPS
Jim Easton
o More re: "More power to you"
Ralph Barone
o The unstoppable computer: PLURIBUS
Pete Kaiser
o Computers asked to identify suspicious baggage
Edupage
o Government database correlations
Bear Giles
o Hidden file info that you do not know about
Kirk McElhearn
o Windows 95 passwords
Bear Giles
o Re: Quadro tracker
Bear Giles
o Accidental shooting down of F15 plane revisited
Chiaki Ishikawa
o Re: Denial of service ... Netcom listservers
Greg Lindahl
o Re: Back-country technology
Roger F Connolly
o Re: FedEx monitoring of cellular...locations
Steve Holzworth
Gene M. Stover
Tony Lima
o 7th Computers, Freedom, and Privacy
Bruce R Koball
o Info on RISKS (comp.risks)

China screens out Internet "Spiritual Pollution" (Edupage, 5 Sep 1996)

Edupage Editors <educom@elanor.oit.unc.edu>
Thu, 5 Sep 1996 18:37:34 -0400 (EDT)
The Beijing government has begun blocking as many as 100 Internet sites that
offer material the government deems unsuitable for its citizens -- including
dissident viewpoints from Hong Kong and Taiwan, sites sponsored by U.S.
major media organizations such as CNN and the Washington Post, and sexually
explicit sites such as Playboy and Penthouse.  An official described the
blocked sites as suspected purveyors of "spiritual pollution."  (*Wall
Street Journal*, 5 Sep 1996, B12)


AOL curbs incoming spams

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Thu, 5 Sep 1996 8:40:38 PDT
Junk mail seems to be overwhelming all of us (including RISKS).  America
Online has decided to block completely all incoming e-mail from five
Internet sites, three of which are run by Cyber Promotions, Inc., in
Philadelphia.  Those five sites apparently accounted daily for about 700,000
pieces of unsolicited e-mail to AOL subscribers.  Cyber Promotions earlier
had sued AOL for interfering with its business, and also sought an
injunction against AOL's blockade (although that injunction has not yet been
acted on).  Cyber also accused AOL of hypocrisy, because AOL sends its own
commercial pitches to its subscribers.  (CompuServe and Prodigy have also
taken "comparable" steps.)  [Source: Peter H. Lewis, item from *The New York
Times* in *San Francisco Chronicle*, 5 Sep 1996, D3.]

Stay tuned for further developments in the commercialization of the
Internet.  Perhaps most frustrating is that would-be retaliatory reverse
spammers often discover that the given e-mail FROM: address is bogus, with
the spammer relying on a phone number instead.


AOL denial of service

"Joe J. Birsa E-375B 8-284-5192" <birsaj@h01.pgh.wec.com>
Tue, 3 Sep 1996 16:18:02 -0400 (EDT)
Late last month, my sons complained that AOL wouldn't let them log on.  When
I called AOL, I found out that AOL suspended our service because the
computer at the credit card company was unavailable and sent them a "try
again later" message when they tried to debit my account. (I wonder how hard
they REALLY tried to contact the credit card company.)  Apparently because
their computer couldn't talk to the credit card company's computer, the AOL
computer decided to suspend my account and cut us off.  Two days after this
happened, I got a "snail mail" from AOL saying that I owed them money and my
account was suspended until I contacted them.  The amount involved was
$20.24.

The risks - If I was using my AOL e-mail for business purposes (or other
serious use) I would have been cut off until I figured out that I needed to
call them.  I have no idea if (or how many) e-mail messages were "bounced"
because of this.  Again if this account was used for business, my reputation
could have been seriously damaged because of this policy.  Most companies
that I am familiar with will not take such drastic action immediately if the
normal payment process is delayed or interrupted.

BTW - The AOL representative I spoke to did not know if the AOL computer
would retry until got an answer.

Joe Birsa


Warning on the use of GPS

Jim Easton <jeaston@johannsen.com>
Tue, 3 Sep 1996 20:54:42 -0700
Over the last few weeks I have experienced a series of GPS navigation errors
ranging from minor (triggering RAIM) to as large as 20 miles horizontally
and calculated GPS altitudes of below NEGATIVE 5000' MSL. I have never been
given a NOTAM telling me to expect this performance.

Reading the current issue of AOPA Pilot, I now understand.

* First: Kudos to AOPA for finally telling us what is going on.

The military has been conducting GPS jamming exercises in Southern
California affecting at least the Los Angeles and San Diego areas (that I
have observed) lasting for times up to some 15 minutes (again that I have
observed).

You should note that the vast majority of GPS units flying do NOT have RAIM
and will NOT automatically flag an erroneous GPS position.

I would seriously warn pilots against trusting VFR GPS navigation in
Southern California without cross-checks. Should a RAIM flag go on in an IFR
GPS do NOT assume that because you are receiving lots of healthy satellites
with good signal strength that you can ignore the warning. This is exactly
what you will see when you are receiving jamming.  Look at the calculated
GPS altitude and calculated position error and cross check with any other
available navigation source.

Note that the government has decided to take down LORAN and VORs which will
leave you dead when GPS is jammed. In spite of the absolutely predictable
loss of airplanes and lives that this decision will cause, it is apparently
cast in concrete. I believe that the plan may be to have a multibillion
dollar fix to GPS after all alternative means of navigation have been shut
down and a thousand or so people have been killed by GPS failure.

Jim Easton  4364 Bonita Rd., No. 166  Bonita, CA, 91902-1421
Tel: (619) 548-0138  FAX: (619) 470-8616


More re: "More power to you" (RISKS-18.32,40)

"Ralph Barone" <Ralph.Barone@BCHydro.bc.ca>
Wed, 04 Sep 1996 12:15:07 -0700
The following quote is from the Aug 19/96 issue of "Power Markets Week"
(published by McGraw Hill).  I thought you might find it interesting.

One Pacific Northwest market player stated that the new open-market,
profit-making electricity industry is straining the existing Western
distribution system.  "This distribution system was never designed to
maximize people's profits," he said.  The price differentiation between the
Northwest and Southeast trigger huge shifts in energy, which "can't be
supported by the existing transportation system." he added.

Ralph Barone, Protection & Control Manager/HVDC Control Engineer
BC Hydro  Ralph.Barone@bchydro.bc.ca


The unstoppable computer: PLURIBUS

<kaiser@acm.org>
Wed, 04 Sep 1996 13:09:11 +0200
In my archives I came across this short article that Bernie Cosell wrote in
August 1980.  I'm posting it to RISKS, with his permission, because it
seems worth getting the article into print -- it's still of interest -- and
into all the archives where RISKS will be kept.

 [Here's] a real world anecdote.  It concerns the development of the
 software for the PLURIBUS multi-processor here at BBN.  I think that the
 only details you need know about the PLURIBUS are that it is a symmetric
 multi-processor that uses (in essence) a network to connect together
 various buses; each bus contains only a limited amount of stuff: e.g., at
 must two processors, not all of common memory, only one end of a doubly
 interfaced I/O interface.  Each processor has a small amount of local
 memory, but beyond that runs "through the switch" to execute code out of
 one of the common memories.

 Since the hardware was designed to be extensible and resilient, the
 software was designed to be the same way.  We were out there on the fringes
 figuring out how to build reliable, extensible, fault tolerant systems.

 Without going into the details of how we made it all (mostly) work, let me
 describe some of the more amusing properties of the system.  In particular,
 it was nearly impossible to stop the sucker once you got it going.

 A pretty amusing circumstance crops up when someone would (innocently)
 wander up to the machine and push STOP on the console and mount a paper
 tape to load up some new software with.  The console, however, only halts
 the processors on the bus it is on.  Within a few seconds of halting the
 bus, the other (still running) processors in the system notice that some of
 their brethren have disappeared, and they reload them (lest their local
 memories had gotten clobbered) and then restart them.  So as you stand in
 front of the paper tape reader, you notice that your "stopped" processor is
 happily back in the fold and you've been done in.

 This actually happened (and caused something of a panic) when we shipped
 one to Washington.  As the field engineer began uncrating the thing and
 powering back up and cabling the buses together, the shards of the IMP
 program we had last been debugging woke up and began sniffing about.  By
 the time the whole machine was reassembled the software had long since
 found enough resources to make itself happy, and so had reinstated itself
 and was happily running along.  He, of course, wanted to run some
 diagnostics, but couldn't (and never did) figure out how to get the system
 to go away and let him do his job:

 Since the system is symmetric, both for software and hardware, there is
 really no critical component.  If you unplug some of memory, the system
 will hiccough a moment, locate new copies of the code in the memory that is
 now gone and quietly continue running.  Since the system always (if at all
 possible) maintains two copies of each software module and keeps them in
 separate memory modules, simply messing with memory wont stop the system.
 And on and on with plausible tries that just wouldn't get the thing to
 die...  (eventually, one of the software wizards in Cambridge was located
 and gave him the secret:

    Plant an appropriate illegal instruction in common memory in a
    (carefully chosen) location which each processor would blunder
    across (and so stop) before either reloading any of the other
    stopped processors or noticing that the common memory checksum is
    clobbered and switching in a fresh copy.)

 Even then you have to be careful, because if you happen to restart one of
 the processors before you load up your new code, it will quickly repair the
 damage to common and then seek out and restart its brethren and almost
 before you know it you're back where you started from...  sigh....

The risks are pretty clear, aren't they?

Pete  kaiser@acm.org +33 92.95.62.97, FAX +33 92.95.50.50


Computers asked to identify suspicious baggage (Edupage, 3 Sep 1996)

Edupage Editors <educom@elanor.oit.unc.edu>
Wed, 4 Sep 1996 07:15:08 -0400 (EDT)
Officials working on an aviation commission headed by Vice President Gore
and formed after the TWA Flight 800 crash are recommending that computerized
background checks of passengers should be made to determine which customer
luggage to search.  Names, addresses, phone numbers, travel histories and
billing records of passengers would be examined to look for irregularities
that would suggest the possibility of terrorist activity.  Civil
libertarians are expected to object to the plan as an invasion of privacy.
(*The New York Times*, 1 Sep 1996, p17)


Government database correlations

Bear Giles <bear@indra.com>
Thu, 5 Sep 1996 03:44:14 -0600 (MDT)
According to a sidenote on the minimum-wage bill recently passed, starting
FY 98 (?) the federal government will maintain a list of _all_ court ordered
child support payments and _all_ newly employed individuals, and then
cross-correlate them.  Needless to say, there appears to be no consideration
of the inevitable problems with misidentification, security/privacy, etc.

Undoubtedly, "if you don't have children out of wedlock and aren't divorced
you have nothing to worry about."


Hidden file info that you do not know about

Kirk McElhearn <kirk@lenet.fr>
Thu, 5 Sep 1996 14:07:35 +0200
I work in France as a [bilateral] translator, and I am also a French editor
for an American language learning software company.  One of my roles is
purchasing content, and negotiating rights.

I have recently been negotiating with a French TV station, to purchase some
video.  My contact sent me a draft contract as an e-mail attachment, but I
had trouble opening it.  When I opened it with a text editor, I discovered
my contract, as well as 2 others.

It seems that they use Word.  Now, my Mac is a Microsoft-Free zone, so I am
not sure about how this works, but, if I understand correctly, you can save
a document under Word which includes previous versions.  (The doc I received
was about 40k, and my contract was only 5 pages.)

This means that the person had been saving his contracts like that, and for
a new contract, he just took an old one and made some changes.  Well, the
implications of this are obvious.  I could have found, for example, that the
price the previous client paid was far below what I had agreed to pay.  Or
there could have been other confidential information.

I explained this to my contact, who seemed a bit upset about not knowing
what was in the file he sent me.  I guess that many users of Word, and
probably other WP software, may be in this situation also.  If they were to
read the manual...

Kirk McElhearn  91 rue de la Mesangerie  37540 St Cyr sur Loire  France
kirk@lenet.fr    http://www.nirvanet.fr/kirk/kirk.html

  [I think this problem has appeared previously in RISKS.  PGN]


Windows 95 passwords

Bear Giles <bear@indra.com>
Thu, 5 Sep 1996 03:44:14 -0600 (MDT)
(This may be very old, but I just installed Windows 95.)

Windows 95 allows you to specify one password on the system... and changing
the password on the Win95 screensaver does _not_ require verification with
any system-wide or user-specific passwords.  This is a minor annoyance, but
still an unnecessary one.

Bear Giles  bear@indra.com


Re: Quadro tracker (RISKS-18.22)

Bear Giles <bear@indra.com>
Thu, 5 Sep 1996 03:44:14 -0600 (MDT)
Archival update: the senior officers of the company which manufactured the
"quadro tracker" were indicted on mail fraud charges.  (AP, week or so ago;
it was discussed previously in RISKS-18.22)


Accidental shooting down of F15 plane revisited (RISKS-18.18)

Chiaki Ishikawa <ishikawa@personal-media.co.jp>
Fri, 6 Sep 1996 01:44:07 +0900 (JST)
I reported last year and early this year regarding the accidental shooting
down of an F15 by a wing mate.

What happened: An F15 fighter plane of Japan's air force shot down another
F15 during interception training over the Sea of Japan near the Honsyu
island last November.  Both planes were based in the Komatsu air base. One
of the planes carried the live sidewinder missiles and despite the claimed
safety mechanism, the missile was launched. The pilot of downed F15
parachuted down and was rescued.

Earlier reports I picked up suggested malfunction of safety mechanism such
as static electricity problem of the master firearm system.

However, the investigation turned to a different direction, it seems.  An
article in the Asahi Shimbun on September 4th stated that the Komatsu
military police of the Air force (my English translation of the unit name)
filed formal charge with the local prosecutor's office against the 30 years
old pilot Jyun'ya Hino for disabling (turning off?) the safety mechanism and
then pushing the missile launch button.

The charge mentioned is Kashitsu-Kokuh-Kiken-Zai.  Kashitsu is a Japanese
legal term for mistake, oversight, or an error.  Kokuh here refers to air
traffic.  Kiken means danger. Zai is the legal word for crime.  In a
nutshell, the pilot is, if the prosecutor's office agrees, likely to be
charged and tried with a grave oversight that brought about the serious
accident.

My observation: It looks that the safety mechanism was overridden by human
operator for whatever reason.  This seems to be the conclusion of the air
force investigation.

That military investigators filed charge with the prosecutor's office is a
little puzzling, but I think the Japanese laws would require the handling
outside the military court. I think petit crime such as stealing would be
handled in the military.  The military investigators must have found a
serious neglect on the part of the pilot to justify the release of his name
by filing formal papers to the prosecutor's office: the pilot's name had not
been mentioned in the earlier reports at all (at least not in the newspaper
articles that I saw in Asahi, Yomiuri, Nikkei newspapers).

If the military investigators are right, the accident was more likely to be
the result of human error, and not that of computer-controlled system.

If only the live missile was taken off the airplane before the training
started. As I mentioned earlier, the reason given by the air force for not
doing so was that the airplane was used for routine real-life interception
take-offs and the unloading/loading of live missiles before and after the
training takes time. This is total non-sense since the airplane had to be
refuled anyway after the interception training which also takes time. Also,
the air force officials admitted that carrying live missile was unnecesary
for the type of interception training intended.

(Since I am not a legal expert, nor a military expert, the English
translation of the military terms and legal terms are likely to be loose.)

Ishikawa, Chiaki            ishikawa@personal-media.co.jp
(family name, given name)
    Personal Media Corp.
  Shinagawa, Tokyo, Japan 142


Re: Denial of service ... Netcom listservers (Dave, RISKS-18.39)

Greg Lindahl <Greg-Lindahl@deshaw.com>
Thu, 5 Sep 1996 13:08:52 -0400
The majordomo software used by Netcom for their mailing lists uses the
traditional Internet mechanism for avoiding mail loops. As a victim of many
victim's attempts to bounce unwanted e-mail, I don't think it really matters
that these victims are well-meaning when they:

* automatically reply to Precedence: bulk and Precedence: junk mail
* ignore the Errors-to: header line [ admittedly, I'm not sure if
  this "standard header" is in the RFC's ]
* repeatedly reply to the same From: line [ cf. vacation(1) ]

Writing correct mail handling programs is complex. Most PC vendors made and
still make many mistakes when writing gateway programs. Good intentions are
not a defense for sending thousands of unwanted pieces of mail.

Because of this problem, I do not have Reply-to: headers pointing back to
any of my mailing lists -- this generally means only the author of the
message sees the bounces. Then I get to deal with complaints like "why
doesn't this list work like my other mailing lists?"

Sigh.  Greg Lindahl  D. E. Shaw & Co., L. P.


Re: Back-country technology (Duane, RISKS-18.40)

Roger F Connolly <james1_12@juno.com>
Thu, 5 Sep 1996 00:14:33 PST
This makes no sense to me.  If they had known how to use the GPS receiver in
the first place, they would have stored critical waypoints in it and
wouldn't necessarily need a map to get back.  Most modern handheld receivers
will even point you in the right direction and show you a tracing of the
path you've taken.  However, if you stored no waypoints, and don't even know
the approximate coordinates of where you want to be, a GPS receiver is about
as useful as something pretty useless.


Re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

Steve Holzworth <sch@unx.sas.com>
Wed, 4 Sep 1996 16:50:23 -0400
Cellular carriers are now required to supply 911 emergency service centers
with caller locations to within some small distance (a block?). This is so
EMS can locate people who call in via cellular. This can be thought of
as an extension of ANI, used by such services already to determine your
address immediately upon your calling into a 911 center.

Whenever your phone is on, it is communicating with the nearest cell(s) and
flagging cell boundary crossings. This is necessary so that the cellular
service knows which cell to use to contact your phone for in-bound calls. In
addition, individual cells can ramp your transmitter signal strength up or
down to accommodate varying cell sizes.

>2. Is it possible for FedEx to capture information that Cellular One doesn't
>know it's passing?

No. However, like ANI and CallerID, this is a capability that the cellular
companies have apparently found a way to market, at least to customers
that it might help, like FedEx. I imagine that the number you called was
a "800" number or free cellular equivalent (*foo). Thus, FedEx would argue
that they are paying for the call and deserve the additional information...


Re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

"gene m. stover" <gangrene!gene@netcom.com>
Wed, 4 Sep 96 23:52:40 -0500
I have been a software engineer at various companies in the cellular
industry for about two years. Since I am not an RF engineer, what I say
about cell isn't authoritatively final, but short of that, it is reliable.

There has been discussion of geographic mobile-location systems for the
North American cellular system that do no rely on special features like
adding GPS to the mobile. Such systems are:

1. Possible,

2. Of extremely limited accuracy (not nearly to the resolution of a street
intersection; more like a 20- to 45-degree arc at least a mile in radius),

3. Not implemented anywhere.

Even Cellular One didn't know your location when you made the call, so FedEx
must have determined it some other way.

>  2. Is it possible for FedEx to capture information that
>  Cellular One doesn't know it's passing?

No. (Well, since we're talking about a complex software system, a more
accurate answer might be ``No more likely than the possibility that a C
compiler would insert a backdoor when it compiled the Unix login program.''
;-)

gene m. stover (gene@CyberTiggyr.com)


re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

Tony Lima <tony.lima@toadhall.com>
Wed, 04 Sep 1996 15:02:00 -0700
RO> Two days later, a FedEx operator confirmed that they are getting "new
RO> systems" at some locations that are able to record the locations from which
RO> cellular calls are placed.

What amazes me about this tale is that it's been widely reported in San
Francisco area newspapers that the local 911 system can't tell where a cell
phone call originates.  It strikes me as perverse that FedEx can do
something our local emergency system can't!  Talk about your RISKS! - Tony
Lima

Internet: tony.lima@toadhall.com (Tony Lima)


7th Computers, Freedom, and Privacy

Bruce R Koball <bkoball>
Tue, 3 Sep 1996 12:37:14 -0700 (PDT)
   THE SEVENTH CONFERENCE ON COMPUTERS, FREEDOM, AND PRIVACY
                Call for Participation
        San Francisco Airport Hyatt Regency Hotel
                Burlingame, California
                   11-14 March 1997

CFP97: Commerce & Community will be sponsored by the Association for
Computing Machinery SIGCOM and SIGSAC. The host institutions will be
Stanford University and the University of California at Berkeley.
Co-sponsors and cooperating organizations include the ACM SIGCAS, the
Electronic Frontier Foundation, the Center for Democracy and Technology, the
Electronic Privacy Information Center, and the WELL.

CFP97: Commerce & Community is the latest in a series of annual conferences
assembling a diverse group of experts and advocates from the domains of
technology, business, government, and academia to explore the evolution of
information and communication technologies and public policy, and its
effects on freedom and privacy in the United States and throughout the
world.

Past CFP sessions have discussed, debated -- and often anticipated -- issues
of great social import.  In this tradition, CFP97: Commerce & Community will
examine the social and policy questions posed by:

* the growth of electronic communities;
* electronic commerce and the commercialization of cyberspace;
* the problems of legal and regulatory control of the Net;
* the interests of privacy and property in the electronic domain;
* high-tech law enforcement and security concerns.

The CFP97 Program Committee invites your suggestions for presentations on
these or other important issues at the nexus of technology, business, public
policy, freedom, and privacy.

Proposals may be for individual talks, panel discussions, debates, moot
courts, moderated, interactive sessions or other formats.  Each proposal
should be accompanied by a one-page statement describing the topic and
format.  Descriptions of multi-person presentations should include a list of
proposed participants and session chair.  Proposals should be sent by e-mail
to cfp97@cfp.org. If necessary, typewritten proposals may be sent to:
CFP'97, 2210 Sixth Street, Berkeley, CA 94710.

Please submit your proposal as soon as possible.  The deadline for
submissions is 1 October 1996.  (Please note that we have extended our
deadline for submissions)

For more information on the Computers, Freedom and Privacy Conferences,
as well as up-to-date announcements on CFP'97, please visit our Web
page at:   http://www.cfp.org

Please report problems with the web pages to the maintainer

Top