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 19 Issue 78

Thursday 4 June 1998

Contents

o Mir mortals' bum steer
PGN
o Senate talks martial law and Y2K; Indian nuke-hackers
Declan McCullagh
o Corporate insurance excludes Y2K
Ulf Lindqvist
o The Year-2000 Muddle Continues
Andy Goldstein
o Texas accent required for voice recognition in UK
Mich Kabay
o Netomania
Edupage
o Nielsen Rate-Hiked
Declan McCullagh
o Risks of online phone books
Jeremy Epstein
o NorWeb denies 999 interference
Michael A. Eccles
o Re: Pager unreliability
Chris Cartledge
o Re: Navy stops teaching celestial navigation
Jeff Uphoff
Geoff Kuenning
Jim Wolper
o Re: Failure modes when the power fails
George C. Kaplan
o Disabling Java and JavaScript isn't totally safe either
Don Byrd
o Who is watching the capacity and performance needs of Java solutions?
Jerry Svigals
o Referer-log security hole
Jorn Barger
o globe.com vs Advertising Age passwords: spam and security problem
David Wittenberg
o Re: CzERT group of hackers ravage Czech & Slovak cyberspace
Steven Slatem
o Info on RISKS (comp.risks)

Mir mortals' bum steer

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Tue, 2 Jun 98 20:18:36 PDT
Over the last weekend of May 1998, a computer critical to the Mir automatic
steering system failed.  The cosmonauts replaced it with a new one, but they
were unable to load the new one with software necessary to run the steering
system, at a time when the shuttle Discovery was about to be launched to
dock with Mir.  Finally, on Monday 1 June, the problem was resolved (just
*how* was not specified in the reports I saw), and the Discovery launch took
place.

  Does a tear appear when Mir won't steer?
  Well, have no fear, the veer's not near.
  The cheer from here I hear is clear.
  It's sheer delight.  You have our ear.

  So, quaff a kvass and hoist a beer,
  Let's hear it for the programmeer
  who caused the glitch to disappear --
  and thus inspired this sonneteer.

PGN


Senate talks martial law and Y2K; Indian nuke-hackers

Declan McCullagh <declan@well.com>
Thu, 4 Jun 1998 14:21:28 -0700 (PDT)
http://cgi.pathfinder.com/netly/afternoon/0%2c1012%2c2038%2c00.html

time.com / The Netly News / Afternoon Line, 4 Jun 1998

The Martial Plan

Think the Year 2000 problem means mere elevator snafus? Try dealing with a
platoon of Marines who show up in your front yard to confiscate your hoarded
lentils. Sen. Robert Bennett (R-Utah) asked the deputy secretary of defense
at a hearing this morning what plans the Pentagon has "in the event of a
Y2K-induced breakdown of community services that might call for martial
law." John Hamre replied carefully, but none too reassuringly, "We've got
fundamental issues to deal with that go beyond just the Year 2000
contingency planning. And I think you're right to bring that up." Another
distressing point that came up at the Senate Armed Services committee
hearing was the fact that the military directs one quarter of U.S. air
traffic. "You may be flying across the country and an air traffic controller
may be a military guy in certain areas as opposed to it being an FAA
person," Hamre said. Although the FAA's head Y2K guru assured us this
afternoon that the agency will have its Y2K fixes complete by October 1998,
the military appears to be in much worse shape. And other countries? "We can
be sure that there will be social unrest in many parts of the world as a
result of Y2K," Bennett said. For the record, though, Bennett did say, "I am
not one of those who says that Y2K will automatically produce martial law,"
and blamed "alarmists, extremists out there on the Internet" for unnecessary
scaremongering. --By Declan McCullagh/Washington

Hackistan

As if the accelerating arms race on the subcontinent weren't disturbing
enough, a group of hackers broke into the local area network of India's
Bhadha Atomic Research Center (BARC) and copied five megabytes' worth of
data, including e-mail between scientists and files from India's nuclear
research program.  [...]

  [According to an article by James Glave in WiReD News, 3 Jun 1998, James
  interviewed the three teenage "Milw0rm" crackers (in New Zealand and
  England) by Internet Relay Chat.  They apparently gained control over 6 of
  the 8 servers in *.barc.ernet, altered the BARC Web site, and deleted
  many files -- in protest against the Indian nuclear testing.  (The BARC is
  worse many bytes?)  They also e-mailed some of their discoveries to James.
  They say they are now going to take a closer look at the Pakistanis.  PGN]


Corporate insurance excludes Y2K

Ulf Lindqvist <ulf@csl.sri.com>
Mon, 1 Jun 1998 14:04:54 -0700 (PDT)
I note that in their general conditions for corporate insurance policies,
one of the large Swedish insurance companies (Trygg-Hansa) have made the
following exclusion effective as of May 1, 1998 (my layman translation):

  "The policy will not cover damage, cost, legal or other liability caused
  directly or indirectly or connected to time-related disturbance in
  computer functionality."

This is hardly surprising, but it is interesting to note that the exclusion
specifically concerns only time-related overflow and would not for example
exclude the Dow Jones 10K problem.

Ulf Lindqvist, Department of Computer Engineering, Chalmers University of Tech.
SE-412 96  Goteborg, SWEDEN, Currently at SRI.   http://www.csl.sri.com/~ulf/


The Year-2000 Muddle Continues

Andy Goldstein - VMS Development <goldstein@star.zko.dec.com>
Sun, 31 May 1998 10:41:48 -0400
Yesterday I was in line at the register of a store I will leave nameless
to avoid undue embarrassment. Ahead of me, a silver-haired gentleman
handed over a check for his purchase. The register clerk stamped the
check (getting the stamp right side up on the second try) and took the
customer's vital statistics. She was puzzled when the computer wouldn't
take his birth date. After a phone call and consultation with a
supervisor, the man's check was approved, with the explanation that his
date of birth had been rejected "because of a recent year 2000 fix".

Figured it out? No further explanation was available, but I'll bet you
dollars to donuts they made the old "sliding window" fix, making all dates
before, say, 50, be in the 21st century. And of course the program was
smart enough to not accept birth dates in the future.

Morale: Having your code inspected and fixed for year-2000 compliance
is no guarantee it's going to work right.


Texas accent required for voice recognition in UK

"Mich Kabay [ICSA]" <Mich_Kabay@compuserve.com>
Wed, 3 Jun 1998 17:05:18 -0400
According to an article in _The Guardian Weekly_ (May 10, 1998; p. 11),
biometric authentication using voice recognition has hit a stumbling block
because of trans-oceanic differences in accent.

> Tagging Test Pines for Texas, by Alan Travis

> A British experiment using an American device to monitor convicted
> criminals to be introduced later this year has hit a snag -- the high-tech
> "voice recognition" system only responds to a Texas drawl.

> The Home Office scheme involves ordering offenders to carry dedicated
> pagers with them to ensure check-ins several times a day.

The author explains that the paroled convicts are supposed to respond to the
request for check-in by phoning a toll-free number and identifying
themselves.  The biometric authentication system then authenticates their
identity.  I guess the system must also use automatic number identification
to track their physical location (although auto-forwarding of calls poses an
unmentioned threat to such a scheme).

The problem occurred when the unnamed brand of voice recognition system
failed to respond reliably to British accents.  Seems the Texas company
"trained" the system using only Texas drawls.

One additional problem: if the manufacturers in Texas assume that all
British people sound the same, they are in for a nasty surprise.  I suspect
that the variations of pronunciation and even of prosody in that tight
little isle exceed the variations found in television-drenched America (not
counting the wonderful flavours added by immigrants' accents).

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education International
Computer Security Association (Carlisle, PA) <http://www.icsa.net>

  [Quick-drawl artists need not apply.
  The AYES of Taxes are a pun us. PGN]


Netomania (Edupage)

Edupage Editors <educom@educom.unc.edu>
Tue, 02 Jun 1998 16:49:05 -0400
Reporting a study of 14 so-called Internet "addicts," psychiatrist Nathan
Shapira of the University of Cincinnati says that, on average, the subjects
of the study each had had five psychiatric disorders.  Shapira thinks that
excessive online use should be considered not as a separate addiction but
as a disorder of impulse control, in the same category as kleptomania or
compulsive shopping.  He suggests the problem be called Internetomania or
Netomania.  (*USA Today*, 1 Jun 1998; Edupage, 2 June 1998)


Nielsen Rate-Hiked

Declan McCullagh <declan@well.com>
Wed, 3 Jun 1998 15:39:48 -0700 (PDT)
"Release of the prime-time television ratings has been delayed due to
computer problems at Nielsen Media Research. We hope to move them by
noon EDT."  (according to an AP item on 3 Jun 1998)

  [Declan later noted that a story slugged BC-Nielsens was out
  by 1:12pm, and the list of primetime shows made it by 3:10pm EDT.
  I suppose that many folks consider the ratings even more moving
  than the content of the listed programs themselves.  PGN]


Risks of online phone books

Jeremy Epstein <jepstein@tis.com>
Tue, 02 Jun 1998 14:45:13 -0400
One of our staff took off early the other day because he received an
emergency phone call that a family member had been shot.  But it was a false
alarm caused by technology.

Seems that "Cousin Patrick" was shot, and "Aunt Penny" decided to tell
everyone.  She did a Web search for everyone with the same unusual last
name.  [I don't know how wide a geographical area she searched over.]  Among
the hits was someone on my staff, who was unrelated, but happens to also
have a Cousin Patrick and an Aunt Penny.  So he got an emergency phone call,
trundled off, etc.

Of course this could have occurred in the "old days" too, but it's much
easier to get those phone numbers now, while in the old days it would have
required a trip to the library and leafing through dozens of phone books (or
lots of calls to directory assistance).  And as a result, people would be
less likely to broadcast a warning to unknown "relatives".

Other than some lost time and some frightened people, no harm was done by
the mistaken identity.

Jeremy Epstein  jepstein@tis.com, TIS Labs at Network Associates,
Northern Virginia Office  +1 (703) 356-2225 Ext 106


NorWeb denies 999 interference (Re: Slade, RISKS-19.74)

<michael-a.eccles@bae.co.uk>
Wed, 3 Jun 98 12:36:25 +0000
> ... Nick Long from the Low Power Radio Association reports that
> streetlamps in the Nortel trial region have been acting as highly
> efficient antennae ...

According to PCWEEK newspaper (2 June 98) here in the UK, NorWeb (the
company Nortel and Norweb established to develop the technology has
described the allegations as "fictitious and laughable". The company claim
that they have been working with the UK Radiocommunications Agency which has
stated "DPL (Digital Power Line) technology has not interfered in any way
with any radio spectrum users." NorWeb is considering legal action against
Great Circle Design, the company that made the allegations to the press.

Mike Eccles <mike.eccles@acm.org> Independent Safety Auditor for Software


Re: Pager unreliability (McInnis, RISKS-19.76)

"Chris Cartledge" <C.Cartledge@sheffield.ac.uk>
Tue, 2 Jun 1998 15:32:08 +0100
> Hospitals, doctors, and other emergency personnel (and those who
> depend on them) are dependent on paging systems.  Many businesses are
> dependent on paging systems.

I would question the risk analysis of any organisation that depends for
critical messages on the general use of pagers outside a well defined area.

Pagers have the message sent to them once and there is no acknowledgement --
the transmission is single ended and prone to failure.  In a recent test, a
UK consumer magazine found as many as 40% of messages could go astray if the
intended recipient was in a multi-story car park, metro station or similar
location where reception is difficult.

There is a more modern and reliable alternative - SMS, short message system
used with mobile phones, though it may be even more satellite dependent.

Chris Cartledge


Re: Navy stops teaching celestial navigation (Mannes, RISKS-19.76)

Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
Tue, 2 Jun 1998 15:36:07 -0400
<> ... midshipmen will no longer have to learn the often tedious task of
<> using a wedge-shaped sextant to look at the stars and plot a ship's
<> course.

This statement strikes me as just a bit misleading: Celestial Navigation
was--at least when I was a Midshipman at Annapolis in the late 1980's--a
full-semester course; it was not just a few easily-replaced lessons stuffed
inside another course.

So...not only are they eliminating the Celestial Navigation course--they're
planning (according to a friend of mine that currently teaches at Annapolis)
on adding those "few extra lessons on how to navigate by computer" by
replacing some of the lessons in *yet another* navigation course: the basic
navigation course (a prerequisite for the Celestial Navigation course) that
teaches voyage planning, tidal computation, triangulation fixes, etc...real
bread & butter stuff for a junior officer.

Jeff Uphoff - Scientific Programming Analyst, National Radio Astronomy
Observatory Charlottesville, VA, USA juphoff@nrao.edu juphoff@bofh.org.uk


Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77)

Geoff Kuenning <geoff@Ashby.CS.UCLA.EDU>
Mon, 1 Jun 1998 14:06:29 -0700
> I believe there are still backup satnavs, independent of GPS...

I know of no backup satellite systems.  There was a predecessor to GPS, but
I'm pretty sure it's been shut down.  There are two existing ground systems
that provide near-worldwide coverage: Omega and Loran.  Omega is the older,
and is in the process of being retired (it was pretty unreliable already,
judging from the frequent outage notices).  Loran will be retired in the
next few years.

For some perspective, however: sextants are *not* reliable.  They depend on
having a reasonable clear view of both the horizon and some celestial body,
simultaneously.  That means that in bad weather you're stuck, sometimes for
many days at a time.  A flotilla steaming at 30 knots can cover a lot of
ocean, and might just go aground on an island, in that interval.  Even in
the best conditions, sextant shots are accurate to only +/- a mile or so,
making it hard to avoid (or find) that island if it's very small.

In contrast, the military built GPS under the assumption that the USSR would
have anti-satellite capability.  You know all those missiles we have in
silos?  Some don't have warheads; they have spare satellites.  I don't know
the exact numbers, but I'd bet they can get a new GPS broadcaster online in
minutes if they *really* need to.

Geoff Kuenning   geoff@fmg.cs.ucla.edu   http://fmg-www.cs.ucla.edu/geoff/


Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77)

Jim Wolper <wolpjame@cwis.isu.edu>
Tue, 02 Jun 1998 19:34:02 +0000
Dave Pierson suggests, probably correctly, that the US Navy does not intend
to use GPS as the sole source for navigational information.  However, he
alludes to the Transit/SATNAV system as a possible backup system. This
system was decommissioned on 31 Dec 1996.

Nobody has said that the Navy intends to stop using celestial navigation ;
the assertion is that it will not be taught at the very beginning of an
officer's career.  A typical military officer undergoes advanced training as
a prerequisite to new assignments or promotion; a naval officer's training
no more stops at the Naval Academy than a physician's stops at medical
school.  It is certainly possible that young officers will be trained in
celestial navigation at sea.  This might be an improvement over classroom
training.

Jim Wolper ATP/PhD/CFI, Associate Professor of Mathematics, Idaho State
University   Pilot/Instructor, Avcenter, Inc.


Re: Failure modes when the power fails (Weaver, RISKS-19.76)

"George C. Kaplan" <gckaplan@gangrene.net.berkeley.edu>
Tue, 26 May 1998 16:30:32 -0700
In RISKS-19.76, Nicholas C. Weaver described various failure modes in the CS
department during the power failure that hit UC Berkeley on 19 May.  The
entire campus network was, of course, offline during this period, and all
the major network equipment was turned off to prevent damage due to surges
when the power returned.

When it became apparent that the power wouldn't come back before the
end of the working day the network support personnel went home, leaving
instructions with the skeleton operations crew to page them when the
power came back on.

By now we all know about that *other* little problem that afternoon.
Because our pagers weren't working, we didn't hear that power had returned
until someone happened to call in to work to check.  So restoration of
network operations took about an hour longer than it would have if Galaxy IV
hadn't failed.

George C. Kaplan, Communication & Network Services, University of California
at Berkeley  1-510-643-0496  gckaplan@ack.berkeley.edu


Disabling Java and JavaScript isn't totally safe either

Don Byrd <dbyrd@cs.umass.edu>
Wed, 03 Jun 1998 09:43:27 -0400
To avoid the well-known risks of Java and JavaScript--cf. McGraw and
Felten's book Java Security, numerous comments in this forum, etc.--I
usually leave Java and JavaScript disabled in my Browser. But this leads to
another risk, namely missing something important that requires Java and/or
JavaScript but where it isn't clear that they're required. A minor example:
I was just looking at a Web site that boasted a link called "Privacy
Statement". I clicked on it and nothing happened. I tried again; same
result. I was about to give up, concluding that either they hadn't actually
put a statement online yet or the server was having problems of some sort,
when I noticed the status line of my browser showing the link as
"javascript:mapOpen...".

In experience, it is _very_ common for Web pages that depend on Java and/or
JavaScript to give no indication of that, even when you try to use the
dependent features. (If Java is disabled or not implemented, the browser
won't recognize the <applet> tag, and will very likely display any text
until </applet>. So informing the user of this situation is trivial. I
don't know about JavaScript.)

Don Byrd, Center for Intelligent Information Retrieval (CIIR), Computer Science
Department, U. Mass, Amherst, MA 01003 1-413-545-3147 dbyrd@cs.umass.edu


Who is watching the capacity and performance needs of Java solutions?

Jerry Svigals <smartcard@sprynet.com>
Mon, 25 May 1998 17:01:19 -0700 (PDT)
For the past decade, the "conventional" microprocessor smart card had an 8
bit wide microprocessor and up to 64,000 bits of memory.  The Sun Java
language has been proposed as a write once, run in any smart card,
application solution.  it is intended to overcome the fact that most smart
card vendors have an individual design and application architecture.  to run
the java application solution in any smart card requires the use of the java
virtual machine (jvm).  this is an interpretive program language which
converts the java application description into the native language of the
smart card being used.

last december (1997), at the card tech meeting in san jose, a senior sun
executive stated that performing the java application and the jvm requires
more capacity and performance than available in the "conventional"
microprocessor smart card. at the recent april 1998 card tech meeting, the
sun executive changed his tune.  it was possible to run a java application
and jvm in a conventional smart card.  when pressed for details he offered
that the operating system and input/output portions of the application
solution could be expressed in smart card native microprocessor language.
use of the java application language and the jvm could then be processed in
a conventional microprocessor smart card.

what happen to the write one solution, run anywhere java goal.  it has been
quietly abandoned if you want the economics of the conventional 8 bit wide
microprocessor smart card. the full solution is available by going to a
higher performance, higher capacity microprocessor smart card.  with the
need to use a 16 bit or 32 bit wide microprocessor the cost of the smart
card has increased by a factor of two or three times that of the
conventional smart card.

there appears to a quiet conspiracy not to disclose these facts.  sun will
not talk publically, unless pressed.  big java fans like ibm carefully omit
capacity and performance projections from their worldly pronouncements of
java application and smart card architecture.  the smart card vendors have
mostly announced support for java - but they appear to omit performance and
capacity details, even if pressed.

there are serious consequences to these actions.  the significant increase
in smart card costs is of great assistance to those trying to delay smart
card action programs.  it postpones the point at which a business case may
be made to proceed with smart card issue.  it also forces the smart card
vendors to come up with their individual native language components to
support java applications.  this is called an api.  how long will it take to
provide those components?  to what specifications?  what happened to the
write-once, any smart card solution - at implied conventional smart card
costs?

Jerome Svigals Inc., 221 yarborough lane, redwood city, ca 94061
1-650 365 5920  fax 650 363 2198  smartcard@sprynet.com


Referer-log security hole

Jorn Barger <jorn@mcs.com>
Wed, 27 May 1998 17:14:23 -0500
On 11 May, CNet reported a security hole with the "My Excite" web 'portal',
where a subscriber's private ID (effectively their private password) may
show up in the referer-log of the next site they visit.  The article is at:

 <URL:http://www.news.com/News/Item/0,4,21994,00.html>

...and I doublechecked it today with "Pascal's Header Echo" at
<URL:http://echo.znet.de:8888/> -- by pasting the Pascal URL into my
Netscape Location Bar, Pascal *or anyone* will see much more in my
headers than they ought:

===
I. Your Browser sent the following request to this server:

GET / HTTP/1.0 Referer: http://my.excite.com/?uid=12345ABC654321A0
Connection: Keep-Alive
User-Agent: Mozilla/4.03 (Macintosh; I; PPC, Nav)
Host: echo.znet.de:8888
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

===

I've changed the "uid" to a random equivalent, but anyone who found it in
their Referer-log would gain full access to my customized Excite data.

I don't remember even seeing this discussed, but presumably it applies just
as well if you've been browsing pornography, etc, or even looking at an HTML
file in your local filesystem... it would happily deliver up the full path
to that file.

[Added note:] It gets worse and worse:

Going to Altavista and querying "+my.excite.com.uid" turns up 200 pages,
many with usable My Excite passwords.

I EDIT THE NET: <URL:http://www.mcs.net/~jorn/html/weblogs/weblog.html>


globe.com vs Advertising Age passwords: spam and security problem

David Wittenberg <dkw@cs.brandeis.edu>
Thu, 4 Jun 1998 14:40:30 -0400 (EDT)
According to the New York Times 4 June electronic edition article "Marketing
Mixup Raises Concerns About the Privacy of Passwords", 35000 subscribers to
"Advertising Age" received unsolicited e-mail from theglobe.com.  There are
two concerns.  The minor concern is that some of them felt spammed.  The
major issue is that the mail contained an invitation to a free e-mail account
and provided a username/password pair.  This pair was their
username/password from "Advertising Age"'s web site.  Some users worried
that their passwords had been hacked.

In fact theglobe.com was running a site for "Advertising Age", so in that
sense the passwords weren't compromised directly, but why were the passwords
stored in plaintext?  There is also the risk of e-mailing passwords.

David Wittenberg <dkw@cs.brandeis.edu>


Re: CzERT group of hackers ravage Czech & Slovak cyberspace (R 19 77)

Steven Slatem <steven.slatem@intellitech-media.cz>
Wed, 03 Jun 1998 21:57:18 +0200
Herewith are the links, mistakenly omitted in the last RISKS posting, to
the full story "CzERT lives on":

http://www.intellitech-media.cz/public-access/nbisn/19980524-75x.htm

Central & East European Hack Archive/CzERT Hack Archive:

http://www.intellitech-media.cz/public-access/cee-hack-archive/czert-hack-ar
chive

The author (me) welcomes your comments, questions and opinions in regards
to this story as well as the last posting to RISKS which contained points
exclusive to that posting.

- Steven Slatem, Editor-In-Chief, Networked Business & Information Security
News (NBISN), IntelliTech Media, Inc.  http://www.intellitech-media.cz

  [When including URLs in RISKS submissions, please remember to use only
  long-term URLs as in the case of these archival ones.   TNX.  PGN]

Please report problems with the web pages to the maintainer

Top