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 83

Tuesday 23 June 1998

Contents

o Recent RISKS subscriber problem
PGN
o ISPs not liable for actions of subscribers
Edupage
o Expectations of technology
Chip Seymour
o Software Piracy Battle Heats Up
Edupage
o Arizona Lottery Pick 3 random number bug
Alan Hamilton
o GPS - one they didn't think of
Ian Cargill
o ISP Security fiasco
Paul van Keep
o Social security numbers on-line
John W. Lewellen
o New virus posts user documents to public newsgroups
Mikko Hypponen
o Anonymous call rejection
Edupage
o Shuttle imaging Y2K problem?
Daniel A. Graifer
o More on @#$%& software
Phil Agre
o Re: Exchange/Outlook plug-in for PGP ...
Curt Sampson
o Re: German high-speed train disaster
Peter da Silva
o Re: Fire risks compounded by loss of ... power
Eric Roesinger
David Kipping
o Re: Severed MCI cable cripples the Net
Seth Breidbart
o Social Engineering free long distance
Max Stevens
o REVIEW: "Web Security and Commerce", Simson Garfinkel/Gene Spafford
Rob Slade
o Info on RISKS (comp.risks)

Recent RISKS subscriber problem

<PGN>
Mon, 22 Jun 1998
Due to a Majordomo configuration glitch, all new subscriptions between last
Friday afternoon and Monday morning went into a BLACK HOLE.  Sadly, the
folks who need to know about this probably won't see this until they get
tired of waiting and try again -- if they ever scan the archives.  SORRY!


ISPs not liable for actions of subscribers

Edupage Editors <educom@educom.unc.edu>
Tue, 23 Jun 1998 12:46:03 -0400
The Supreme Court has let stand a lower court ruling that frees Internet
service providers such as America Online from legal liability for
information one subscriber circulates to millions of others. The appeals
court said that federal law "plainly immunizes computer service providers
like AOL from liability for information that originates with third parties."
The case is Zeran vs. America Online, 97-1488.  (*San Jose Mercury News*, 22
Jun 1998; Edupage 23 June 1998)


Expectations of technology

Chip Seymour <cseymour@mail11.mitre.org>
Mon, 22 Jun 98 16:37:18 -0400
We have wittingly fallen victim to a behavior modification problem that has
resulted from the way we think technology works (or should work).  Or,
perhaps the way we FAIL to think about it.  Either way, it appears to be
life threatening.

Two cases in point:

Last week, a smoky fire broke out in the basement of a Chase Manhattan
Bank building on Wall Street.  People working on the 22nd floor of the
building noticed the "lights started to flicker and then the phones
went dead, but the computers were still working."

Apparently the company's UPS kicked in, allowing the computers to remain
functional.  However, a person's perception of a power failure is that
either everything stays on (power) or everything shuts down (failure).

The failure of the lights and phones would lead one to believe the power
has been lost.  However, the computers continued to run, leading the
people to confusion. "We all looked at each other because we couldn't
figure out what the heck was going on."

They remained at the helm for another 20 minutes before someone smelled
smoke.  Then a person from another part of the building warned them to
leave.  At the end, thirteen people were injured.

The second case involves a horrible traffic accident where the driver
and passenger were injured and pinned in a flaming vehicle.  A witness
dialed 911 on his cellular phone.

U.S. residents "all know" that 911 is the number to call to request
emergency equipment.  What we don't "all know" is that cellular calls
to 911 do not automatically provide an Automatic Location Identifier
to emergency responders (although a few 911 cell ALI systems have sprouted
since this accident happened).

In Massachusetts, where this accident happened, all cellular 911 calls
are routed to one of two State Police barracks, then are transferred to
the responding agency.  This 911 call was answered 50 miles away.

The witness was fairly spun up because of the immediate danger to the
accident victims.  Due to his excitement, the 911 operator had difficulty
understanding the caller, resulting in a delayed response.  The victims
were finally extricated, treated at a local hospital (multiple fractures,
burns, sucking chest wound), and eventually released.

The risk here is that the witness couldn't fathom that the 911 call
wasn't sent to the closest 911 Public Safety Answering Point, and that
the 911 operator had no indication of the accident location.  He expected
technology to work the way he *thought* it should work.

The public at large seems to have a notion that technology will always
perform in the manner perceived, with little notion of how that
perception is developed.  I suspect, in our frantic pursuit of the
newest and fastest whozywatts, this will be the case for a while, and
it's our fault.

Chip Seymour <cseymour@mitre.org>


Software Piracy Battle Heats Up

Edupage Editors <educom@educom.unc.edu>
Sun, 21 Jun 1998 12:33:47 -0400
A report released earlier this week by the Software Publishers Association
and the Business Software Alliance shows the industry lost $11.4 billion to
pirates who produce illegal copies of software.  SPA now acknowledges that
its strategy of settling infractions with a fine and a confidentiality
agreement has not been very successful, and vows to begin pressing charges
and publicizing the names of offenders.  "I don't like doing that, but it
serves as an education to companies in a similar situation," says the SPA's
director of anti-piracy efforts.  "If they want to keep ripping off our
members, why should we treat them nicely?"  Some areas have shown
improvement -- Europe, which had a piracy rate of 90% five years ago, is now
down to 50% -- still, that's almost twice as high as the U.S., which is 27%.
(TechWeb 19 Jun 1998: Edupage, 21 June 1998)


Arizona Lottery Pick 3 random number bug

Alan Hamilton <alanh@primenet.com>
20 Jun 1998 23:40:01 -0700
The Arizona Lottery suspended its new Pick 3 game when they discovered that
the computer selecting the winning numbers never picked 9
(http://www.arizonalottery.com/new/pick3faq.html).  The Pick 3 game had
players select three numbers, 0-9.  Why do I have a sneaking suspicion that
their code probably looked like INT(RND * 9)?

The lottery is offering refunds to players that had played 9, but they have
to still have their losing tickets.  I suspect that most players threw away
their tickets when they lost.

The lottery plans to reintroduce the Pick 3 game, using a ping-pong ball
machine (as its other games use) rather than a computer.

If a simple bug like this slipped through, I'd have to wonder about the
robustness of their random number generator, which would be another risk.

Alan Hamilton <alanh@primenet.com>


GPS - one they didn't think of

Ian Cargill <ian@soliton.demon.co.uk>
Tue, 23 Jun 1998 21:48:50 +0100
There has been quite a bit of discussion on comp.risks lately about the
various risks associated with relying on GPS systems.  I read about another
one today that not many people will have thought of.  (Daily Telegraph, June
23, 1998)

When a body weighed with an anchor was caught in a fishing boat's nets,
police launched a murder investigation.  After identifying the body (by the
maintenance records for the Rolex Oyster Perpetual Date Chronometer it was
wearing!), their invesigations uncovered a man who had stolen the victims
identity and allegedly murdered him to prevent it being discovered.

The nice bit is that they found the GPS navigation unit for his yacht in his
garage.  The GPS route history showed that he had been close to the area
where the body was found just about the time that it was believed to have
been dumped!  After that, it was all downhill...

He should have dumped the GPS, too.

Ian Cargill  CEng MIEE  Soliton Software Ltd.


ISP security fiasco

Paul van Keep <pvk@acm.org>
Tue, 23 Jun 1998 10:36:26 ECT
WorldOnline, one of the large dutch ISP has suffered a number of security
failures recently. These were mainly attributable to human error and weak OS
level security measures. The most prominent mistake was to assign passwords
to users by using a combination of the first four letters of their userid
and a 4 digit code. I even doubt that the 4 digit code is randomly chosen
but even if it is, cracking an account with this knowledge is pretty easy
and straightforward.  In an attempt at damage control, WorldOnline last week
stated that it's system is secure and that users should not worry, although
they do not feel responsible for breakins on websites that they host. To
prove their point and to get some positive publicity, they even launched a
competition with a prize of $7400 for the first reproducible crack. The
prize was claimed within a few days by a cracker who managed to extract
thousands of private e-mails from a mail server.  Another team cried foul
because the system they had hacked into (running the internal helpdesk) had
been abruptly switched off in an attempt to stop the crackers.  The dutch
provider association (NLIP) has denounced the competition as a cheap
publicity stunt.

Paul van Keep


Social security numbers on-line

"John W. Lewellen" <Lewellen@aps.anl.gov>
Tue, 23 Jun 1998 10:27:07 -0500
I found this little gem today while searching for something completely
unrelated.

A person had listed, on his on-line resume (or curriculum vitae, if you
prefer), his name, birth date, social security number, marital status, and
home address.

It's bad enough when organizations collect them, but to give such
information out this freely...?

The risks?  Just the usual ones of posting such information on-line, and not
having it located behind any sort of security screen.  Less obvious?  The
home page owner didn't realize the risks ... and there's apparently no-one
else at the site responsible for checking content.  This is perhaps
understandable for someone's home page on a commercial server ... but this
one was part of a department's staff listing.

John Lewellen <Lewellen@aps.anl.gov>
Advanced Photon Source, Argonne National Lab.


New virus posts user documents to public newsgroups

Mikko Hypponen <Mikko.Hypponen@DataFellows.com>
Mon, 22 Jun 1998 01:32:39 +0300
A Word macro virus called WM/PolyPoster was recently found. As the number of
macro viruses is soon reaching 3000, there's nothing special about this.
However, under the right conditions, this virus sends copies of a victim's
Word documents to 23 different Usenet newsgroups under subject lines like
"New Virus Alert!," "Important Princess Diana Info" and "How to find child
pornography."

Risks are obvious and three-fold:

1. Private and confidential data is disclosed to the world

2. When unsuspecting fellow users download and read these documents, they
get infected themselves

3. The user's name get's archived to services like DejaNews as posting
messages related to software pirates or child porn.

More details at:
http://www.DataFellows.com/news/pr/eng/fsav/19980618.htm
http://www.DataFellows.com/v-descs/agent.htm

This virus is not known to be widespread at this time.

Mikko Hermanni Hypponen - Mikko.Hypponen@DataFellows.com Tel +358 9 859 900
Data Fellows Group, PL 24, FIN-02231 Espoo, Finland http://www.DataFellows.com/


Anonymous call rejection

Edupage Editors <educom@educom.unc.edu>
Tue, 23 Jun 1998 12:46:03 -0400
The California Public Utilities Commission has voted to allow Pacific Bell
to offer a service that allows customers to reject calls from people who
have blocked transmission of their own phone numbers, a service called
"anonymous call rejection" (ACR). The ruling is an attempt to balance the
rights of caller and the party being called.  Consumer advocate Charles
Carbone explains, "People are pretty passionate about ACR and complete
blocking and select blocking.  I get people who call up and say, 'I consider
complete blocking a critical issue and one that protects my privacy,' and
from people who say, 'It's my right to know who's calling me and I don't
want to take a call from someone who doesn't want to tell me who they are.'"
(*Los Angeles Times*, 22 Jun 98;  Edupage 23 June 1998)


Shuttle imaging Y2K problem? (O'Leary via Wood, RISKS-19.81)

"Daniel A. Graifer" <dgraifer@cais.com>
Mon, 22 Jun 1998 10:56:33 -0400
>There is a Year 2000 problem with the SIR-C processor ...

Once in a while, economics has something to contribute to RISKS issues.  It
sounds like the SIR-C processor is functioning as what economists call a
"public good".  If the manager of the SIR-C processor doesn't have the
resources to contemplate a fix, perhaps the user community does.  The
problem is determining how much the user community would be willing to pay.

Academic economics has pretty much solved the problem of obtaining accurate
bids for a public good.  This is generally done with a "Groves Mechanism"
(see Groves, T. and J. Ledyard, 1977, "Optimal allocation of public goods: a
solution to the `free rider' problem", Econometrica 45, 783-811.)  This is a
bidding scheme where it can be proved that the optimal strategy for the
bidders for the maintenance of a public good is a truthful assessment of
what the good is worth to each bidder (which economists equate with the most
the bidder would pay).  If the sum of the bids exceeds the cost of the
public good, each bidder is asked to pay an amount less than or equal to
their bid.  But the mechanism rigs the game so that bidding more than it's
true value is likely to result in bill for more than it's worth to you,
while bidding less will not change the amount you are billed, but may cause
the entire project to be scrapped for insufficient community interest.

Daniel A. Graifer <dgraifer@cais.com>


More on @#$%& software

Phil Agre <pagre@weber.ucsd.edu>
Mon, 22 Jun 1998 13:40:05 -0700 (PDT)
An article in the 17 Jun 1998 *Wall Street Journal* (Robert Cwiklik,
"Honest, mom, I don't even know what those @#$%& words mean", page B1)
describes a program called "Secret Writer's Society" that is supposed to
help children write by reading their writing back to them in automatically
generated speech.  Under certain conditions, however, the recitation is
augmented with every obscenity in the English language.  The problem is
evidently that the program also reads out loud its full dictionary of words
that it is supposed to filter out.

Judging from the sound of the conditions under which the problem arises,
some kind of array bounds check is not being done.  Assuming that this
isn't another in the Wall Street Journal's recent series of urban myths,
it's a depressing comment on the state of computer programming.  Way back
when I was a college student, we were taught programming languages that
automatically prevented your program from reading random swatches of
memory through automatic bounds checking.  This was presented as a boring
and well-established technology, which of course it was.  So many of the
problems reported on Risks result from the failure to apply methods that
were prevalent 40 years ago.


Re: Exchange/Outlook plug-in for PGP ... (Poulson, R-19.82)

Curt Sampson <cjs@portal.ca>
Sat, 20 Jun 1998 21:59:39 -0700 (PDT)
>  Insert a "^Zrm *" at the right time and boom.

Actually, that would be "^Drm *". Regardless, this is hardly the first
problem that has appeared with ssh. At least twice before I've had to run
out and update all of my machines immediately due to problems of this sort
that have appeared. Fortunately, the problems appear to be publicised
quickly, and a solution is available almost immediately.

This appears to me to be about the best way of dealing with these problems
that I can think of. It's certainly unrealistic to expect that problems will
never occur in a programs as complex as the ssh suite, and, given the amount
of scrutiny that this system comes under, I'm impressed that there have been
only three or four incidents of this type in the last dozen revisions or so.

Curt Sampson, Internet Portal Services, Inc., Vancouver, BC
(604) 257-9400  http://www.portal.ca/  cjs@portal.ca


Re: German high-speed train disaster (Lesher, RISKS-19.81)

Peter da Silva <peter@baileynm.com>
Sun, 21 Jun 1998 10:28:11 -0500
This is not a new problem. Back in the early '80s I spent a couple of years
working on the real-time control software for a "hot box" detector, that sat
by the track and examined wheels and bearings as trains went by and looked
for wheels that were hot... it's amazing the number of failure modes that
could be detected simply by looking for an excessively hot bearing. Flats
were one of the things that could generate an alert.

Of course it had code to allow for temperature differences between different
kinds of wheels and bearings, and those caused by sunlight on one side of
the train.

The detector worked at up to 90 miles an hour, with a 2 MHz Z80 CPU doing
all the analysis and templating of trains, and delivering alerts over the
radio to the driver (using a male voice... normally female voices are easier
to hear but in this case the engineer has a lot of high frequency noise to
deal with).  There were no identifying marks on the trains, they and their
cars had to be recognised simply by the timing of the wheels as they passed
the detectors.

Further processing and reports were handled by a Microvax in the control
center in Portsmouth, Ohio. I think it was a Microvax I... a box with less
CPU power than the original Macintosh.

I'm really surprised that they didn't have something better on a 200 MPH
train in 1998.


Re: Fire risks compounded by loss of ... power (Erwin, R-19.82)

Eric Roesinger <aerie@on-net.net>
Sun, 21 Jun 1998 17:04:37 GMT
> When members of the household smelled smoke, they could not immediately
> call for help because their cordless phone required AC power to run.

Which is why the instruction books for many cordless phones include a
warning NOT to use a cordless phone as the only phone in a residence. In
fact, on many of the models which my engineering group specifies and/or
designs, we have this information repeated in several places (a drop-in
safety leaflet, and sometimes even on labels affixed to the product, as well
as RTFM).

Nonetheless, despite warnings, people behave as if they are stupid...

Eric Roesinger, Member Technical Staff,
Communications RF Cordless Development, Thomson Consumer Electronics


Re: "Fire risks compounded by loss of residential power" (R-19.82)

David Kipping <kipping@compuserve.com>
Mon, 22 Jun 1998 19:38:01 -0400
When smoke detectors become popular in the '80s, I added several to my
existing home.  They were battery operated and the battery "chirped" for a
week or two before it went dead.

In 1992 I built a new home and smoke detectors were installed (BRK
Electronics Model 86RAC).  The primary power is AC, but the detector has a
backup battery which also "chirps" when it runs low.  The original batteries
lasted 4 years before they ran down.  [Since I was not aware that the smoke
detector contained a battery, this caused a certain amount of confusion at 3
AM when the chirping started.]

I am surprised that it is legal to sell AC powered smoke detectors that do
not have a battery backup.  Maybe the building codes in Virginia are more
lenient than those in Idaho where I live.

David Kipping <kipping@compuserve.com>


Re: Severed MCI cable cripples the Net (Edelson, RISKS-19.82)

Seth Breidbart <sethb@panix.com>
Sun, 21 Jun 1998 22:38:29 -0400 (EDT)
>A fiber optics cable was severed under 42nd Street in the Bronx, [...]

There is no 42nd Street in the Bronx.  42nd Street runs through midtown
Manhattan.  Seth

  [A Bronx cheer for those of you who didn't know that.
  I didn't believe it for a minute, but I avoid trying to correct
  everything that does not look right, for obvious reasons.  PGN]


Social Engineering free long distance

Max Stevens <jomsteve@undergrad.math.uwaterloo.ca>
Mon, 22 Jun 1998 09:46:47 EDT
I have a calling card here in Canada with Bell, the countries largest long
distance carrier.  Over the weekend I discovered that the PIN number for it
had been changed.  I called up customer service and asked them what had
happened.  They said that *I* had changed it two days ago.  I asked them
what was required in order to change the pin number, and apparently a
password (one I've long since forgotten) that's mailed out with the card is
the only way.  Upon pressing further, they admit that if the caller appears
under duress, they'll change it.

The risks here are obvious, but what I find even more interesting is
that:
  - they didn't log when the change actually occurred
  - they didn't log the number where the call originated
  - the only information they required was my name and phone number,
    not even my billing address was required.

Assuming most people have calling cards, imagine what you could do by
picking names out of the phone book and calling Bell?

    Max Stevens                                   jomstevens@uwaterloo.ca


REVIEW: "Web Security and Commerce", Simson Garfinkel/Gene Spafford

"Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Mon, 22 Jun 1998 14:02:15 -0800
BKWBSCCM.RVW   980411

"Web Security and Commerce", Simson Garfinkel/Gene Spafford, 1997,
     1-56592-269-7, U$32.95/C$46.95
%A   Simson Garfinkel simsong@aol.com
%A   Gene Spafford spaf@cs.purdue.edu
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   1997
%G   1-56592-269-7
%I   O'Reilly & Associates, Inc.
%O   U$32.95/C$46.95 800-998-9938 707-829-0515 nuts@ora.com
%P   483 p.
%T   "Web Security and Commerce"

Anyone who does not know the names Spafford and Garfinkel simply does not
know the field of data security.  The authors, therefore, are well aware
that data security becomes more complex with each passing week.  They note,
in the Preface, that the book cannot hope to cover all aspects of Web
security, and therefore they concentrate on those topics that are absolutely
central to the concept, and/or not widely available elsewhere.  Works on
related issues are suggested both at the beginning and end of the book.

Chapter one, which is also part one, introduces the topic, and the various
factors involved in Web security.  The topic is examined from the
perspective of the user and vendor, and also looks at vulnerabilities at the
server site, client computer, and the network in between.

Part two concerns the user.  Chapter two looks at the various possible
problems with browsers, not all of which are related to Web page
programming.  Java security is only marginally understood by many "experts,"
and not at all by users, so the coverage in chapter three is careful to
point out the difference between safety, security, and the kind of security
risks that can occur even if the sandbox *is* secure.  ActiveX and the
limitations of authentication certificates are thoroughly explored in
chapter four.  Chapter five looks briefly but analytically at the possible
invasions of privacy that can occur on the Web.

Part three deals more completely with the question of digital certificates.
Chapter six explains the various techniques for identification confirmation.
The use of certification authorities is reviewed in chapter seven, including
the activity this can generate on Web browsers.  Chapter eight covers the
steps needed to obtain a client-side digital certificate from Verisign.
Microsoft's Authenticode code signing system is detailed in chapter nine.

Cryptography must be invoked at some point for any kind of data security,
and particularly for security over insecure networks, so part four invests
some depth in the topic.  Chapter ten starts with cryptographic basics,
simply in terms of the various functions cryptography can provide.
Functional limitations of cryptography, various existing systems, and US and
international regulation with respect to the technology are discussed in
chapter eleven.  SSL (Secure Sockets Layer) and TLS (Transport Layer
Security) are described in chapter twelve.

Part five details technical aspects of securing Web servers.  Traditional
host security weaknesses are reviewed in chapter thirteen.  Chapter fourteen
looks at specific strengthening measures for Web servers.  Rules for secure
CGI (Common Gateway Interface) and API (Application Programmer Interface)
programming are promulgated in chapter fifteen, along with tips for various
languages.

Commercial and societal concerns are major areas in Web security, so part
six reviews a number of topics related to commerce, as well as other social
factors.  Chapter sixteen looks at current non-cash payment systems, and the
various existing, and proposed, digital payment systems for online commerce.
Censorship and site blocking are carefully examined in chapter seventeen.  A
variety of legal issues are discussed, civil in chapter eighteen, and
criminal in nineteen.

In reviewing books I very often find that appendices are often filler.  The
most useful tend to be bibliographies or lists of vendor contacts.  Too many
seem to be mere self-indulgent filler used by the author to pad out the
book.  Although it has almost nothing to do with Web security as such, I
very much enjoyed Appendix A, Garfinkel's recounting of the lessons learned
in setting up a small ISP (Internet Service Provider).  (I suppose that this
could be considered valid coverage of Web commerce.)  The other appendices
are more directly related to the topic, including information on the
installation of Web server certificates, the SSL protocol, the PICS
(Platform for Internet Content Selection) specification, and references.

In comparison to Stein's "Web Security" (cf. BKWEBSEC.RVW) I find it very
difficult to choose between the two.  Each is readable, and each is aimed
pretty much at the same target audience.  There is little to choose between
them for technical depth: each has useful information that the other does
not.  Both are excellent: what the heck, buy two, they're small.

copyright Robert M. Slade, 1998   BKWBSCCM.RVW   980411

Please report problems with the web pages to the maintainer

Top