Text File

Subject: RISKS DIGEST 18.41

RISKS-LIST: Risks-Forum Digest Thursday 5 September 1996 Volume 18 : Issue 41

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

***** See last item for further information, disclaimers, caveats, etc. *****

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

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

Date: Thu, 5 Sep 1996 18:37:34 -0400 (EDT) From: Edupage Editors <educom@elanor.oit.unc.edu> Subject: China screens out Internet "Spiritual Pollution" (Edupage, 5 Sep 1996)

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)

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

Date: Thu, 5 Sep 1996 8:40:38 PDT From: "Peter G. Neumann" <neumann@chiron.csl.sri.com> Subject: AOL curbs incoming spams

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.

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

Date: Tue, 3 Sep 1996 16:18:02 -0400 (EDT) From: "Joe J. Birsa E-375B 8-284-5192" <birsaj@h01.pgh.wec.com> Subject: AOL denial of service

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

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

Date: Tue, 3 Sep 1996 20:54:42 -0700 From: jeaston@johannsen.com (Jim Easton) Subject: Warning on the use of GPS

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

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

Date: Wed, 04 Sep 1996 12:15:07 -0700 From: "Ralph Barone" <Ralph.Barone@BCHydro.bc.ca> Subject: More re: "More power to you" (RISKS-18.32,40)

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

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

Date: Wed, 04 Sep 1996 13:09:11 +0200 From: kaiser@acm.org Subject: The unstoppable computer: PLURIBUS

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

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

Date: Wed, 4 Sep 1996 07:15:08 -0400 (EDT) From: Edupage Editors <educom@elanor.oit.unc.edu> Subject: Computers asked to identify suspicious baggage (Edupage, 3 Sep 1996)

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)

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

Date: Thu, 5 Sep 1996 03:44:14 -0600 (MDT) From: Bear Giles <bear@indra.com> Subject: Government database correlations

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

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

Date: Thu, 5 Sep 1996 14:07:35 +0200 From: Kirk McElhearn <kirk@lenet.fr> Subject: Hidden file info that you do not know about

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]

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

Date: Thu, 5 Sep 1996 03:44:14 -0600 (MDT) From: Bear Giles <bear@indra.com> Subject: Windows 95 passwords

(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

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

Date: Thu, 5 Sep 1996 03:44:14 -0600 (MDT) From: Bear Giles <bear@indra.com> Subject: Re: Quadro tracker (RISKS-18.22)

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)

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

Date: Fri, 6 Sep 1996 01:44:07 +0900 (JST) From: Chiaki Ishikawa <ishikawa@personal-media.co.jp> Subject: Accidental shooting down of F15 plane revisited (RISKS-18.18)

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

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

Date: Thu, 5 Sep 1996 13:08:52 -0400 From: Greg Lindahl <Greg-Lindahl@deshaw.com> Subject: Re: Denial of service ... Netcom listservers (Dave, RISKS-18.39)

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.

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

Date: Thu, 5 Sep 1996 00:14:33 PST From: james1_12@juno.com (Roger F Connolly) Subject: Re: Back-country technology (Duane, RISKS-18.40)

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.

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

Date: Wed, 4 Sep 1996 16:50:23 -0400 From: Steve Holzworth <sch@unx.sas.com> Subject: Re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

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

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

Date: Wed, 4 Sep 96 23:52:40 -0500 From: "gene m. stover" <gangrene!gene@netcom.com> Subject: Re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

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)

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

Date: Wed, 04 Sep 1996 15:02:00 -0700 From: tony.lima@toadhall.com (Tony Lima) Subject: re: FedEx monitoring of cellular...locations (Glassman, RISKS-18.40)

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)

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

Date: Tue, 3 Sep 1996 12:37:14 -0700 (PDT) From: Bruce R Koball <bkoball> Subject: 7th Computers, Freedom, and Privacy

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

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

Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS

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

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