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 20 Issue 82

Monday 28 February 2000

Contents

o U.S. government abandons Bernstein restrictions
Jeremy Epstein
o How to make friends, influence hackers, and build bugfree code Paris style
Peter Wayner
o Someone making sense about e-commerce
Paul Robinson
o The Millennium Bug Revisited
R A Downes
o It was just a network board...
Debora Weber-Wulff
o Risks of National Weather Service tests
John O Long
o Re: Microsoft responds
R A Downes
o Re: Great West gives out too much personal info
Taylor Hutt
Bob Hofkin
o Imbalanced parentheses or angle brackets
W.T. Shymanski
o "Unstable" postal addresses
Joseph A. Dellinger
o REVIEW: "Security Technologies for the World Wide Web", Rolf Oppliger
Rob Slade
o Info on RISKS (comp.risks)

U.S. government abandons Bernstein restrictions

Jeremy Epstein <jepstein@monumental.com>
Thu, 24 Feb 2000 17:04:37 -0500 (EST)
In light of the new export restrictions, the Commerce Department has
abandoned all claims that Prof. Daniel Bernstein is restricted in posting
his Snuffle encryption source code to his web site, according to a Reuters
article at http://www.wired.com/news/politics/0,1283,34550,00.html .
However, the article says "'We are still considering our options,' said
Cindy Cohn, Bernstein's lawyer. Cohn said the Commerce Department letter
failed to clear up some questions about the new rules." [See PGN note below.]

--Jeremy

  [The *Wall Street Journal* 25 Feb 2000 noted that the residual questions
  are on areas of ambiguity such as mirror sites and a restriction on access
  in countries suspected of supporting terrorism.  PGN
    http://interactive.wsj.com/articles/SB951422940442620073.htm]


How to make friends, influence hackers, and build bugfree code Paris style

Peter Wayner <pcw@flyzone.com>
Sat, 26 Feb 2000 10:36:22 -0500
The *Times* (London) reported on 26 Feb 2000 that Serge Humpich, a hacker,
was convicted of fraud and given a suspended sentence. The young man
discovered how to trick the Carte Bleue system and claimed he could have
gone on an unlimited spending spree. Instead he hired lawyers and negotiated
with the company that runs the system for payment in return for detailing
the problems. The company turned around and prosecuted him for fraud after
they arranged for him to demonstrate the system.

What a brilliant way to discourage folks from rooting around in a system
_and_ reporting security flaws! I wouldn't be surprised if their system
proves to be so impervious that the number of bug reports drop to zero. What
a wonderful solution for creating bugfree code!


Someone making sense about e-commerce

Paul Robinson <Rfc1394a@aol.com>
Wed, 23 Feb 2000 08:45:03 EST
When we think about the risks of technology, we often think about the risks
to life and property.  But the risks of technology are caused because people
don't think about the possible consequences of relying on technology.
Sometimes it does good but if you don't know when technology isn't the
solution you're taking a big risk.

In the following link, the CEO of Liz Claiborne, Paul Charron, explains why
he's not jumping whole hog into Internet sales.  It's a breath of fresh air
in the otherwise rarefied atmosphere of the e-commerce market to hear from
someone who has seriously thought about what he's doing: 
http://www.computerworld.com/home/print.nsf/CWFlash/000221EDB2

It shows that he understands the risks of trying to spend several million
dollars on setting up a web site to sell something when it might not create
profitable returns for 20 years or might merely cannibalize brick-and-mortar
sales.  If a few more people had thought about this, maybe we wouldn't have
an Amazon.Com and 200,000,000,000,000,000 other on-line commerce sites
losing tens of millions of dollars every year.  Okay, so I'm exaggerating
(but not by much).

Has anyone ever thought about the fact that in general, the only web sites
that are consistently making money are the ones dealing in pornography?
This brings new meaning to the term, "obscene profits". :)

Paul Robinson <postmaster@paul.washington.dc.us><A
HREF="http://paul.washington.dc.us"> http://paul.washington.dc.us</A>


The Millennium Bug Revisited

<main@radsoft.net>
Wed, 23 Feb 2000 20:46:11 +0000
Y2K is here and on a roll: things went better than expected; Clinton's
administration is declaring a total victory. The real Millennium Bug -
Windows 2000 - has had much worse luck. Further, it is now apparent that
there are two such bugs: the operating system itself, and the hype campaign
now introduced to get us all to once again jump on the merry bandwagon of
planned obsolescence and upgrade to it.

None other than Paul Thurrott of Windows NT Magazine has declared, after
admitting that a lot of Win2K, such as tooltips that not only "display" as
before, but now "roll in" and "roll out", is "fluff" and no more, that these
supposed enhancements are "good for the end user". It remains a mystery,
however, to both the undersigned and many more, how a rolling tooltip can be
regarded as a substantial end user improvement.

Sanity. Keeping a level mind. Let's remember that the shortest distance
between two points in this case, the distance between what a user wants and
what the operating system does to the hardware, has not increased by one
iota. File operations are still file operations (encryption on disk an
option and not a requirement); video RAM updates are identical; everything
in fact is the same. There is no reason whatsoever for any of these basic
operating system functions to require more hardware - CPU speed, disk space,
RAM - to work. There is no reason for the operating system to exhibit the
extreme sluggishness it does.

"When things get too slow, we just throw more hardware at it." This, the
"Rule of Redmond", obvious everywhere in Redmond code, is especially
prevalent in the code of Windows 2000. And while it is an affront to our
collective human intelligence to expect to be able to sell us on the
assumption that the same operations which ran so fast on previous
versions can suddenly run so agonizingly slow with even twice or four
times the processing power on this one, it is not without our collective
human imagination to understand - or even predict - why and how this
"fluff" - this _junk_ - can have that effect.

When things deteriorate to the point where a major Internet authority
slips into saying that rolling tooltips make matters better for an end
user, then we know we have been hit - by the second of the lethal
Millennium bugs.

Windows 2000 has not at all received the welcome Redmond would want.
Long before its release the Microsoft Windows 2000 Redeployment Program
fell completely apart. ISVs and OEMs and major corporations everywhere,
after seeing the frightening wave of the future with the betas, decided
to jump ship. Polls conducted as recently as days before the official
release of Windows 2000 indicate most of these same corporations
naturally have no inclination whatsoever to upgrade to Win2K and even
less inclination to take it into consideration when writing new
software. So Microsoft has been hard put. And, to make matters worse for
them, a Finn has entered their arena, becoming a nemesis that they fear
more than we can ever really appreciate. Microsoft is not making inroads
in the net server market, and this must hit them hard too, as do
relations with the DOJ in Washington. So under the circumstances,
watching Microsoft do its little propaganda dance, and now do it a bit
more openly and a bit more brazenly than in the past, makes an
interesting study indeed.

Maybe we didn't really notice last time around - if you reckon the inception
of Windows 95 as "last time" - the kind of hype we do today.  Maybe it was
there and we just didn't notice it. But today, most likely because of the
circumstances, it seems to stand out more:

- We're told that this is the best product Microsoft has ever released
(there's a noticeable echo on this one: we've heard it before, and been
gravely disappointed before too - what else can we expect them to say).

- We hear things like "we really love this product". Over and over
again. The power of suggestion, of repeating the "big lie", has become a
weapon in the Redmond camp.

- We're told Win2K runs faster than both 95 and NT 4 on the kind of hardware
running 95 and NT 4 today, when we've all seen that the contrary is true.

- Supposedly independent computer science authorities are heard to mumble
incredible things such as those mentioned above. (Another gem came about in
the wake of the rumour that Win2K has over 60,000 bugs: suddenly these
"authorities" are claiming that none of these bugs will ever be noticeable
by end users).

We know that not all these dupes are on the Microsoft payroll. We don't
assume, to paraphrase Lyndon B. Johnson, that Microsoft has everyone's CPU
in their pocket. But we do see that the cult of mania begun by Microsoft
with the release of Windows 2000 is spreading, and that many individuals who
normally consider themselves sane and level headed are unwittingly acting as
dupes of the International Microsoft Conspiracy of planned obsolescence.

This seems somewhat borne out by the fact that Microsoft even attempted to
keep good old NT 4 away from ISVs involved in their development network
(MSDN). It is borne out by the fact that several key NT applications (such
as File Manager) have been deliberately sabotaged by the Win2K team. And
further evidence of Microsoft's desperation might be upon us before this
letter is even sent.

Let's get this absolutely straight: no one "needs" Win2K. There is nothing
inherent in Win2K that we have been desperately longing for. No advocate of
Win2K can come with a long and impressive list of enhancements that have
been conspicuous in their absence from Windows NT. All we really know is
that Microsoft has decided, as so often in the past, that it is time again
for their "out with the old and in with the new" marketing coup. Even
Intel's claims that Win2K is horrendously slow, so slow that they themselves
need to invest in new hardware for $50 million, must be taken with a grain
of salt. There is no way Microsoft will ever tell us the truth: they were
not going to admit that Windows 95 was a RAM hog and needed four times the
CPU speed and RAM as its predecessor, and they are not going to admit that
Windows 2000 doubles even that multiplication figure. No, they are going to
let us figure this all out by ourselves: the more processors they can help
Intel and others sell the better. Look at Michael Dell: in one breath he
fells a comment about Windows 2000 which sends Microsoft stock plummeting;
in the next he tells of his decision to run his web site with it.

So there's a second bug here all right, almost more dangerous than the first
and a lot more contagious. And there are no known vaccination serums
available.

RA Downes  Radsoft Laboratories  http://www.radsoft.net


It was just a network board... (Re: RISKS-20.75)

Debora Weber-Wulff <weberwu@tfh-berlin.de>
Mon, 28 Feb 2000 13:15:52 +0100
The Berlin Fire Department has found the culprit!  RISKS readers recall the
problems the Berlin Fire Department had starting 4 minutes after midnight on
1 Jan 2000: The dispatching system went awry, believing that fire trucks
were in places they weren't, dropping emergency calls on the floor,
confirming dispatches that never were forwarded, etc, etc.

In anticipation of Leap Day they have been busy testing and testing the
system.  Lo and behold, they can repeat the behavior for 29 Feb 2000.  It
turns out that a handful of network cards, costing about $50 a piece, were
not able to handle either date, and were generating erratic packets.
Replacing the boards has fixed the problem, according to *Der Tagesspiegel*.
[http://www.tagesspiegel.de/archiv/2000/02/24/ak-be-st-32899.html]

The police union criticizes that this system behavior had been observed
before, but no one ever bothered to find the source of the problem.  The
police ended up fighting fires with water cannons instead of the fire
department using all those shiny new fire engines they bought from a German
automotive company after the fire chief was lent a nice car from the same
company.

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin
weberwu@tfh-berlin.de, http://www.tfh-berlin.de/~weberwu/


Risks of National Weather Service tests

<j1long@us.ibm.com>
Mon, 28 Feb 2000 13:12:33 -0500
Today, I was checking the weather on the MyYahoo web page I have created.  I
noticed that there was a red asterisk by the listing for the city I live in.
The red asterisk is denoted as meaning "severe weather alert".  This was
strange, since the forecast summary showed a sun, indicating a clear, sunny
day.  I clicked to get the full weather report, which indicated a normal
sunny day, but a clickable line that said "severe weather alert".  I
clicked on the severe weather alert to find the following:

  ALAMANCE, ANSON, CHATHAM, CUMBERLAND, DAVIDSON, DURHAM, EDGECOMBE,
  FORSYTH, FRANKLIN, GRANVILLE, GUILFORD, HALIFAX, HARNETT, HOKE, JOHNSTON,
  LEE, MONTGOMERY, MOORE, NASH, ORANGE, PERSON, RANDOLPH, RICHMOND, SAMPSON,
  SCOTLAND, STANLEY, VANCE, WAKE, WARREN, WAYNE, WILSON, INCLUDING THE
  CITIES OF BURLINGTON, CHAPEL HILL, DURHAM, FAYETTEVILLE, GOLDSBORO,
  GREENSBORO, RALEIGH, ROCKY MOUNT,

  925 AM EST MON FEB 28 2000

  ...FROM THE NATIONAL WEATHER SERVICE...THIS IS A TEST HIGH WIND WARNING
  ONLY... THIS IS ONLY A TEST.

It would appear that the text scanner that looks for severe weather
announcements is unable to determine when it's only a test.

The risk is probably very small.  However, as more and more people rely on
automated reporting data from various sources, we will find that many of
these sources were not really created for direct pass-through of
information.  Direct, live testing of systems such as the National Weather
Service is important, but unless this is carefully handled by vendors on the
web, we could have a lot more miscues sent to the general public.

John O Long/Raleigh/IBM@IBMUS, j1long@us.ibm.com
Programming Consultant, Solution Architecture and Reuse  919.993.4208


Re: Microsoft responds (Allchin, RISKS-20.80)

<main@radsoft.net>
Tue, 22 Feb 2000 01:20:08 +0000
Tom Sheppard <TSheppard@home.com> writes of a possible 63,000 bugs in
Win2K. Tom is still the Titanic in search for the tip of an iceberg.

The internal rule in Redmond is "4 bugs per KLoC".

Ok. A KLoC is 1000 (or 1,024) lines of code.

Windows NT was only 16 million lines of code. Piece of cake.

But Windows 2000 - without the likes of Cutler, without being a direct copy
of VMS and Prism - is four times that size. Written by people with a
fraction of the talent.

We're talking about 50,000 or 60,000 KLoCS.
Microsoft themselves say 4 bugs per KLoC.
Go figure.

...and I think we must remember that we can never have a debate on the
merits or shortcomings of Windows 2000.  On the one side we have inquisitive
minds authentically attempting to arrive at the truth, on the other we have
the clever minds of those like Alchin who are simply trying to sell a
product by any means.  Windows 2000 will always be the best and most stable
and fastest and most loved product ever.  It will run faster on a Z80 than
CP/M.  We will always really love this product.

RA Downes  Radsoft Laboratories  http://www.radsoft.net


Re: Great West gives out too much personal info (Hutt, RISKS-20.80)

Taylor Hutt <t.hutt@worldnet.att.net>
Fri, 25 Feb 2000 06:24:52 GMT
Last week I submitted a message about Great West giving away too much
information (Name, birthdate, SSN, account number) in a confirmation letter
regarding a change-of-address.

I spoke to the person in charge of the account (Nancy Lynch) and she
indicated that a meeting with management was to be held this week; she would
raise the issues and get back to me.

Well, I'm here to report that she did get back to me and has informed me
that Great West will not be putting the SSN of a person on any
correspondence effective immediately.  Further, they will be doing a
systematic review of all correspondence to determine which information is
actually pertinent to that correspondence.  (She even offered to keep me
up-to-date with their progress on that, but I told her I didn't think that
would be necessary)

I am pleased at the speed which Great West has addressed this situation and
am once again invigorated to believe that it is possible to change the
system.

Hats off to Nancy for carrying through so well on this one.

Taylor Hutt


Re: Great West gives out too much personal info (Hutt, RISKS-20.80)

Bob Hofkin <bhofkin@erols.com>
Sun, 27 Feb 2000 14:46:40 -0500
Taylor Hutt wrote about his 401(k) company mailing out all of his account
identifying information in one letter.

I had a similar problem with Cigna a couple of years ago. They convinced our
HR Person to have them send out letters with lots of personal identifying
information, and a pitch to sign up for their on-line service, Neither the
HR Person nor any of the Cigna reps I spoke with seemed to understand that
anyone who intercepted the letter could commandeer my account. Cigna claimed
the system met their internal security guidelines(!!) and besides, even if
something did go wrong, I would see it on my quarterly statement and they
would be happy to fix any problems.  I can just imagine the phone rep: "Sure
thing, we'll be happy to move that $100,000 right out of the fund that lost
2% and back into the one that made 24%, and of course we'll make that
retroactive.  So sorry to inconvenience you in the least."

Perhaps this is standard procedure in the industry. I was surprised at the
lack of security awareness and the lack of concern. One comment that was no
surprise: "You're the first person who ever complained about this."


Imbalanced parentheses or angle brackets

"W. T. Shymanski" <"nski\" Mon, 21 Feb 2000 19:29:27 -0500
I had the misfortune last week to photocopy a customer request for proposal
document that I needed to work with.  While frantically trying to put the
proposal out before the deadline, I noticed the requirements seemed a little
sketchy in parts; examination of two pages showed that the set of points was
numbered 1,2...big white space at bottom of the page...5,6 on the next page.

It turned out that our digital Pitney-Bowes photocopier had developed a
problem where it would not print the bottom half of a page.  For spreadsheet
pages printed in landscape format the error was quite prominent, since the
left-hand-side of the page was blank.  But for regular portrait-mode text,
it was only because the following page had paragraphs numbered out of
sequence that I even noticed the problem.

The risks are pretty obvious: potentially the difference between profit and
loss on any given contract might hinge on a paragraph at the bottom of a
page, which the digital photocopier might softly and silently eat without
trace.  Normal analog-type photocopiers in my experience don't make *this*
type of foul-up.

Bill Shymanski <wtshyman@mb.sympatico.ca>


"Unstable" postal addresses

"Joseph A. Dellinger" <jdellinger@amoco.com>
Mon, 21 Feb 2000 20:46:49 -0600 (CST)
My street address has a letter on the end to make it unique: "123D Memorial
Street". This works fine for mail delivery, it's what is engraved on the
mail boxes, and is more concise than "123 Memorial Street Apartment D", so
when I moved in "123D" is what I handed out as my new address.

Big mistake! While that address will work for a while (months), eventually
the businesses whose job it is to mail out magazines, notices, offers, etc,
will run clever software over their databases to "correct mangled
addresses". When that happens, the "D" on the end gets deleted as an
"error", or (worse) changed into a "0". While mail addressed to "1230"
usually arrives, when presented with an address of "123" and a row of letter
boxes marked "123A", "123B", "123C", "123D", ...  the mail carrier will
often just pick a random box to deliver the mail to.

This took a while to figure out. All I knew was that the amount of mail I
was getting seemed to be exponentially decaying. Calling up the magazines to
ask "are you sure you still have my address correct?" didn't work: in their
databases the "D" is invariably still there.

Eventually some of my own mail without the "D" ended up arriving in my box,
so I was able to figure out what was happening. So now I have to call up
everyone sending me mail and change my address to put the "Apartment D" on a
separate line, where it is apparently stable. Even so I bet my neighbors
will be getting all sorts of junk mail meant for me for months to come.

The risks?

Software that is overly aggressive in "fixing" addresses.

The address the subscription services people see in their computer is not
the same as the one that is actually used (and they don't even realize it's
not the same).

No error message being returned by the post office saying that the address
without the letter _can_ be delivered, but not _reliably_.

Purging all the "123 no D" addresses now existing in hundreds of databases
out there will be just about impossible.


REVIEW: "Security Technologies for the World Wide Web", Rolf Oppliger

Rob Slade <rslade@sprint.ca>
Tue, 22 Feb 2000 10:49:32 -0800
BKSCTCWW.RVW   20000113

"Security Technologies for the World Wide Web", Rolf Oppliger, 2000,
     1-58053-045-1
%A   Rolf Oppliger rolf.oppliger@acm.org,oppliger@computer.org
%C   685 Canton St., Norwood, MA   02062
%D   2000
%G   1-58053-045-1
%I   Artech House/Horizon
%O   800-225-9977 fax: 617-769-6334 artech@artech-house.com
%P   419 p.
%T   "Security Technologies for the World Wide Web"

In the preface, the author states that the book is first intended for
Webmasters, who need practical configuration information, then for users who
have security concerns, and finally for Web and electronic commerce
developers.  He also says that the book can be used as an introduction, for
self-study, as a course text, and as a reference.  A pretty tall order, but,
by and large, Oppliger does a reasonable job of fulfilling the entire
mandate.

Chapter one, as an introduction, is possibly more than most people want to
know.  However, the extra information (such as the explanation of HTTP
[HyperText Transfer Protocol] requests and responses) does help provide an
understanding of the underlying actions and concepts which are needed for a
thorough view of security operations and requirements.  There is a detailed
presentation of HTTP access control methods in chapter two.  The
introduction to firewalls, in chapter three, is complete and helpful, with a
wealth of user level information that is all too often omitted.  Chapter
four is a solid introduction to the basics of cryptography.  Channel
security at the data link, transfer, and application layers is the theme of
chapter five, touching on tunneling, VPNs (Virtual Private Networks), IPsec,
and various application protocols.  Chapter six expands two of these with
details on the Secure Sockets Layer (SSL) and Transport Layer Security
(TLS).

Chapter seven gives an overview of electronic payment systems, with brief
descriptions of the most common electronic cash, debit, and credit schemes.
The management of certificates, in chapter eight, mostly covers ongoing work
in key infrastructure, with a good discussion of the important and difficult
question of certificate revocation.  A fair and realistic review of active
content is provided in chapter nine.  For slightly less active content,
chapter ten discusses and shows examples of more secure practices for CGI
(Common Gateway Interface) and API (Application Programming Interface) work.
Mobile code and agents are still really future technology, and so are the
proposed security functions in Chapter eleven.  The copyright discussion in
chapter twelve is a little disappointing, since it seems primarily concerned
with watermarking.  Chapter thirteen looks at privacy, being dealt with by
amateurs as usual, and, as usual, providing glimpses of fascinating work
that is not widely known.  There is a brief overview of censorship systems
and problems in chapter fourteen.  Chapter fifteen concludes with a somewhat
pessimistic review of the situation.

The bibliographies at the end of every chapter contain solid works, and can
be useful to those wanting further information.  They do, however, have a
very definite academic flavour, in that most of the entries are articles or
conference presentations, with books and online references making up a
smaller portion of the whole.

Oppliger's writing is rather dry and academic in tone, but the material
presented is realistic, useful, and conceptually complete.  Despite the
disparate audience range, the author has managed to provide something of
value for all.  For the Web workers who are the primary audience, this book
provides, if not a cookbook for security, a complete picture of the various
aspects that must be addressed.

copyright Robert M. Slade, 2000   BKSCTCWW.RVW   20000113
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top