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 01

Tuesday 1 April 1997

Contents

o French computer systems found to be immune to Y2K problems
John O'Connor
o The Year 2100 Problem: a simple solution
Martin Minow
o Microsoft buys Sun
Mark Stalzer
o Maybe we should start a "savoracle" e-mail address
Martin Minow
o The risk of perceiving the usual as normal
Gene Wirchenko
o Spry policy change causes e-mail denial
Michael Miora
o Unsecure online banking
David Ross
o AT&T Worldnet snafu/scam
Matt Holdrege
o Free book because computers cannot lie
Mich Kabay
o Re: Computer model blamed for $83 Million loss
Mark Stalzer
o Re: RISKS of tracking packages
Matt Welsh
o Correction for ``hard core bits'' reference
Paul Eggert
o Re: all-ways green lights
Mark Brader
Steve Summit
Dik T. Winter
o "Child Safety on the Internet" by Distefano
Rob Slade
o Info on RISKS (comp.risks)

French computer systems found to be immune to Y2K problems

"John O'Connor" <jpoc@cix.compulink.co.uk>
Tue, 1 Apr 1997 0:59:59 +0100 (MET)
Paris, Tuesday, 1st of April 1997

The French Ministry of Informatics (MOI) today announced that they have
determined that French computer systems will not be affected by the year
2000 problem.  An extensive series of tests have been run on a wide range of
applications within the country and on no system has a Y2K problem been
apparent.

A spokesman put this good fortune down to a side-effect of the French number
system.  In this system the number eighty is represented by the composite
"quatre vingts" -- literally "four twenties."  French computer systems
represent the "quatre" as a single digit and will harmlessly roll over to
"cinq vingts" or "five twenties" while the rest of the world collapses.
Thus, "quatre vingts dix neuf" will increment to "cinq vingts."

French speaking areas of Belgium and Switzerland are bemused by these
developments, because they still use the older "septant, octant, nonant"
system for 70, 80, and 90.  The Belgian government is thought to be
considering an urgent change in the language.  This would provide a major
boost for the less prosperous French speaking part of the country when
computer systems are relocated to French speaking communes.

Microsoft has announced that it will use similar techniques to guarantee the
PCs will not suffer from such problems, by launching a new version of their
operating system.  "Windows ninety ten" is expected to be available in the
year 2002.

  [``MOI?'', dit Mademoiselle Petite-Couchon
  (better known here as Miss Piggy).  PGN]


The Year 2100 Problem: a simple solution

Martin Minow <minow@apple.com>
Tue, 1 Apr 1997 00:00:00 -0800
A few weeks ago, someone who used a calendar application I wrote e-mailed me
a warning that the program *incorrectly* (his words) indicates that the year
2000 will be a leap year.  (The application, including source, is available
in several on-line archives.  Use a search engine to locate
mac-calendar-cs.hqx.)

After explaining the entire leap-year algorithm to my correspondent, I
realized that the overall year-2000 problem is just the tip of the
software-bug iceberg.  For example, in the year 2100, software using a
popular oversimplified algorithm that computes leap years as "year evenly
divisible by 4" will break for the first time since 1900 [when there were no
computers doing this kind of calendar arithmetic anyway].

Since, by that time, software will be even more difficult to fix than it is
today, I humbly propose that it would be simpler to fix the erroneous
definition of the "second" than to fix the software.  According to my
calculations, by lengthening the second by only 0.00001312449483, which
surely will be not noticeable, leap-years will occur every four years
without the clumsy and error-prone corrections necessitated by the poor
mathematical abilities of medieval monks.  (Recall that the meter was
recently changed so that the speed of light is exactly 3,000,000
meters/second).

Because adjusting the duration of the second will lead to a considerable
simplification of date-conversion software, and an elimination of a source
of considerable confusion and error, it would be well worth the minor
disruption (barely a second a day) that this might cause to existing,
old-fashioned, analog timekeepers that can't keep time that accurately
anyway.  Of course, the length of the meter would have to be changed again.

Martin Minow minow@apple.com

  [Martin's proposed solution seems very timely(!), and incurs *no* software
  costs -- in contrast to the Y2K problem, with estimates of fixes running
  in billions (and trillions?) of dollars worldwide.  Incidentally, newer
  readers with foresight might go back and visit RISKS-17.83 and 84, noting
  that the length of a tropical year is (at present) 365.24219 days.  Barry
  Jaspan suggested that the correction of making every 4000 years *not* a
  leap-year gives a closer approximation.  Alternatively, Jan Vorbrueggen
  suggested that years divisible by 2000 would not be leap years unless
  divisible by 4000, and years divisible by 16000 would not be leap years
  unless divisible by 400,000, which averages out to 365.24219 days per
  year.  Of course, by the year 400,000 the length of the tropical year will
  have changed.  However, even if Martin's solution has to be tuned once in
  a rare while, it would never require any software changes.  Think of the
  savings!  On the other hand, what are the odds that there will still be a
  Risks Forum issue on 1 April in the year 400,000, and that it will still
  be devoted to recently discovered risks involving calendar arithmetic?  PGN]


Microsoft buys Sun

Mark Stalzer <mas@acm.org>
Mon, 31 Mar 1997 17:04:01 -0800
This item may be of some interest to RISKS readers, given all of the
discussions about ActiveX and Java. -- Mark

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

Redmond WA, March 31 (Routers) - Microsoft Corporation announced after the
close today that it will buy Sun Microsystems in a deal valued at $11.7
billion.  The price works out to $50 a share, which is a premium over Sun's
close at $34.  Microsoft will finance the deal by issuing 50 million shares
of common stock, using some of its cash reserves, and borrowing $5 billion
at "very low rates" from a "long time strategic partner" rumored to be Intel
Corporation.  Every 4 shares of Sun stock will be exchanged for 1 share of
newly issued Microsoft stock plus approximately $100 in cash.

Bill Gates, Microsoft's Chairman said "It's time to kill Unix.  Unix is
providing stiff competition to Windows NT in the server arena.  We have
already placed NT on Digital and HP servers, and Sun was the only
substantial holdout.  So we decided just to purchase Sun to assure that
their servers ship with NT."  He continued, "We also wanted control over
Java to better position ourselves to, uh, compete with Netscape."

The deal was approved earlier today by the boards of both companies.  Large
institutional holders of Sun are known to favor the deal so it should get
shareholder approval in the coming weeks.  Privately, a Sun board member
said "the price was so sweet, we would be violating our responsibility to
the shareholders if we didn't accept the offer."  Scott McNealy, Chief
Executive Officer of Sun, was unavailable for comment.  Several Sun
employees expressed dismay, one adding simply that "this sucks."

When asked about transition plans for Solaris, Sun's version of Unix, Taj
Raji, Sun's Vice President of Systems Software, said that the "Solaris APIs
will be wrapped around the NT megakernel in a seamless fashion to produce a
robust feature-rich operating environment."  A Microsoft spokesperson
quickly added that "only native NT applications certified by Microsoft get
to use the flying windows logo."

Speculation about Intel's possible involvement centered on the SPARC chips
that power Sun's servers.  Intel might incorporate the SPARC architecture
into their planned Hexium "You're Inside" family of processors.  If these
chips were used in Sun servers, analysts say that Intel would lock up the
worldwide processor market.

As for Sun's Java technology, if Microsoft follows their standard practice,
they will make proprietary enhancements to assure market share.  One insider
suggested that they might make "Java more like C++", but others said that
would be foolish.  April Austin, a technology analyst with Hambust-Quick in
Oakland CA, commented that "the buyout could really put a crimp on Netscape
since Microsoft will control the two major means of placing active content
on the web, ActiveX and Java.  Microsoft will set the standards and Netscape
will always be six months behind the feature curve."

A spokesperson for the Department of Justice said there was no official
comment on the proposed transaction.  Although, a highly placed Justice
source felt that there shouldn't be any problems because "Microsoft is a
software company and Sun is a hardware company."

The combined company's yearly sales will be approximately $16 billion based
on end-of-year figures.  For the day, Microsoft (MSFT.O) was up 1 5/8 at 97
7/8 and Sun (SUNW.O) was up 3 3/4 at 34.  Officials at the Pacific Stock
Exchange reported that the volume on Sun April 30 calls was 15 times
normal.  The SEC is investigating possible insider trading.


Maybe we should start a "savoracle" e-mail address

Martin Minow <minow@apple.com>
Mon, 31 Mar 1997 10:07:31 -0800
>From http://www.macintouch.com

  "The e-mail address we first reported for feedback on Larry Ellison's
  Apple takeover idea [saveapple@us.oracle.com] did not work, apparently due
  to an 8-character limitation in Oracle's e-mail system.  The revised
  address is savapple@us.oracle.com ."

Noted without further comment by Martin Minow minow@apple.com

  [I suppose they should have indirected it through Oracle@Delphi.com,
  which Greek legend tells us could have interpreted the address wisely.  PGN]


The risk of perceiving the usual as normal

Gene Wirchenko <genew@vip.net>
Fri, 28 Mar 1997 02:16:52 GMT
Not too long ago, I moved from Vancouver, BC to Penticton, BC.  It then
being long distance to Vancouver, I needed to change my ISP.  I did this.
On the new ISP, the newsgroup service was flaky.

How did I know about the flakiness?  Simple.  I continued with the same
newsgroups that I had been using and noted a marked drop in volume as well
as seeing responses to messages which I hadn't gotten.  The latter had
happened but rarely before.

I was told I was the only one to complain.  (Remember that Customer Service
critters can always say this at least once (the first time).)  It took some
convincing on my part to get them to see it, but now they are looking at how
to get out of their existing newsgroup feed contract.

The risk here is getting used to a state and thinking that state normal.  If
I had just signed up in Penticton, I might never have noted anything out of
the ordinary.  Apparently, that's what has been happening.

Gene Wirchenko


Spry policy change causes e-mail denial

Michael Miora <mmiora@miora.com>
Fri, 28 Mar 1997 10:06:25 -0800
Until last week, I used Sprynet as my ISP. They provided me with SMTP
services (I have my own POP server) and Newsgroup services. Sometime
last week, at a time and date nobody at Spry would or could divulge,
Spry instituted a new policy: server access would be denied to anybody
using a non "@sprynet.com" return address. This included SMTP and
Newsgroup servers, along with unspecified other servers.

The result of this unannounced policy change was that anyone with either
his/her own domain name or using other external, ISP-independent
addresses lost e-mail, newsgroup, and other unspecified services. We
received unintelligible error messages from the Newsgroup servers. We
received occasional e-mail returns with the message, "External server
access denied." Not all e-mail was returned this way, some was simply
discarded. In all cases, the time-to-return was unpredictable, in one
case exceeding 12 hours.

When the errors began occurring regularly, I tried contacting Spry tech
support and customer service. The long distance numbers had wait times
estimated at 20-30 minutes. After 45 minutes, I hung up. I connected to
the IRC "chat.sprynet.com#spryhelp" and was told of this new policy.
When I explained the implications, they replied: "Sorry, those are the
rules. We are not responsible."

They are quite correct, they are not responsible. This unannounced
change on a system was a de facto denial of service attack on many
legitimate users. Spry's explanation was that their SMTP and Newsgroup
servers were being used by non-Sprynet subscribers and that this
rule-based authentication was their only way of eliminating unauthorized
use, given that these servers did not support log in protocols. I wonder
how many of these "unauthorized" users were legitimate Spry customers
with non-Sprynet addresses.

Michael Miora, Miora Systems Consulting, Inc.
mmiora@miora.com; http://www.miora.com


Unsecure online banking

David Ross <rossde@acm.org>
Thu, 20 Mar 1997 21:18:31 -0800
Western Federal Credit Union (WFCU) at http://www.western.org/ provides for
home banking over a supposedly secure Web site.  Several problems plague
this site.

On entering the Home Banking site, a popup notifies the user that a secure
document has been requested.  The popup has no cancel capability; the Cancel
button is deactivated.  The user has to continue to the login page and then
select a link to return to the home page.

If the user continues by logging in, a total of seven "going secure" popups
appear even though the site does not go insecure once.  An error in the use
of RSA tools is strongly indicated.

Once within the secure site, the user sees an Exit button.  Selecting that
button returns the user to the WFCU home page without leaving the secure
mode.  The user is then on a Web page for which security cannot be
justified.  Selecting the link to the menu page (there being little else on
the home page), the user remains in secure mode, still for no reason.  For
the user to return to insecure mode requires selecting the user's home
page.  This is definitely contrary to proper use of the RSA tools and
indicates a lack of proper verification of the design of the Web site.

This problem was reported to WFCU's Webmaster along with a request that
users be notified of potential security failures caused by software
incorrectly using RSA tools.  A week later, the problem still exists; no
user warning has been posted on the Web site.

By the way, WFCU is the successor of SDC Federal Credit Union.  The latter
was the credit union for the employees of System Development Corporation
(SDC), the company that initially established computer programming as a
discipline distinct from designing and building computer hardware.  Before
then, the only people who programmed were the engineers who custom-built
the computers.  Somehow, I expected more from WFCU, given this heritage.

David E. Ross  http://www.geocities.com/CapitolHill/6727/index.html


AT&T Worldnet snafu/scam

Matt Holdrege <HOLDREGE@Eisner.DECUS.Org>
Mon, 31 Mar 1997 18:19:09 -0500 (EST)
Like many people, I signed up for AT&T Worldnet back when they first
announced free Internet access for up to 5 hours per month.  Also like many
others, I decided I didn't like the service and stopped using it.  I thought
that AT&T being a reputable company would not give me any problems.

Today I received a card in the mail saying that my introductory year is
almost over and I need to choose which rate plan to use.  I can choose
unlimited for $19.95 per month or hourly for $4.95 per month plus usage.

It says if I do nothing, I will automatically stay in the hourly plan and be
billed $4.95 per month.  There is no phone number to call to complain, nor
is there an e-mail box listed.  I tried AT&T main numbers but they know
nothing about Worldnet.  There is an URL listed, but I tried several times
today to access it and the path to it is overloaded.  I'm sure if I did find
out the number to call, it would also be overloaded.

I will make sure somehow that I am not billed, but I wonder how many folks
will be surprised with a $4.95 entry on their credit card or AT&T phone
bill.

Matt Holdrege    holdrege@eisner.decus.org


Free book because computers cannot lie

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Fri, 28 Mar 1997 04:57:55 -0500
Another in the "Computer Can't Lie" series that we have been seeing lately
in RISKS (e.g., "Telephone Scam" responses in RISKS-18.91; "Bank cannot
believe it made a mistake!" in RISKS-18.92):

I received an interesting book from my synagogue office -- but never ordered
it.  When I called the synagogue office, the secretary told me that I had
registered for a course several months ago, had ordered this book, and had
actually paid for it.

None of the above is correct.

I protested that there had been a mistake, and offered to return the book.
The secretary insisted that what she had said must be true: "Look, it's in
the computer -- you must have done it."

I gave up and am keeping the book until further notice.  When they fix their
files, I'll return their book.  Mich

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com


Re: Computer model blamed for $83 Million loss (Kaplan, RISKS-18.97)

Mark Stalzer <stalzer@macaw.hrl.hac.com>
Mon, 31 Mar 1997 13:52:34 -0800
Financial models are used for a reason more fundamental than the complexity
of the instrument, namely there may not be a market available to discover
the instrument's price. If you want to know the price of Intel, you go to
Yahoo!, type in INTC, and get the price. This works because there is a
liquid market in Intel shares. The markets in common Intel derivatives
(calls/puts) out to expirations of a few years are also liquid. But let's
say you want to buy an Intel call that expires in 5 years. This instrument
is not traded on any exchange so what's it worth? Fortunately, models exist
that can price this option if you know some parameters that can be observed
in the markets. For example, the most common options pricing model,
Black-Scholes, needs the yield curve of the dollar (risk free interest rate
vs. maturity), current price of Intel, exercise price (strike), expiration,
and volatility of Intel's stock price.  All of these parameters are known or
can be determined from current and past market data. You drop them in and
out comes a value. You can test the model against market traded instruments
and tweak the parameters (mostly volatility) as necessary.  The model and
the market determined parameters give traders the tools to write all sorts
of funny contracts at sensible prices.

It's certainly true that there are much more complex instruments and the
models can get quite sophisticated. Obviously, there are bugs, and the users
need to be very careful.

It should be said that to really blow up an investment house requires a
human. Barings fell due to forgery, misappropriation of funds, illegal
trades, no management oversight, all the usual stuff. The financial
community is responding with increased reporting requirements and some
external review over pricing models (it depends on the country, but the UK
appears to lead here). I think these are good ideas, but the computer
related risks are increasing.

Mark Stalzer, mas@acm.org


Re: RISKS of tracking packages (Ishikawa, RISKS-18.92)

Matt Welsh <mdw24@cl.cam.ac.uk>
27 Mar 1997 15:12:41 GMT
Chiaki Ishikawa worries about tracking a postal package delivery (over the
Internet, say) without any authentication:

>In any case, I can't wait to mistype a digit/letter of an assigned number
>to MY package to see if it will print out someone's supposedly private info.

This has happened to me - in reverse.  I was once tracking a package be
delivered to me by a major US parcel carrier (I believe it was UPS), using
the carrier's automated tracking system via a Web page.  I entered the exact
parcel number that I had been given, and lo and behold - I discovered that
some months earlier a package had been delivered to a particular address and
signed for by a particular person ... with the same tracking number.

In most cases it's difficult to invent or mistype these tracking numbers
(they may use a particular encoding or checksum), but in this case I was
able to learn something about someone else's private delivery using MY OWN
tracking number.  Apparently this carrier recycles the numbers!

So many problems in this world which could be solved with proper security
and authentication techniques.  What's really amazing is that this
technology already exists, but politics prevents us from deploying it.

M. Welsh, University of Glasgow/University of Cambridge


Correction for ``hard core bits'' reference (Re: Nelson, RISKS-18.94)

Paul Eggert <eggert@twinsun.com>
Thu, 27 Mar 1997 15:39:06 -0800
In RISKS-18.94, when writing about using hard core bits to defend against
statistical attacks on cryptographic algorithms, Jeff Nelson referred to the
Eurocrypt '95 paper ``Universal hash functions and hard-core bits'', but
unfortunately he gave the wrong authorship for that paper.  The actual
author is Mats Näslund of the Royal Institute of Technology, Stockholm.

You can find a copy of the paper itself at:
ftp://ftp.nada.kth.se/pub/documents/Theory/Mats-Naslund/hh-ec95.ps.Z


Re: all-ways green lights (DeBert, RISKS-18.94)

Mark Brader <msb@sq.com>
Mon, 31 Mar 97 15:07:58 EST
> Probably some of the same thinking is involved as that which led
> certain parties at NASA to conclude that since the seals had
> eroded by x% but the shuttle hadn't crashed, x% erosion must be okay.

Didn't they even say that, after all, they still had a factor of safety
of (100-x)/x?  (As if the erosion had been modeled and was known to
proceed at a constant rate, when in fact it was completely unexpected
and its behavior was, as experience showed, unpredictable.)


Re: all-ways green lights (RISKS-18.94,95)

Steve Summit <scs@eskimo.com>
Fri, 28 Mar 1997 12:23:32 -0800 (PST)
Well, shoot!  I've believed (and asserted) that it was impossible, too.  Not
(of course) because I have any deep faith in the perfection of software, but
because it was so obvious to me that the right way to build a
computer-controlled traffic signal would be to have the brand-new high-tech
solid-state circuitry control the actual (110VAC) signal lamps through a
last stage of old-fashioned relays, configured in such a way that it's
physically impossible to have two conflicting greens on at once.  (In the
simple case, for example, the north-south green lights and the east-west
green lights could be driven by opposite poles of a double-pole,
break-before-make relay).

In fact, I was so sure that this was the right way to do it that I'd managed
to convince myself (based on no more evidence than sheer speculation) that
this *was* the way modern signals were in fact constructed.  Are they not?
I'm crushed.  (Would I be out of place if I exhorted those reading this to
use such a design in any analogous safety-critical systems they have any
control over?)

Steve Summit  scs@eskimo.com


Re: all-ways green lights (RISKS-18.94,95)

Dik T. Winter <Dik.Winter@cwi.nl>
Sat, 29 Mar 1997 01:47:50 GMT
There are many articles about this issue.  However, it was solved in the
Netherlands before such a thing as a computer controlled traffic sign could
emerge.

The general rule is that traffic from the right has the right of way.
Traffic signs do *not* overrule that general rule %.  A green sign merely
grants you the right to proceed while a red sign tells you that you are not
allowed to proceed.  So if you enter a crossing with your light green you
still have to obey the general right of way rule, even if you might think
that his/hers sign was red.

This ruling has been upheld in the high court (or supreme court or whatever
translation you want to apply).  The reasoning is simply that lights can be
defective, so you can not get rights from a green light because the other
party may have seen no light at all.

________
* Actually there are very few rules that override it, except explicit signs
and a few more.  For instance, if there is a one-way road on the right so
you may not expect traffic from it, if there comes traffic from it you must
yield the right of way.  (Of course the other party may be guilty of going
in the wrong direction in a one-way street; that is a different matter.)

dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/


"Child Safety on the Internet" by Distefano

Rob Slade <roberts@mukluk.hq.decus.ca>
Mon, 31 Mar 1997 14:11:49 EST
BKCHSFIN.RVW   961128

"Child Safety on the Internet", Vince Distefano, 1997, 0-13-569468-X,
U$34.95/C$48.93
%A   Vince Distefano
%C   One Lake St., Upper Saddle River, NJ   07458
%D   1997
%G   0-13-569468-X
%I   Prentice Hall
%O   U$34.95/C$48.93 +1-201-236-7139 fax: 201-236-7131 beth_hespe@prenhall.com
%P   296
%S   Classroom Connect
%T   "Child Safety on the Internet"

This volume contains a helpful and generally realistic set of resources.  It
talks primarily about the dangers, but does note that the risks are not as
bad as some of the hype.  The book does, for once, look at other "dangers"
besides pornography, and has a reasonable chapter on netiquette.  Online
service protection options, content rating systems, and protective/support
groups are discussed.  In addition, there are suggestions and advice for
"after the fact" detecting and policing.

There are some gaps in the book.  The fact that there are weaknesses,
inaccuracies and misleading statements in the (now infamous) Rimm study/Time
special is dismissed as "not important".  The subtle censorship of Internet
filter software is not discussed.  (One of the filter programs on the
accompanying CD-ROM blocks non-pornography or violence related terms which
are germane only to discussions of certain political leanings.  Filter
developers will not even confirm the dictionary of words used, with some
slight justification.)  Most filter packages do not allow parents to tune or
manage the terms to be included or excluded.

copyright Robert M. Slade, 1996   BKCHSFIN.RVW   961128
roberts@decus.ca           rslade@vcn.bc.ca           rslade@vanisl.decus.ca

Please report problems with the web pages to the maintainer

Top