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 39

Friday 30 August 1996

Contents

o Qualcomm Satellite Tracking System creates regulatory risk
Steve Grabhorn
o 911 and voicemail
Carl Jester
o Caching in web proxy gateways and content negotiation
Klaus Johannes Rusch
o Java passwd changer?
Ken Bass
o Risks of lowered expectations of stability
Daniel P. B. Smith
o When the muzak goes quiet: risks of exception strategies
Nick Brown
o Tunnel vision of Computer Society CD-ROM
Geoff Kuenning
o US Army troubled by viruses in Bosnia
George Smith
o Re: Denial of service ... Netcom listservers
Methvin Dave
Brent Chapman
o Update on GPS Explosion
Bob Potter via David Kennedy
o Karpov Wins Online Chess Match
Edupage
o DIMACS Workshop on Network Threats
Wanglai Li
o Info on RISKS (comp.risks)

Qualcomm Satellite Tracking System creates regulatory risk

Steve Grabhorn <steveo@nosc.mil>
Wed, 28 Aug 1996 23:57:24 -0700
  [Here is a case that has considerable RISKS interest because of the
  potential availability of historical data to regulators.  PGN]

Qualcomm Inc.'s popular Omnitronics [Omnitracs?] electronic truck-tracking
system is causing tension between regulators and truck lines.  The system
uses satellites and receivers to give trucking companies two-way messaging
with its drivers, as well as accurate data on the location of trucks.  The
Federal Highway Administration is battling Youngblood Truck Lines of North
Carolina over what data Youngblood must provide the regulators.  In
response, Truckers United for Safety has filed a lawsuit contending that
regulators are trying to force Youngblood to retain electronic data from its
system for use in audits (with even accidental discrepancies between logged
hours and actual hours potentially resulting in fines).  Youngblood is
considering dropping its very productive use of the system, to avoid the
ensuing risks.  This is at least the second time federal regulators have
demanded electronic data.  Although current regulations do not require it,
proposed new regulations do.  [Source: Regulators seeking Qualcomm truck
data, By Elizabeth Douglass, Staff Writer, *The San Diego Union-Tribune*, 25
July 1996.  PGN abstracting.]


911 and voicemail

carl jester <cjester@interaccess.com>
Wed, 28 Aug 1996 22:38:33 -0500
Last Friday evening, after most people had gone home, the local police
arrived at my place of employment in response to a 911 call. There was no
message, and the caller hung up immediately. On Monday this happened again,
once in the morning and once in the afternoon. The police simply called to
check that it was a false alarm. On Tuesday the calls picked up, at one
point occurring about 5 minutes apart. By this point the police were
becoming upset (I certainly don't blame them).

Due to the nature and timing of the calls, it seemed most likely that there
was a problem with a modem. The most obvious choice was a new Win 95
notebook used by a field tech. Win95 keeps track of things like dailing 9 or
1 for you. This combined with a tech entering 9 or 1 as well might cause
this (more likely 9191 or 991, although 911 is possible).  Unfortunately for
that theory, the notebook was configured correctly.

The problem turned out to be a recently (Friday afternoon) deactivated voice
mail box. Friday was the last day for one of our sales staff (he is leaving
the area). He had set up his voice mail to page him whenever he received a
new message. When his box was deactivated, his pager number was deleted. The
code he chose to identify voice mail on his page remained. The code was, I'm
sure you've guessed by now, 911.  Whenever he received a new message the now
blank number, followed by the message (911) was sent to the switch.

Risks? First, 911 no longer sent anybody to check on the problem. If we'd
had a real emergency, response time would have been slowed. Second, a
"denial of service" as 911 operators were busy with us when there might have
been a real emergency elsewhere.

Carl Jester  cjester@interaccess.com  http://homepage.interaccess.com/~cjester


Caching in web proxy gateways and content negotiation

Klaus Johannes Rusch <KlausRusch@atmedia.net>
Sat, 24 Aug 1996 12:46:52 CET
As the architectured method for language negotiation between web browsers
and web servers is not supported by all products, and often fails as users
tend not to customize their browsers properly, attempts have been made to
select the preferred language (and sometimes content) based on host names.
Similarily, different versions of a page may be sent depending on the
browser's capabilities, the line speed and the like.

Country guessing seems to get much harder with emerging caching strategies.
The two requests below originated at the same client in the .at country
domain.

The first one got propagated from proxy.tuwien.ac.at to
ebone-proxy.univie.ac.at, and finally to salvator.ecrc.net (with possibly
some additional proxy servers in between). In the second has,
ebone-proxy.univie.ac.at actually fetched the document.

  salvator.ecrc.net        - - [22/Aug/1996:14:34:06 -0400]
  ebone-proxy.univie.ac.at - - [22/Aug/1996:14:37:03 -0400]

Now what's the problem with this? At the server there is no evidence where
the request actually originated. The assumption that proxy servers tend to
be in the same geography, consequently in the same top-level domain, does
not hold any more.

In this case, with a .net domain, most servers will probably present the
English version of a document, which may not be the intent of the author,
but still acceptable for many users.

With proxy servers being located in different country domains, however,
there is a risk of presenting a language version which is very likely not to
be understood at all.

Likewise presenting different versions of a document to meet legal
requirements such as adding extra disclaimers, or to direct users to
country-specific information, or optimizing for specific browsers, may fail
for the very same reasons: The cached version of a dynamically created home
page, optimized for use with Netscape and excessively using tables and
graphics, was sent to a text-based Lynx client.

Klaus Johannes Rusch  e8726057@student.tuwien.ac.at, KlausRusch@atmedia.net
http://www.atmedia.net/KlausRusch/


Java passwd changer?

Ken Bass <kbass@fred.net>
Wed, 28 Aug 1996 22:48:30 GMT
  Excerpts from InfoWorld:

  "Courion Corp. has announced Password Courier ... "
  "Password Courier integrates with existing help desk systems and allows
users to reset their own passwords to networks. "
  "Courion estimates that 10-20% of internal help desk calls are from users
who have forgotten their passwords or have been denied because of invalid
password attempts."
  "Users can access Password Courier from a web browser in a corporate
intranet and authenticate themselves with personal identification
information.

It appears the system is for intranet applications, but I wonder how easy it
would be for someone to change my password for me? If this become an
automated process, not requiring the human verification and interaction, I'd
be concerned of the risks.


Risks of lowered expectations of stability

"Daniel P. B. Smith" <dpbsmith@world.std.com>
Thu, 29 Aug 1996 09:40:44 -0400 (EDT)
>From an actual review of a software package, "Personal Engineering," Aug
1996, p. 51: "In general, I really enjoyed working with this package and am
impressed with its stability.  During the entire review process I only got
it to crash twice, and neither situation was repeatable."  Can you imagine
Consumer Reports saying "We really liked the Frammis sport utility vehicle
and were impressed with its stability.  During the entire review process we
got it to roll over only twice, and neither situation was repeatable."?  Or,
"We really liked the [xxx airplane].  During the entire review process we
got it to crash only twice, and neither situation was repeatable."?


When the muzak goes quiet: risks of exception strategies

+33)88412674 <"Nick BROWN" <Nick.BROWN@DCT.coe.fr> (Tel>
28 Aug 1996 15:39:33 +0000
A few months ago, my wife was shopping in the supermarket when large lines
started to form at the checkout counters.  It turned out that (of course)
the whole payment system was down.

In this French store, the procedure to be followed in this case is very
simple: you wait.  I suppose the reasoning goes that even if all the
articles had price stickers, and all the checkout people had calculators
and/or very good mental arithmetic skills, there'd still be no point in
adding everything up by hand since the majority of people would have nothing
to pay with apart from their debit cards.

Anyway, after about half an hour, the lines got moving again, and my wife
made what turned out to be the right call: rather than dump her trolley and
hope that store employees would put all the frozen stuff back in the
freezers before bacteria decided to wake up and multiply for the next
customer, she made it through the line and was able to pick the children up
from school only a couple of minutes late.

I assumed this was pretty much all a store could do in this kind of case,
until I was in a Safeway supermarket in Britain last month [I think Safeway
UK is completely independent of Safeway US - NB].  While waiting in line at
the checkout, I was idly reading one of those stand-up signs that says
something like "to serve you better, this counter is closed", which was
waiting to be deployed on some unsuspecting victim.  When I turned it over,
however, I found another message, indicating that this supermarket chain, at
least, is prepared for when technological Armageddon strikes.  Here
(approximately) is what it said:

  "Owing to a technical problem, we are unable to process purchased items
  electronically.  Therefore, your bill will be calculated by multiplying
  the number of items in your basket by an average item price.  Thank you
  for your understanding."

Now, I presume this must be legal, because I said jokingly to the clerk "I
bet you hope that never happens" and he said "It happened when I was on duty
a few months ago".  Apparently the average item price (I wonder if this is
the average price of each stocked item, or a weighted average of what people
purchase) is around 94 pence, say US$ 1.42.  When the big moment comes, you
get the choice: pay the average price, or drop everything and leave the
store.

So, next time you're in Britain and the lights go low in the supermarket,
the message is clear.  Empty your trolley of canned vegetables and head for
the electrical goods and alcoholic beverages section.

The RISKS are numerous: huge financial losses for the store as savvy
comp.risks subscribers empty the shelves of foie gras and champagne;
confrontations between customers and clerks over the bill; and the store
(inadvertently) ripping you off if you just _have_ to buy a pint of milk and
a small loaf of bread, right now.


Tunnel vision of Computer Society CD-ROM

Geoff Kuenning <geoff@ficus.cs.ucla.edu>
Wed, 28 Aug 1996 12:12:24 -0700
I just posted the following to comp.org.ieee, and consider it appropriate
for RISKS as well:

Since I subscribe to about 7 IEEE Computer Society publications, which take
up significant shelf space, I was excited to learn of the new CD-ROM with
all of 1995's issues on it.  To learn more, I visited the Computer Society's
Web site (www.computer.org).

The first disappointment was the difficulty of even finding the proper
sub-page (their search engine won't let you look for punctuation or "words"
of 2 letters, so I was reduced to looking for "ROM" and hoping I wouldn't
get lots of hits about ICs).  But this was nothing compared to the discovery
that the $90 CD-ROM would be a waste of my money.

Why is this true?  The CD-ROM stores articles in SGML format, together with
a database to help you search it.  SGML viewers are provided for the Mac,
Windows 3.1, and "Unix".  Note that SGML is a superset of HTML, so that
common Web browsers won't display the files correctly.  Worse, the "Unix"
variants supported by the viewers and the database engine are SunOS,
Solaris, and SGI IRIX -- *only*.  Users of DEC Alphas, Linux, Nexts, most
popular x86 Unixes, etc., are out of luck.  So are Windows NT users, who
have already raised complaints about incompatibility.

But if you think the audience is limited now, consider the potential
lifetime of the CD-ROM.  The UCLA library keeps 10-30 years of IEEE
publications on the "active" shelves, and a complete history in secondary
storage.  My own collection is smaller but still dates back quite a few
years.  What are the chances that, 30 years from now, we will be able to run
this software?  The data will be there, and there's a good chance that
there'll be hardware capable of reading the now-obsolete CD-ROMs.  But I
doubt that Windows 3.1 will be around.

The IEEE Computer Society has stumbled twice here.  First, as a society of
computer scientists, it should not be disenfranchising its members by
publishing data that can only be viewed with proprietary software.  Second,
the choice of formats and software has been excessively focused on the
technology of 1995, with little apparent planning for the libraries of the
21st century.

I recognize that the IEEE cannot afford to support every oddball operating
system out there, let alone predict the future.  It is for precisely this
reason that they should have made the CD-ROM available with complete
documentation and source code included, so that all potential current and
future customers would have an equal chance to make use of the information
therein.

Geoff Kuenning  g.kuenning@ieee.org geoff@ITcorp.com
http://fmg-www.cs.ucla.edu/geoff/


US Army troubled by viruses in Bosnia

George Smith <76711.2631@CompuServe.COM>
Wed, 28 Aug 1996 23:03:52 +0000 (GMT)
  PGN-excerpted from VIRUS-L Digest  Friday, 30 Aug 1996 Volume 9 : Issue 152
  Date:   Fri, 30 Aug 1996 23:09:31 +1200 (NZT)
  From: virus-l@cantva.canterbury.ac.nz
  Subject: VIRUS-L Digest V9 #152]
  Administrative mail to n.fitzgerald@csc.canterbury.ac.nz.
  Posting guidelines ftp://CS.UCR.EDU ; FAQ at ftp://cs.ucr.edu/pub/virus-l

Writing in an article entitled "US Army Seeks Computer Antivirus Plan" in
the 26 Aug 1996 issue of *Defense News* magazine, reporter Pat Cooper
reveals the US Army suffered from serious computer virus infections while
deployed in Bosnia.

Infections by Monkey, AntiEXE and Prank Macro caused computer software
malfunctions and related problems which "forced Army personnel to waste
hundreds of hours finding the viruses and cleaning them from the systems..."
Apparently, imperfect Monkey virus removals also resulted in non-critical
data being lost from infected hard disks.

The widespread dispersal of the viruses on Army computers in Bosnia have
catalyzed a review of information systems procedures and could have
implications for all future force deployments, servicewide, according to
Cooper and *Defense News*.

Army Captain Steve Warnock told Cooper that while virus computer trouble
was widespread, it affected only "nonsensitive data and did not adversely
affect the Bosnian mission."

Army officials pressed for solid recommendations that all computers be
checked for computer viruses prior to future deployments.  One suggestion
aired involved the maintenance of an on-line site from which Army personnel
could download current anti-virus software while in the field.

Pat Cooper commented to Crypt Newsletter that the US Army had used
IBM Anti-virus and McAfee Associates software while in Bosnia.
Crypt Newsletter http://www.soci.niu.edu/~crypt

   [Tails from The Crypt.  PGN]


Re: Denial of service ... Netcom listservers (Markowitz, RISKS-18.38)

Methvin Dave <dmethvin@cmp.com>
Fri, 30 Aug 1996 11:04:48 -0400
Let me provide a victim's perspective on Netcom's mail list troubles. I was
one of about two dozen people who were falsely subscribed to over 1000
mailing lists in the early hours of 10 Aug 1996 by someone calling
himself "johnny xchaotic". On 12 Aug, the mail bomber posted a manifesto
in news.admin.net-abuse; you can find a copy of it at
http://www.winmag.com/people/dmethvin/mailbomb.htm.

The good news as far as RISKS goes was that there were hundreds of mailing
lists that did the right thing and rejected the subscription request. Some
mail list software detected the inconsistency between the From address and
the rest of the header. Others realized that the sheer number of
simultaneous subscriptions reeked of spam. Others sent a confirmation
request that had to be returned to start the subscription; I deleted them
and the subscription never got started. Ahh, the beauty of well-behaved
software.

Netcom's mailing list software (and many others as well) fell into the other
category. It was suckered by the forged From in the header, wasn't at all
troubled that the attacker was asking to be signed up to every list at
Netcom, and didn't send any confirmation request before adding me to the
list.

By the time I logged on later that Saturday (about 10 hours after the attack
started), I had over 1600 mail messages. Since I was going on a long
business trip that week, followed by a vacation the next week, I knew I
wouldn't have time to deal with the problem immediately. I decided to have
my incoming Internet mail turned off at our corporate gateway, so that
messages to dmethvin@cmp.com would be bounced back to the sender. In
attempts to contact them, I found out that many of the other victims are
also bouncing mail, some because their mailboxes are full.

In the case of Netcom's mailing list, I suspect that since our bounced
messages went back to their mailing list address, the software just turned
them back around and sent them to the mailing list distribution again,
including all the people who couldn't accept mail. And guess what?  The
messages bounced again and again and again. There was nothing malicious that
I or any of the other victims needed to do to cause this loop, but if it
gets Netcom to straighten out their mailing list software then it's a good
thing.

Dave Methvin, Executive Editor, Windows Magazine  dmethvin@cmp.com

   [I guess that Dave can never have a WinDoze.  PGN]


Re: Denial of service ... Netcom listservers (Markowitz, RISKS-18.38)

Brent Chapman <Brent@GreatCircle.COM>
Mon, 26 Aug 1996 20:48:32 -0600
I don't know anything about this incident or about Netcom's installation of
Majordomo (the mailing list management software in question), but speaking
as the original author of the software, let me quote the original design
paper ("Majordomo: How I Manage 17 Mailing Lists Without Answering
'-request' Mail", USENIX LISA 6 conference, 1992):

    ... the goal is not absolute security, but to avoid people
    making a nuisance of themselves by abusing the Majordomo server.

By today's standards, Majordomo's "security" measures are incredibly weak;
they weren't particularly strong even 5 years ago, when the software was
written. Most lists are configured so that users can subscribe or
unsubscribe themselves, which is determined simply by checking that the
"From:" line in the header matches the address they're trying to
subscribe/unsubscribe, and thus trivially subject to forgery. Furthermore,
those operations that are "protected" are accessed through reusable
passwords sent in clear-text through e-mail, and thus trivially subject to
interception and reuse.

The next release of Majordomo (which will be version 1.94) will include a
simple challenge/response "confirm" mode for lists, where a supposed
subscriber will be sent pseudo-random confirmation string that they must
turn around and send back to the server before their subscription is
finalized.  This should significantly cut down on the spam subscriptions.
Version 1.94 is in alpha test now, and due for release sometime in the next
few months; send e-mail to majordomo-announce-request@greatcircle.com if
you'd like to be added to the list for notification when it's released, or
to majordomo-workers-request@greatcircle.com if you're interested in helping
with the development and alpha/beta test)

Clearly, I should have worked harder to keep folks from making a nuisance
of themselves with the original version of Majordomo.  Some days, I think
that releasing the damn thing was the biggest mistake I ever made...  :-)
And I now have a _lot_ of sympathy for folks like Eric Allman (author of
Sendmail), whose creations have taken on a life of their own on the net...

Brent Chapman         | Great Circle Associates    | 1057 West Dana Street
Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041

  [RISKS is greatly indebted to Brent and majordomo.  They have greatly
  simplified my life, and will do even more in 1.94.  The challenge-response
  will also get rid of the jerks whose FROM: addresses are flagrantly
  unanswerable; on 28 Aug alone, I had to manually remove four would-be new
  subscribers whose given addresses bounced on the acknowledgement, and I
  had one more just before putting this issue out!  PGN]


Update on GPS Explosion

David Kennedy <76702.3557@CompuServe.COM>
29 Aug 96 09:40:12 EDT
C4I-Pro-Digest        Tuesday, August 27 1996        Volume 02 : Number 458

Date: Mon, 26 Aug 96 09:54:00 +6
From: Potter B MSgt ACC/SCXX <potterb@ns.langley.af.mil>
Subject: c4i-pro Update to PLGR Battery Venting Event

Potter B MSgt ACC/SCXX <potterb@ns.langley.af.mil>

Here's an update on the exploding Precision Lightweight GPS Receiver:

     Regards,
       //Bp//       (http://www.geocities.com/Heartland/7167/)
     MSgt Bob Potter     (potterb@hqaccsc.langley.af.mil)
     HQ ACC/SCXX    (DSN 574-5736)
 - - - - - - - - - - - -
Issues:

(1) AA battery tray safety of use
(2) Is PLGR battery venting event systemic or anomalous? (i.e. design or
manufacturing related)
(3) Is there anything that the operators can do to minimize chances of
reoccurrence?

Discussion:

This issue for us is no longer a singular matter of finding out what
happened to cause the violent venting at Fort Irwin on 29/30 July 96. We
hope to be able to determine what the exact cause of that violent venting
was, however, there could be a number of contributing factors and we may
never know exactly what caused that violent venting. The bigger issue is
what are we learning from the on-going testing as we try to determine what
could have caused the violent venting at Fort Irwin, and given this
learning, what can we tell users of the PLGR that will prevent a
reoccurrence of this type of incident in the future.

[DMK: Discussion of batteries, diodes and case specification deleted.
Summary: The investigators cannot replicate the explosion through single
failures or combinations.]

Recommendation:

Until further notice, if operating PLGRs with external power, remove prime
power battery. This includes BA5800 lithiums and AA lithium batteries when
used with AA battery holder. The use of AA alkaline batteries when used with
the AA battery holder is safe, even if holder deforms. In other words when
operating on external power the prime power battery compartment should not
contain any lithium batteries!!!

  Dave Kennedy CISSP Lead InfoSec Analyst InfoSec Recon NCSA

     [Die,lithium batteries?  (See RISKS-11.95.)  PGN]


Karpov Wins Online Chess Match (Edupage, 27 August 1996)

Edupage Editors <educom@elanor.oit.unc.edu>
Tue, 27 Aug 1996 19:51:39 -0400 (EDT)
In an open chess game on the Internet, Russian grandmaster Anatoly Karpov
defeated several hundred opponents in a game that lasted 65 moves and four
and a half hours.  For each move, contestants had seven minutes [down from
the originally advertised 10 minutes, at Karpov's request -- I guess he did
not want to get too bored.  PGN] to indicate their response, and a computer
calculated the most frequently suggested response.  (*The New York Times*,
27 Aug 1996, B9)  [See <http://www.tele.fi/karpov/gameworl.htm>.]

  [This item is noted primarily for archival purposes, as a follow-up
  to the risks suggested in RISKS-18.37.  The result was clearly not
  a surprise.  Only about 300 hundred opponents?  Suppose the group was
  composed of only a few grand masters?  What would that do to the odds?
  Better yet, one grand master with others kibitzing by e-mail.  If a
  grand master can play simultaneous matches, it should be no difficulty
  winnowing the e-mail suggestions in real-time.

  I suppose at the next Computer Chess Olympics we will see on-line groups
  of Russian chess players pitted against their U.S. counterparts using
  this software, *en mass-ant*.  PGN]


DIMACS Workshop on Network Threats

Wanglai Li <wli@dimacs.rutgers.edu>
Thu, 29 Aug 1996 14:40:56 -0400
DIMACS Workshop on Network Threats (abridged announcement)
Sponsored by the DIMACS as part of the 1996-97 Special Year on Networks
4-6 December 1996
DIMACS Center, CoRE Building, Rutgers University

Organizers:
   Rebecca Wright, AT&T Research, rwright@research.att.com
   Peter Neumann, SRI International, neumann@csl.sri.com
   Steve Bellovin, AT&T Research, smb@research.att.com

As the use of computer networks, and in particular the Internet, has
increased, so has the potential threat to security. In the last several
years, we have seen numerous security-related attacks on Netscape, Java, and
the Internet protocols. New protocols and systems for electronic commerce,
secure financial transactions, and other applications are being introduced,
and are being deployed quickly, and on a large scale. This workshop aims to
bring together theorists and practitioners working in areas related to
network security in an informal setting to foster discussion regarding the
nature of the threat and what we, as researchers, can do to help manage it.

This workshop will cover topics including, but not limited to:

 o attacks on network security
 o prevention/detection of attacks
 o threat models
 o threats to individual privacy
 o risk management
 o formal methods of security analysis
 o political, legal, and social aspects of network security

INVITED TALKS: Confirmed invited speakers (subject to change) include:

 o Bill Cheswick (Bell Labs)
 o Ed Felten (Princeton University)
 o Peter Neumann (SRI International)

Abstract submissions *by 16 Sep 1996* should describe original, unpublished
work, and should be 1-2 pages in length. Abstracts should clearly state the
problem being addressed, the nature of the solution, and the main
contribution of the work. Abstracts will be selected on the basis of
originality, significance, technical content, and applicability. Please
include a cover letter indicating the name, address, and e-mail address of
the contact author.  Electronic submissions are preferred. To submit
electronically, send postscript or plain ASCII text to:
rwright@research.att.com.

To submit hardcopy, send three (3) copies to:

   Rebecca Wright
   Network Threats Workshop
   AT&T Research
   Room 2T-314
   600 Mountain Avenue
   Murray Hill, NJ 07974

More Information: For more information about the Special Year on Networks,
see the DIMACS web pages at http://dimacs.rutgers.edu and for information
regarding author schedules, registration, travel and local arrangements for
this workshop see http://dimacs.rutgers.edu/Workshops/Threats.  E-mail to
dimacs-www@dimacs.rutgers.edu

Please report problems with the web pages to the maintainer

Top