The RISKS Digest
Volume 19 Issue 37

Monday, 8th September 1997

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

!!! FBI wants to ban the Bible and smiley faces !!!
Ron Rivest
Nielsen snafu hurts cable network's ratings
George Mannes
SSA to Restore Online Web Service
Marc Rotenberg
Password unsecurity in cc:Mail release 8
Carl Byington
Re: SOHO gives 1 hour advance warning to Solar storms
John W. Cobb
Runaways
Lindsay F. Marshall
Re: KAL801 and GPWS
John Kohl
Re: Cockpit data wiped by RF interference?
Chris Norloff
Java date range correction
Rodney Ryan
Re: Tcl 8.0 Y2K Risk
Carlie J. Coats
Jr.
Bill Gunshannon
Re: Y2K and C
Harlan Rosenthal
Re: Tamagotcha!
Markus Aichholzer
Kenneth M. Sternberg
Doris Beers
@LARGE, by David H. Freedman and Charles C. Mann
PGN
Info on RISKS (comp.risks)

!!! FBI wants to ban the Bible and smiley faces !!!

Ron Rivest <rivest@THEORY.LCS.MIT.EDU>
Sun, 07 Sep 97 21:43:23 EDT
Congress is apparently considering legislation that would make it illegal to
post portions of the Bible on the Internet.  FBI Director Louis Freeh wants
to make it illegal to use secret codes on the Internet that the FBI can't
break, and some members of Congress have been drafting legislation in
support of Freeh's position.  However, such a law might have startling
consequences.

A recent best-selling book, "The Bible Code," claims that the Bible is full
of secret messages and codes.  These messages are only partially decoded so
far.  If true, the proposed legislation would make it illegal to post the
Bible on the Internet, unless someone provides the FBI with a way to decode
all of these secret messages contained within the Bible.

Another consequence would require you to register your "smiley faces" with
the FBI.  It is common to use smiley faces to convey meanings.  For example,
the face ;-) is usually interpreted as a "wink".  (If you haven't seen such
smiley faces before, just rotate them ninety degrees.)  Such smiley faces
are an example of a "substitution code", where one symbol (such as ;-) ) is
substituted for another (such as "wink").  Substitution codes are a classic
cryptographic technique.  The proposed law would require you to register
your list of smiley faces with the FBI.  Otherwise, the FBI might have no
way of figuring out what *you* think symbols such as 8-) or :-( might mean.

    ;-)

Ron Rivest

P.S., The proposed language would appear to ban the sale of all computers,
since they are products "that can be used to encrypt communications or
electronic information...".  Ron

  [You think this is early April Fools'?  WRONG.  Think again.  This is
  just a hint of some VERY SERIOUS stuff.  There are many concerned people
  in the computer security community and in the privacy community who
  believe that most of the U.S. populace will be the Fools if the newly
  proposed legislation goes through.  If you want more background, read my
  Senate testimony from 9 Jul 1997
    <http://www.csl.sri.com/neumann/judiciary.html>
  and my follow-up responses, 2 Sep 1997, to questions from Senators
  Thurmond, Grassley, Leahy, and Feinstein, directed at panelists by Senator
  Hatch,
    <http://www.csl.sri.com/neumann/judiciary-ans.html>
  which I wrote *before* the newly proposed legislation was introduced, and
  which seems even more relevant now.  The newly proposed legislation seems
  even more draconian than the earlier McCain-Kerrey bill in the Senate:
  MANDATORY KEY RECOVERY in sheep's clothing.  PGN]


Nielsen snafu hurts cable network's ratings

George Mannes <gmannes@compuserve.com>
Fri, 5 Sep 1997 12:19:03 -0400
A "software snafu" at Nielsen Media Research, the company responsible for TV
and cable ratings, undercounted the viewers of the USA Network on a daily
basis from April 1 through July 1, according to a report by Richard Huff in
the 4 Sep 1997 *NY Daily News*.  The overlooked viewers, about 15,400 homes
each day, were in homes with DirecTV satellite systems. The article
estimates that the undercount cost USA Network $2 million. "It was a very
unique and unusual circumstance, technical in nature," said a USA Network
executive quoted in the story. Correcting USA's ratings, according to the
story, is impossible, because "all DirecTV viewing information about USA was
lost in the computer foulup."

- George Mannes (also of the NY Daily News)

  [Bill Hensley <Bill_Hensley@smtp.rc.trw.com> spotted the *News* item in
  _ShopTalk_, an e-zine covering broadcast TV and radio jobs and issues.
  Bill wonders if the same or similar bug affects measurements for homes
  with different kinds of satellite systems, such as PrimeStar or Dish
  Network, or those with older C- or Ku-band TVRO systems.  PGN]


SSA to Restore Online Web Service (from EPIC Alert 4.12)

Marc Rotenberg <rotenberg@epic.org>
Thu, 4 Sep 1997 18:26:47 -0400
The Social Security Administration announced today it would put a modified
version of the Personal Earnings and Benefits Estimate Statement (PEBES)
service back on-line before the end of the year. The service was suspended
on April 9, following public concerns about the risk of improper access to
personal information held by the agency.

The Social Security Administration said that the new service would be based
on an "opt-in" privacy standard.  Individuals could affirmatively choose to
request the on-line delivery of PEBES information by first obtaining an
authentication code that would only be delivered to a registered email
address.  Records of individuals who did not request the code would not be
available at the web site.

The SSA also said that it would limit the amount of information made
available on-line.  Payment records would not be accessible at the SSA web
site, although they will still be sent by the U.S. mail.

Privacy experts expressed support for the SSA recommendations, saying that
the agency has done a good job meeting with the public, consulting with
experts, and developing sensible standards to protect personal information.

The SSA experience with Internet service delivery is being watched closely
by other federal agencies as well as private companies who hope to take
advantage of the Internet and avoid public concerns about privacy.

The SSA PEBES Service is available at:

     http://s3abaca.ssa.gov/pro/batch-pebes/bp-7004home.shtml

More information on the SSA and Online Privacy is available at:

     http://www.epic.org/privacy/databases/ssa/


Password unsecurity in cc:Mail release 8

Carl Byington <carl@five-ten-sg.com>
Fri, 05 Sep 1997 15:51:21 -0700
After installing a cc:Mail release 8 postoffice (and link to smtp) on an
NT3.51 machine, I noticed that the nightly reclaim process is scheduled via
the standard NT "at" command which runs %systemroot%\~callmnt.bat.  This
batch file simply runs yet another batch file %systemroot%\~ccmaint.bat.
Why do this?  Because the second batch file is "hidden", but a simple
"attrib" command removes that "protection", and then your master postoffice
password is nicely visible.

But you might ask, what are the NT security permissions on these batch
files?  Simply "everyone full control".  Oh well, at least I don't need to
worry about forgetting that password.


Re: SOHO gives 1 hour advance warning to Solar storms (RISKS-19.35)

"John W. Cobb" <cobbjw@ornl.gov>
Wed, 3 Sep 1997 19:00:04 -0400
No new physics. It's basic plasma astrophysics that's been known for over
30 years. The "solar storms" mentioned in the article are carried via the
solar wind --- NOT electromagnetic radiation. That is, particles (mostly
protons) are "drifting" or "streaming" toward the earth at velocities much
less than the speed of light. The currents created by these particle when
they interact with the Earth's magnetosphere and upper atmosphere cause
electrical storms that can cause satellite and power-grid problems.

Good introductory material can be found in Frank Chen's "Introduction to
Plasma Physics and Controlled Fusion" vol. 1 (Plenum, New York, 1974 — at
least my copy). Another reference is Priest's "Solar Magnetohydrodynamics"
(I believe that's the correct cite — my copy is currently on loan)

Chen states (p. 14) the solar wind drift velocity is 300km/sec. At that
speed it would take about 90 minutes to cover 1 million miles. Given
geometrical factors for the location of Earth-Sun gravi-neutral points, 1
hour is probably about right.

The real risk here is one of journalistic mis-communication. So often we
read common media reports of scientific matters and are left to ourselves
to deduce the actual scientific content. Often the journalists mangle the
scientific concept badly.

However, in this case, it looks as if the journalists were correct — if
scientifically abbreviated. Sam adds inappropriate contextual information
from his experience to arrive at an apparent problem where none really
exists.

Maybe there is a risk here worth mentioning. I've call it the risk of
assuming "I know what you *meant* to say" or "introducing errors from
patronizing inference".

Now maybe there *is* a problem with the statement that SOHO CAN provide
early warning for these storms. I mean at first blush, if SOHO blinks out,
am I to take that as a flag indicating an impending storm in less than an
hour?  Considering the reliability of satellites — probably not. However,
these storms don't just come out of the blue (or Orange). Rather they are
associated with activity on the Sun's surface such as prominences, coronal
mass ejections, and such. One of the puzzles is that "events" at the sun do
not necessarily imply storms at earth. How can we find out which ones do?
This is a fascinating area of study in and of itself, but I don't claim to
be particularly current on these issues and by now we're pretty far afield
from talking about risks of computers.

John W. Cobb Computing/Information/Networking Division, Oak Ridge National
Laboratory MS-6144 Oak Ridge, TN 37831-6144 423.576.5439 cobbjw@ornl.gov


Runaways

"Lindsay F. Marshall" <Lindsay.Marshall@newcastle.ac.uk>
Fri, 5 Sep 1997 12:34:22 +0100 (BST)
I found this at <URL:http://www.electronicgizmos.com/> :

  Our remote-control car starter lets you start your car and turn on your
  heater, defroster, or air-conditioner from the comfort of your home or
  office, up to 400 feet away.  Autocommand comes in variety of retail and
  installer versions. In addition to remote starting, depending on the model,
  you can use your Autocommand transmitter to lock/unlock the doors and
  trunk or even operate a complete alarm.

The potential dangers seem to be immense! Think about garage door openers
for one.

Lindsay <http://catless.ncl.ac.uk/Lindsay> [Lightly edited for readability]


Re: KAL801 and GPWS (Ladkin, RISKS-19.36)

John Kohl <john_kohl@alum.mit.edu>
Thu, 4 Sep 1997 09:55:39 -0400 (EDT)
PL> The GPWS provides some detection of incorrect barometric altimetry
PL> when this errs in the unsafe direction (when the aircraft is lower than
PL> pilots think - higher is of course safe, although equally incorrect).

Higher is safe in regards to ground terrain, but not necessarily safe
regarding other aircraft!

==John


Re: Cockpit data wiped by RF interference? (Imran, RISKS-19.34)

Chris Norloff <cnorloff@norloff.com>
Thu, 04 Sep 1997 08:03:45 -0400
Previous contributors made excellent comments on whether or not cell phones
actually caused the cockpit data wipeout, or merely happened to be in use at
the time the data was lost.  Anyone who has witnessed the office cries of
VIRUS! VIRUS! every time software hiccups can appreciate the need to
determine cause and effect with computer systems.

A point I'd like to make is why are these aircraft systems assumed to be so
vulnerable?  Can you really crash a plane by turning on an ordinary FM radio
like a Walkman?  Can you really destroy cockpit flight data by pressing SEND
on a cell phone?  The US military goes to the extent of protecting their
office desktop computers from sending or receiving unintentional RFI (the
TEMPEST program) and airline companies don't protect 400-passenger aircraft
systems from stray RFI?

Either aircraft systems are shockingly vulnerable, or these common consumer
electronic devices are not the problem they are made out to be.

I can see it now, next year's blockbuster movie ... Nicholas Cage rushes
into the 747's cockpit, "Don't anybody move!  I've got a cell phone and I'm
not afraid to use it!"

Chris Norloff


Java date range correction (Anderson-Lee, RISKS-19.36)

Rodney Ryan <rer@interport.net>
Thu, 04 Sep 1997 01:28:13 -0700
>  "Java seems to be limited to the Unix date range (1970-2038)".

This is indeed wrong.  The Java core package method
System.currentTimeMillis() returns the current system time in milliseconds
since 1/1/1970 as a Java primitive type long, which is implemented as a
64-bit two's-complement signed number.  The maximum positive value is
9223372036854775807, which gives us an upper limit of sometime after
292,271,000 A.D.

Java *itself* will never encounter any "Y(2...n)K problem" - any limitation
will belong to the OS that is supporting that particular version of Java
(such as, for instance, Solaris 2.5.1).

Rodney Ryan, Software Architect rer@interport.net http://www.interport.net/~rer

  [Just to correct the record.  Expiration in the
  year 292,271,023 was already noted in RISKS-19.21.  PGN]


Re: Tcl 8.0 Y2K Risk (Anderson-Lee, RISKS-19.36)

<coats@mcnc.org>
Thu, 4 Sep 1997 13:26:50 -0400
> ... When 64-bit operating systems finally catch on there will be a lot of
> code to change when "long" becomes 8 bytes, while the data on disk is
> still only 4.

This ignores the fact that an enormous amount of current C software
incorrectly relies upon having exactly-4-byte integers for type "long".

This is so prevalent that for the upcoming C9x standard, the Powers That Be
are seriously considering introducing a bastard "long long" type so as not
to break code relying upon this nonstandard behavior.

There is a substantial risk that systems from Sun, SGI, HP, and DG
will still use 4-byte integers for "long" in 2038.

Carlie J. Coats, Jr., MCNC Environmental Programs, NC Supercomputing Center,
3021 Cornwallis Road, P.O. Box 12889, Research Triangle Park, NC 27709-2889


Re: Tcl 8.0 Y2K Risk (Wood, RISKS-19.36)

Bill Gunshannon <bill@cs.uofs.edu>
Thu, 4 Sep 1997 10:23:32 -0400 (EDT)
>  Changing expected behaviour and going against user assumptions that
>  have been built upon prior experience is an even bigger risk than Y2K, IMO.

Or, forgetting legacy behavior, one can also make some wrong assumptions.

>  Handling the input unexpectedly before it gets to the script is
>  dangerous - compare with the previously-discussed Javascript tendency
>  to treat numbers with leading zeroes as octal, for instance.

Treating numbers with leading zeroes as octal is a very old concept in the
computing world and, in fact, is still the case in some very common programs
even if most people are unaware of this fact.  I offer one example, the
program "ping"! (I am sure research would find other programs as well.)

Please observe:

>>>>>>>>> ping -c 3 134.198.10.10
          PING 134.198.10.10 (134.198.10.10): 56 data bytes
          64 bytes from 134.198.10.10: icmp_seq=0 ttl=254 time=3.036 ms
          64 bytes from 134.198.10.10: icmp_seq=1 ttl=254 time=3.104 ms
          64 bytes from 134.198.10.10: icmp_seq=2 ttl=254 time=2.972 ms

          --- 134.198.10.10 ping statistics ---
          3 packets transmitted, 3 packets received, 0% packet loss
          round-trip min/avg/max = 2.972/3.037/3.104 ms

>>>>>>>>> ping -c 3 134.198.010.010
          PING 134.198.010.010 (134.198.8.8): 56 data bytes
          64 bytes from 134.198.8.8: icmp_seq=0 ttl=63 time=12.493 ms
          64 bytes from 134.198.8.8: icmp_seq=1 ttl=63 time=56.231 ms
          64 bytes from 134.198.8.8: icmp_seq=2 ttl=63 time=56.178 ms

          --- 134.198.010.010 ping statistics ---
          3 packets transmitted, 3 packets received, 0% packet loss
          round-trip min/avg/max = 12.493/41.634/56.231 ms

Notice that while these two commands would appear to be equivalent (almost
duplicate) to a human, the computer saw them as very unique.  The question
becomes, How long do we prolong this behavior after it has lost it's real
significance??  How many machines today actually use OCTAL representation in
their day-to-day operation?? And the RISK??  How can a user possibly know
beforehand which way the number will be interpreted?? (Is 011 in octal,
decimal, hex, binary or even some other less common numbering base??)  And
there is the additional RISK of accusing someone (in the above case,
Javascript) of aberrant behavior when in fact, the action is quite normal
and completely intentional.

Bill Gunshannon, University of Scranton, Scranton, Pennsylvania
bill@cs.uofs.edu


Re: Y2K and C (RISKS-19.36)

"Rosenthal, Harlan" <rosenthh@dialogic.com>
Fri, 5 Sep 97 9:32:05 -0400
<> ... a C "long" which is currently 4 bytes.  When 64-bit operating systems
<> finally catch on there will be a lot of code to change when "long"
<> becomes 8 bytes, while the data on disk is still only 4.

C is the only language I've ever used in which the *source* code isn't even
portable because such basic concepts as intrinsic datatypes are
indeterminate (and are *defined* as such in the original specification).
Does it worry anybody else that this is the language used by most people and
taught to most beginners?  I suppose at least we're not teaching BASIC using
two-letter variables and GOTOs, but still . . . .

-harlan


Re: Tamagotcha! (Kabay, RISKS-19.36)

Markus Aichholzer <maai@csesys.co.at>
Thu, 04 Sep 1997 10:36:51 +0200
Many people call the Tamagotchi an e-pet; a lot of people think taking care
of a such a pet is good training for life!  Looking realistically, the
Tamagotchis are nothing other than computer games, like Game-Boy, Nitendo
etc.  The only difference is that the game dies not after a few minutes but
after a few weeks (if you play the game well). So, all the discussions are
about a long-term-computer-game, not about an animal that dies!

I do not think that is good for our children to teach them that playing
Computer games is the same as taking care for a pet.  Children should not
come to the idea that taking care of a real pet is as easy as playing Games
on a display and a few buttons.  They should not think that the fun you can
have with your real-pet can be had by playing with buttons.  They must know
that a real-life animal does not always react as programmed (hunger-food-OK,
illness-medicine-OK, etc.).  These things you cannot learn by playing on a
computer — only by taking care of a real pet.  Parents should not think,
that when their child asks for a pet they can put their conscience at rest
by buying a computer game.  I think, we should tell the children the truth
-- it is a game! Then the problems in schools will be solved automatically,
because children would know they cannot play with the GameBoy in school.

Markus Aichholzer, CSE Systems, St. Veiter Strasse 4  A-9020 Klagenfurt Austria
++43 463 50645 34   maai@csesys.co.at   http://www.csesys.co.at


Re: Tamagotcha! (Kabay, RISKS-19.36)

"Kenneth M. Sternberg" <elf@spry.com>
Thu, 4 Sep 1997 11:51:38 -0700 (PDT)
In RISKS-19.36, "Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com> wrote about
the risks involved in allowing virtual pets (and, as he points out, real
pets) into the lives of children who must be separated from these pets for
school hours.

A perhaps less-visible risk is the impact the popularity of these devices
has had on manufacturers.  In a recent TechWire article it was noted:

    "Our fab capacity is fully booked for the remainder of the
    year [manufacturing chips for Bandai's Tamagotchi]," said
    a spokesman for Hsinchu-based United Microelectronics
    Corp. (UMC), one of the world's largest chip foundry
    concerns. "Some of our customers are very disappointed."

    Taiwan's foundry companies are making 20,000 to 30,000
    8-in. wafers per month just for the Tamagotchi and its
    imitators, according to the UMC spokesman. By one estimate,
    chips consumed by the toys now account for 10 percent to 15
    percent of the island's fab capacity.

Full text of the article is available at:
http://www.techweb.com/se/directlink.cgi?WIR1997082505

The risk here is obvious-- the computer manufacturing infrastructure is
not prepared for a consumer craze that draws heavily on its resources.
Other fads have had similar impact on the manufacturing bases upon which
they depended.  However, the industries represented by those manufacturers
were rarely, if ever, the same that businesses, governments, and
militaries rely upon for day-to-day supply and operation.

Elf M. Sternberg, Spry Consulting Group, CompuServe Internet Division
3535 128th Ave SE, Bellevue, WA 98006  425.957.8000  elf@spry.com


Re: Tamagotcha! (Kabay, RISKS-19.36)

Doris Beers <Doris.Beers@lgtna.com>
Thu, 4 Sep 1997 12:39:00 -0400
The digital pet sold under the brand name Tamagotchi has a pause function.
My nine-year-old figured this out the same afternoon he first set it up.  It
is also in the instructions (Read the fine insert?).  One simply presses the
combination of buttons that brings up the time set function and leaves it
there.  When the pet is to be revived, one cancels out of that function, and
the pet is back where it started.

I insisted my son do this the first night he had it to avoid clashes between
the pet's sleep schedule and his or a "dead" pet the first morning he had it.

Doris.Beers@lgtna.com


@LARGE, by David H. Freedman and Charles C. Mann

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 5 Sep 97 8:12:50 PDT
I recently received a copy of

  David H. Freedman and Charles C. Mann
  @LARGE, The Strange Case of the World's Biggest Internet Invasion
  Simon and Schuster, 1997.  ISBN 0-684-82464-7.

This is reportedly an entirely factual saga — somewhat sociological,
somewhat technical — of the "Phantom Dialer" (whose is aliased in the book
as Matt Singer).  (The authors suggest that some of the dialogues may be
artistic verisimilitude, but the details are claimed to be true.  There are
just a few minor factual errors that probably result from the authors being
journalists rather than insider-techies, but the insiders will detect them
without flinching, and they are not important for others.)  The book is
rather well told, and reads somewhat like a Clancy novel — hopping about
from one thread to another, where the threads all more or less converge.
Lots of folks and institutions show up that will be very familiar to many of
you.  Most of the actual security vulnerabilities and types of penetration
exploits should be known to many RISKS readers.  This book will not break
any new ground for SysAdmins, security experts, good hackers, or bad
hackers, but nonetheless has some appeal.  The treatment of its principal
Internet intruder is perhaps somewhere between pathos and bathos.

One of the chapter-head quotes is from Gene Spafford: "Using encryption on
the Internet is the equivalent of arranging an armored car to deliver
credit-card information from someone living in a cardboard box to someone
living on a park bench."

Please report problems with the web pages to the maintainer

x
Top