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 92

Tuesday 18 August 1998


o Computer flaw makes water undrinkable
David Ratner
o The Bloatware Debate
o Y2K: Warehousing systems
David Alan Gilbert
o L.A. school district accused of software piracy
o Cryptanalysis of Frog, an AES Candidate
Bruce Schneier
o A legal way to export crypto code: in English
Jay Ball
o Risks of agents
Paul van Keep
o Geocities: privacy, promises, and regulation
o Tracking activity on the Web
o Microsoft self-extracting files risks
Conrad W. Clark
o Re: Win98 H24 problem, not Yx
Scot E. Wilcoxon
o Re: Global War[m|n|p|r]ing?
Aaron M. Renn
Scot E. Wilcoxon
o Re: Software flaw exposes e-mail programs ...
Andrew Koenig
o Re: Unix passwords no longer safe
Eric Maiwald
Simon Waters
o Re: USS Yorktown: WinNT --not?-- the fault
Mike Williams
Victor Yodaiken
Fred Cohen
o Re: Yorktown dead in water after divide by 0
Henry Spencer
o Info on RISKS (comp.risks)

Computer flaw makes water undrinkable

David Ratner <>
Mon, 17 Aug 1998 13:13:00 -0700
A computer glitch in Lewiston, Maine, shut down the chlorination system and
caused the chlorine content of the city water to drop below the safety
threshold, affecting 40,000 residents.  This occurred during the night, and
was not discovered until a routine check 14 hours later.  Notices were then
sent out to 9,000 homes advising people ``to boil the water before
drinking.''  It took 30 hours to solve the problem.  The city has now
installed an automatic system to notify an on-call supervisor in case this
recurs.  [Source: *USA Today*, Tech Report, Glitches of the Week, updated 17
Aug 1998, <>; PGN Abstracting]

How many other computer systems that require 24x7 service don't have 24x7

David Ratner, Software.Com, Inc. 805-957-1790 x629

The Bloatware Debate

Edupage Editors <>
Thu, 13 Aug 1998 13:09:11 -0400
A 100-company survey by Standish Group International found that 45% of a
software application's features are never used, 19% rarely used, 16 %
sometime used, 13% often used, and 7% always used; yet, in spite of the fact
that most of an application is seldom used, software gets bigger all the
time.  For example, Windows went from 3M lines of code (Windows 3.1) to 14M
lines (Windows 95) to 18M (Windows 98).  Booze, Allen & Hamilton chief
information officer Roger Walters is one of the people complaining now about
this "bloatware" phenomenon: "My problem is, I'm forced to upgrade all the
time -- not for functionality I want, but for features someone wanted for
me."  But industry analyst Jeffrey Tarter defends the software makers by
noting: "I can't think of a single lite version of any product that has ever
succeeded.  It may be inelegant and sluglike, but bloatware sells."
(*Computerworld*, 10 Aug 1998; Edupage, 13 August 1998)

  [The corporate motto must be ``Don't rock the bloat.''?  PGN]

    [Incidentally we are very grateful to John Gehl and Suzanne Douglas
    for their efforts in producing Edupage.  To subscribe to Edupage
    directly rather than relying on RISKS to cull a few RISK-relevant items,
    send e-mail to with the message:
      subscribe edupage 

Y2K: Warehousing systems

David Alan Gilbert <>
Mon, 17 Aug 1998 10:07:26 +0100
One UK Sunday paper carried an article yesterday saying that a major
supermarket had sent an entire consignment of corned beef to be skipped
because a non-Y2K warehousing system had decided that its expiry date of
something like 2001 was actually 1901 and it was about time that it was

Dr. David Alan Gilbert, dg @        - +44-(0)161-428-9444
Home: gro.gilbert @

  [RISKS-6.43 had a meaty case of the Xtra supermarket being meted out a
  $1000 fine for having meat on the rack an extra day, as the result of
  a computer program mishandling the labels over the 1988 leap day.  PGN]

L.A. school district accused of software piracy

Edupage Editors <>
Thu, 13 Aug 1998 13:09:11 -0400
It may cost the Los Angeles Unified School District as much as $5 million to
amend for the software piracy accusations brought by the Business Software
Alliance against an adult vocational school under the district's
jurisdiction.  The Business Software Alliance says it found 1,400 copies of
unlicensed software at the school, including copies of Microsoft Word and
Adobe Word.  The business group wants the school district to replace the
pirated copies with licensed ones.  One educational technology consultant,
Jamieson A. McKensie, thinks the piracy problem is widespread in schools:
"In many places, people think 'the software is for kids; it's a good cause
and there's nothing illegal about it.'"  Microsoft spokeswoman Sarah B.
Alexander says the problem is that often people who would not dream of
stealing other things believe it's legitimate to use software without paying
for it:  "How do they justify it?  Just because it's easier to make a copy
of software than a desk or a book."  (*The New York Times*, 12 Aug 1998;
Edupage, 13 August 1998)

Cryptanalysis of Frog, an AES Candidate

Bruce Schneier <>
Sun, 16 Aug 1998 17:39:44 GMT
Results Announcement:
D. Wagner, N. Ferguson, and B. Schneier, "Cryptanalysis of Frog,"
Counterpane Systems Report, Aug 1998.


We examine some attacks on the FROG cipher.  First we give a differential
attack which uses about $2^{58}$ chosen plaintexts and very little time for
the analysis; it works for about $2^{-33.0}$ of the keyspace.  Then we
describe a linear attack which uses $2^{56}$ known texts and works for
$2^{-31.8}$ of the keyspace.  The linear attack can also be converted to a
ciphertext-only attack using $2^{64}$ known ciphertexts.  Also, the
decryption function of FROG is a lot weaker than the encryption function.
We show a differential attack on the decryption function that requires
$2^{36}$ chosen ciphertexts and works on $2^{-29.3}$ of the keyspace.  Using
our best attack an attacker with a sufficient number of cryptanalytical
targets can expect to recover his first key after $2^{56.7}$ work.  Taken
together, these observations suggest that FROG is not a very strong
candidate for the AES.

This paper is available at, and will
be made available at the AES Workshop next week.


  [That is, it SHOULD NOT BE a strong candidate, assuming strong crypto is
  really the desideratum.  Bruce's message once again reminds us how
  important extensive scrutiny is when it comes to cryptography!  PGN]

A legal way to export crypto code: in English

jay ball <>
Sat, 15 Aug 1998 15:10:35 -0400
"Judge Gwin of the Federal District Court of the Northern District of Ohio
has recently held that software is not protected by the First Amendment
because it is a ``functional device'' like a telephone circuit." as said by
Peter Junger, a lawyer suing for the fight to export crypto as

So, Leevi Marttila has written a program that translates C to English and
back. is the location of the program.
Now, the question is, is this translation free speech?  You can read
blowfish at and see that it
quite readable as a story, even funny if you remember that it came from C
code.  So, are the adventures of William, Edward, Richard, Michael, &
Charles free speech?  If so, you can export it?

Or, are the adventures themselves an encrypted message and the translator a
piece of crypto software?

Jay Ball

Risks of agents

Paul van Keep <>
Fri, 14 Aug 1998 13:08:39 ECT
This abstract was forwarded to me and seems very appropriate for risks.

 > 98-612 WHY THE WIRED ECONOMY IS DOOMED --agents without a conscience
 > [From New Scientist, 4 July 1998--Walter Derzko]
 > Intelligent software agents that don't care about the consequences of their
 > actions will subject the world to frequent and severe bouts of boom and
 > bust,  according to two research groups in the US. As we use the Internet
 > more and more for home shopping and banking, the use of agents to get
 > us the best prices  will lead to economic turmoil.

The experiments seem to indicate that delays (friction) are an essential
part of an efficient economic model. For instance: if we'd manage to remove
all friction from stock market trading, i.e. everyone trades on the basis of
the same information at the same time, the whole thing would come crashing
down or at least start swinging madly up and down.

Paul van Keep

Geocities: privacy, promises, and regulation

"Peter G. Neumann" <>
Mon, 17 Aug 98 14:27:02 PDT
The Federal Trade Commission is finally beginning to confront the privacy
problem.  It has charged Geocities with misleading its 2 million customers
by secretly selling their personal information to marketers, despite the
previously professed policy of not doing so without permission.  In
response, Geocities has now posted on its Web site what is presumed to be
its actually practiced privacy policy.  [Source: Reuters item, 14 Aug 1998]

As long-time RISKS readers well understand, this is an area in which
vigilance and aggressive action are very important.  As usual in matters
relating to your identity, CAVEAT EMPTOR!

Tracking activity on the Web

Edupage Editors <>
Sun, 16 Aug 1998 19:24:54 -0400
Lycos, Geocities, and NBC's Videoseekers are among the major Web sites that
will participate in a new service, called Engage, that was developed to
track what people are looking at on the Internet, so that advertisers can
target their marketing efforts.  David S. Wetherell, the chief executive of
CMG Information Services, the company behind Engage, gives this example of
how the service would be used: "If someone comes to your bookstore for the
first time, you can find out if they are interested in mountain climbing,
organic gardening and tennis; you can present them books related to their
interests immediately."  Mr. Wetherell adds: "We took the highest road you
could possibly take with respect to privacy.  We think you can learn a lot
more about someone from their behavior than from their name and address."
The system will keep information on age, sex, income, zip code and number of
children; it will not collect information on sexual or health related topics
and will not store individual names, addresses, and birthdays.  Privacy
consultant Jason Catlett says: "Engage has done many good things to protect
privacy, but my worry is that they are firing the starting gun in the race
for the bottom.  The worst actors will be left to use the most sophisticated
surveillance techniques as they please."  (*The New York Times*, 16 Aug
1998; Edupage, 16 August 1998)

Microsoft self-extracting files risks

"Conrad W. Clark" <>
Fri, 14 Aug 1998 21:07:21 +0300
Here's the scenario:

I need the new perl for Win32 (Activeperl 5xx)
It requires an update to Win 95 for the DCOM components to 1.2.
I download the file from the Microsoft site, and the file is advertised as
(as I recall) 1.4 meg.
I receive a 764K file, but my browser (Opera 3.2) marked it as completely
It's a self-extracting file to update DCOM (it says so itself), so I
execute it.
It executes!
The Typical forms (do you want to install this - really, and licensing
text) come up, with English heading, except that the contents are garbage.
I click yes anyway, since I'm in physically in an Eastern European country
at this time I figured "Bob" or some other "wizard" had intervened to help
me by munging the fonts.
The installer couldn't find any space on my drive.
I had space on my drive.

So this file is bad.  Don't self extracting files have checksums????  Don't
they check themselves???? I know PKZIP and WINZIP do.

It gets better.

I next try to download the same file from an official MS mirror site in
Sweden.  All of the mirror sites list the file at 3.5MB.  Being foolhardy,
and having backups on a Jaz drive I downloaded it again.  It is 1.200 MB!
It executed and installed.  Perl (which I trust) says so.

So Microsoft downloads DO NOT:

 * Perform file integrity checks before executing.
 * Have reliable information as to file size.
 * Certainly are not validated with digital signatures or other "way
   advanced" stuff.


I have the original corrupted file (my path e:/barf/dcom95.exe).  If
Microsoft isn't interested that's another risk altogether.


Re: Win98 H24 problem, not Yx (RISKS-19.91)

"Scot E. Wilcoxon" <>
Mon, 17 Aug 1998 22:40:30 -0500
At about the same time that my alert appeared in RISKS-19.91, Microsoft and
others confirmed Windows 98 has a problem with midnight incorrectly altering
the date.  Further testing found that the problem actually occurs when
midnight occurs during Win98 start up.  There is about a five-second window
for the problem during a midnight boot.

As the problem can happen any day, this is not a Year 2000 problem.
Microsoft estimates this only affects about one in five or six million users.

Re: Global War[m|n|p|r]ing?

"Aaron M. Renn" <>
Thu, 13 Aug 1998 16:23:32 -0400 (EDT)
You may be interested in knowing that Wentz and Schabel's corrections (of
satellite records showing a global cooling trend) required some corrections.
They did not take into account the east-west orbital drift of the
satellites, only orbital decay.  Also, they applied an average orbital decay
value to all satellites instead of making a precise adjustment for each
satellite when calculating their figures.  The satellite researchers at NASA
applied the corrected corrections to their data and still show a slight
downward temperature drift.  An overview of the results are available at:

This page also mentions the fact that weather balloon data corroborates the
satellite information, something the original posting omitted.

The global warming phenomenon is by no means universally accepted by
science, despite claims of "rampant evidence".  The use of ozone layer
results to discredit satellite cooling data is a logical fallacy which adds
no hard evidence to support the global warming theory.  A somewhat stronger
form of that paragraph's thesis might have read "global cooling and ozone
depletion data are both collected from satellites. The ozone depletion data
was wrong, therefore the global cooling data is wrong".  This is a false
analogy.  If valid, it would impinge on _any_ scientific research because
virtually all methods of data collection have had errors in the past.  Also,
use of the term "faith" implies that those who believe the satellite cooling
data are engaging in a religious instead of a scientific belief.  The use of
such loaded words is a well known propaganda technique.

The risk?  Logical fallacies or propaganda are often employed in debate,
even over scientific issues.  One should be careful to analyze all arguments
to discover them.

To learn more about logical fallacies, I suggest Stephen's Downes' guide to
logical fallacies at:

To learn more about techniques of propaganda, see Aaron Delwiche's
propaganda page at:

Aaron M. Renn <>

Re: Global War[m|n|p|r]ing?

"Scot E. Wilcoxon" <>
Tue, 18 Aug 1998 08:27:06 -0500 (CDT)
In RISKS-19.91, PGN pointed out the study in *Nature* that reported the
realization that orbital decay caused global temperatures to be calculated
as being slightly cooler than actual temperatures.

The scientists operating the global temperature satellite experiment have
thanked the author of the *Nature* article for pointing out this geometry
problem.  They also pointed out that the *Nature* article gave an estimated
temperature based on an average of all eight satellites rather than being
calculated for each individual satellite, and there were two other effects
due to an east-west drift which could now be quantified.  The adjusted
global temperature change for 79-97 is now a cooling of 0.01 degrees C per

Scot E. Wilcoxon

Re: Software flaw exposes e-mail programs ... (Haahr, RISKS-19.90)

Andrew Koenig <>
Thu, 13 Aug 1998 16:28:31 -0400 (EDT)
> What all the reports I've read appear to be missing is that bugs like this
> are almost inevitable in C or C++, [...]

Here, ``bugs like this'' refers to overflowing static buffers.  Such bugs
are *not* inevitable in C++ programs.  Class libraries have been available
for a decade or so that make it easy to write C++ programs that do not have
any fixed upper bounds on buffer sizes.

What I find remarkable is that in all that time, more programmers have not
started using such libraries as a matter of course.  But then I also find it
remarkable how many drivers do not wear seat belts.

I don't think, though, that drivers' failure to wear seat belts is an
acceptable argument against the use of automobiles.  Nor do I think that
programmers' failure to use the tools that are available in one language is
an acceptable reason to argue for switching to another.

Andrew Koenig <>

Re: Unix passwords no longer safe (Ishikawa, RISKS-19.91)

Thu, 13 Aug 98 18:59:41 EDT
> Now we can target the root account for compromise attempt.

I think we have already passed this point.  I did a recent test against
Windows NT passwords using L0phtCrack running on a Pentium II 200MHz.  We
were able to do an exhaustive attempt against all 8 letter passwords in 32
hours and an exhaustive attempt against all 8 letter + number passwords in
310 hours.  That is not targeting a single password but going over the whole
SAM file.

>  It is time to retire [fixed passwords].  PGN]

I began making this point to my clients as well.  My point is just that no
matter what your security policy requires regarding passwords (8, 10, 12
characters), if I can get your password file I own you.

It is not now (and never has been) appropriate to rely on a single
protection mechanism.  Hopefully this is finally dawning on the world at

Eric Maiwald, CISSP, Director Security Services, Fortrex Technologies, Inc.
North Potomac, MD  301-977-6966

Re: Unix passwords no longer safe (Ishikawa, RISKS-19.91)

"Simon Waters" <>
Thu, 13 Aug 1998 21:05:54 +0100
>Crack is meant to plug such holes.

Readers might gain the impression that Crack is intended to be used to
reveal weak passwords and improve security as a result.

Whilst it certainly can be used like that the advice given by Mr Muffet (at
least in version 4) was to take other measures to improve UNIX password
security. The risk being someone else with a better dictionary or more
computer time will break the weak passwords first and compromise the system.

Anyone thinking of running Crack would be well advised to read the
accompanying documentation.

Re: USS Yorktown: WinNT --not?-- the fault (Fraser, RISKS-19.90)

"Mike Williams" <>
Fri, 14 Aug 1998 12:07:06 +0100
Having had to work with fp exceptions recently there are some interesting
implications that can be read from this story.

First, it is possible to make some assumptions on the hardware used to host
the system.  I would guess that the NT system is most likely either an Intel
or Alpha system since MIPs and PPC are no longer in the picture.  The Intel
FPU by default masks all fp exceptions, such as divide by zero, so the
program does not crash and can continue with close to expected results.  In
contrast the Alpha FPU does not mask fp exceptions by default and the same
program that would continue on Intel will come to a grinding halt on the
first divide by zero.

Next, it is possible to have some ideas about the development of the system
that crashed.  In the development of any system it can be very useful to
have fp exceptions unmasked as they can be useful in catching 'extreme' fp
calculations (sqrt of a -ve number, etc.) due to logic bugs as well as
straight compiler bugs (fairly esoteric but seen).  However, for a full
release you would either mask the exceptions to prevent the crash, or
install an exception handler for each exception not masked.  This would be
true for Intel or Alpha hardware.

So, if it was NT that blue screened for division by zero bad karma to MS for
releasing an OS that neither masks or handles such exceptions.
Alternatively, the hosted application while not screening a 0.0 before a
division (slapped wrists) also had unmasked exceptions for whatever reason
in its release version.

Personally, and for no particular reason except I got caught by this once, I
think it is a mixed mode failure.  I would guess that the application was
originally developed and tested on Intel machines with the default fp
exception masking, but that the delivered release version was ported (read
re-compiled) to an Alpha machine with no fp masking by default.  Cue crash
on first fp divide by zero.

Masking fp exceptions and taking the solutions the FPU provides (such as
infinity arithmetic) is not portable, the Intel and Alpha FPUs can have
different masked exception solutions.  IIRC the Alpha returns a 0.0 while
Intel returns 1.INF (an signed infinity).  Life can get interesting when you
do a magnitude check on the result of the expression.

The risk?  Assuming all NT machine environments are the same when developing
for them.

Mike Williams, Harlequin Group plc, Wilmslow Road, Alderley Edge,
Cheshire SK9 7QD  (+44/0) 1625 588010/588049

Re: USS Yorktown: WinNT --not?-- the fault (Myers, RISKS-19.91)

14 Aug 1998 04:01:06 GMT
I'm amazed at the number of terrible technical decisions that are now driven
by MS marketing -- or more correctly -- herd purchasing.  The Navy basing
ship control (and future battlefield command and control) on NT is perhaps
the most outrageous, example, but this phenomenon is pervasive. In the last
3 months:

1. A famous research lab I won't name is building a major  NT based cluster
   despite the known low MTB-BSD numbers (mean time between blue screen of
   death) that will most likely keep the machine from ever running.
2. A  systems architect  at a European bank explained to me that his
   managers repeatedly disregard costing analysis in requiring NT based
3. A researcher in real-time systems told me that he was interested
   in working with our group, but we had to port our work to NT because his
   government funding agency required all "deliverables" in NT.
4. Our state universities are purchasing a student information database and,
   I'm told, there is considerable pressure to adopt an in development
   NT solution over existing, known to be reliable, alternatives.

It's remarkable to see what should be extremely conservative and cost
conscious institutions making the decision to place their hopes on untested
application software that will run on a undelivered OS (NT 5) promised by a
company with a track record of delivering buggy operating systems.  At least
when IBM dominated corporate/government purchasing it was a safe choice.

Re: USS Yorktown: WinNT --not?-- the fault (Ward, RISKS-19.91)

Fred Cohen <>
Sat, 15 Aug 1998 14:17:07 -0700 (PDT)
Shifting the blame does not end there. For example, the day the e-mail
overflow affecting Microsoft and Netscape systems was widely published in
the national news, Microsoft announced a 'fix' which made the news while
Netscape said it would take a week. The 'fix' identified by Microsoft,
however, was not to that bug. It was to a different bug.

Shifty business indeed.  Fred Cohen,
Fred Cohen & Associates: - - tel/fax:925-454-0171

Re: Yorktown dead in water after divide by 0 (Bradshaw, RISKS-19.89)

Henry Spencer <>
Mon, 17 Aug 1998 12:11:12 -0400 (EDT)
>The Yorktown problems are particularly worrying because they're very
>reminiscent of problems the British navy suffered a hundred years or so ago.

Unfortunately, the basic thinking of the US military today is very prone to
this sort of problem.  One of the defense-reform advocates (Spinney, I
think, but the particular book isn't handy to check) has observed that much
of the apparent irrationality of US military technology procurement in
recent times can be explained as the result of three unwritten basic
assumptions, all of which are badly flawed.  The third assumption is roughly
"modern warfare is fundamentally a predictable, orderly process which is
amenable to centralized planning and control".

(Since I suppose folks will ask :-), the first two are "technology has
changed everything, so the lessons of the past no longer apply" and "numbers
and weapon lethality are the only factors which significantly influence the
outcomes of battles".)

Predictable, orderly processes don't need decentralized emergency backups
and underlings trained to take the initiative when needed.  Such a
conclusion is obviously ridiculous in warfare... but unwritten assumptions
are much the most insidious kind, because they creep into system designs
without anyone realizing it.

> People need to be trained in the use of those backup systems [...]

As has been noted in connection with airliners, there is a difficult problem
of keeping the operators skilled in manual control when they seldom exercise
it in normal operation.  It might be better to make partially-manual control
the norm, and reserve full automation as the emergency backup.

(I believe I've seen mention of experimental automated systems for
space-shuttle plumbing which plan actions but delegate execution to humans,
on the grounds that it's the only way to keep the humans current on what's
happening so that they can take over quickly if necessary.)

Henry Spencer   (

Please report problems with the web pages to the maintainer