Subject: RISKS DIGEST 17.19
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest  Monday 19 June 1995  Volume 17 : Issue 19

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

 Contents:
Summer Slowdown for RISKS (PGN)
Bank computer develops costly crush on Fiona (Peter Ilieve)
The Royal Majesty (Bob Frankston)
For DOS/Windows users: Trojan Alert- PKZ300B.EXE (Patrick Weeks
   via Fred Gilham)
Re: The New York subway crash (Mark Stalzer)
Re: 59-Story Crisis: The Risks of Unions (Chuck Weinstock)
Internet gambling (Andrew Koenig)
The media & risks (Justin Wells)
CFP: ISOC Symposium on Network & Distributed System Security (Clifford Neuman)
Re: Multo ante natus eram (Mike Alexander, Mike Crawford)
Prodigy paranoid reaches Tasmania? (Richard Murnane)
Re: not caring about Prodigy (Jim Hill, Bob Morrell, Jim Hill)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Tue, 19 Jun 95 08:01:17 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Summer Slowdown for RISKS

RISKS will be more or less off the air from now until July 24.  I will
probably not be able to answer many of your queries and requests during that
period even when I am on-line.  Continuations of recent ongoing discussions
are likely to cease as of this issue.  However, please send in all
interesting NEW items that you encounter.

For our 10th anniversary RISKS issue on 1 August 1995, I would be very happy
if a few of you would submit (by 24 July) concise and well-reasoned
think-pieces on what we might have learned in the past 10 years, with
respect to some aspect of the RISKS experience.  Have things improved?  Or
are we collectively treading water -- or being washed out to sea?  What is
missing?  Are the real problems technological or otherwise?  (The best
reflective contributions might even wind up as Inside Risks columns in the
CACM!)

I hope you all have a pleasant summer.

PGN

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

Date: Sun, 18 Jun 95 20:51:25 BST
From: [email protected] (Peter Ilieve)
Subject: Bank computer develops costly crush on Fiona

That was the headline on a piece in *The Times* (London) on 15 June 1995
about a Barclays Bank computer system that deals with loans and mortgages to
bank staff.  It was running a new accounting system, and it refused to
generate monthly repayments for more than 100 staff named Fiona.  Nobody
else was affected, including a Ffyona.  Numerous Fionas were sufficiently
honest to contact the bank and ask why their repayments hadn't been
deducted.  It isn't clear how long the lucky Fionas would have had their
repayment holidays if some of them hadn't owned up.  The bank is adamant no
hacking was involved.  A spokeswoman blamed `a blip' and added, `Our systems
people say that they knew how to solve the problem even if they could not
explain what precisely had caused it.'

Peter Ilieve            [email protected]

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

Date: Mon, 19 Jun 1995 14:25 -0400
From: [email protected]
Subject: The Royal Majesty

The Royal Majesty is the cruise ship that ran aground off Nantucket. There
is a good article in *The Boston Globe* 19 Jun 1995 by David L Chandler
entitled "Embarrassing lessons for navigators". It is a good "risks style"
article that covers various issues including the question of whether the GPS
system indeed failed and was 17 miles off. It discusses issues of the user
interface -- is navigation information presented in such a way as to
actually be usable during hectic periods?  It brings up question of whether
it is safe to turn off Loran, the Valdez accident, and other pertinent
issues.

Nothing particularly new for Risks readers, but it is worthwhile to note
reasonable articles in the newspapers.

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

Date: Mon, 19 Jun 1995 10:34:05 -0700
From: Fred Gilham <[email protected]>
Subject: For DOS/Windows users: Trojan Alert- PKZ300B.EXE

------- Forwarded Message

*** Subject: TROJAN ALERT: PKZ300B.EXE / PKZ300B.ZIP ***
**************************** Important Notice *************************

    Some joker out there is distributing a file called PKZ300B.EXE and
PKZ300B.ZIP.  This is NOT a version of PKZIP and will try to erase your
harddrive if you use it.  The most recent version is 2.04G. Please tell
all your friends and favorite BBS stops about this hack.

Thank You.

Patrick Weeks
Product Support PKWARE, Inc.
***********************************************************************

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

Date: Fri, 16 Jun 95 08:30:38 EDT
From: [email protected] (Mark Stalzer)
Subject: Re: The New York subway crash (PGN, RISKS-17.17)

As reported in the June 16 New York Times, further investigation of the 5
Jun 1995 NY subway crash (which killed the motorman and injured 54 people)
indicates the distance between signals is shorter than the stopping distance
of a modern train.  Speculation right after the accident had focused on a
possible emergency brake failure.  However, even with the brake engaged,
tests showed it takes approximately 360ft for the train to stop.
Unfortunately, the rear of the forward train was only 288ft from the signal.
It now appears that the motorman ran the red signal, which tripped the
emergency brake and slowed the train from about 32mph (the maximum speed
after climbing the hill leading to the crash area) to 14-18mph at the time
of impact.

The signal spacing was set in 1918 when trains were shorter, lighter,
and slower than modern trains. The Transit Authority has been upgrading
the trains without upgrading the control system. A familiar RISK.

The immediate response has been to limit speeds on the section of track
where the accident occurred. When a TA official was asked if speeds will
be reduced in other areas, the official said "we don't know where the
potential trouble spots are." I guess we're just going to wait for more
accidents to find the areas that need fixing. Another familiar RISK.

Mark Stalzer, [email protected]

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

Date: Mon, 12 Jun 95 12:10:30 -0400
From: Chuck Weinstock <[email protected]>
Subject: Re: 59-Story Crisis: The Risks of Unions

One of the risks that continues to haunt me from that article (and
apparently others as well since my mother mentioned it to me when we
discussed the article) is this:

(The people in charge of repairs to the building had installed strain gauges
connected by wire to readouts in the main office.)

 One time, the readings went off the chart, then stopped. This provoked
 more bafflement than fear, since it seemed unlikely that a hurricane
 raging on Lexington and Fifty-third Street would go otherwise unnoticed at
 Forty-sixth and Park. The cause proved to be straightforward enough: When
 the instrumentation experts from California installed their strain
 gauges, they had neglected to hire union electricians. `Someone heard
 about it,' LeMessurier [the building designer] says, `went up there in
 the middle of the night, and snipped all the wires.'

Chuck Weinstock

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

Date: Thu, 15 Jun 95 20:01:01 EDT
From: [email protected]
Subject: Internet gambling

I remember once reading a paper with a synopsis something like this:

       This paper is in two parts.

       In Part 1, we prove that it is impossible to play a fair
       game of telephone poker.

       In Part 2, we give an algorithm for playing a fair game
       of telephone poker.

The apparent paradox, of course, was that the algorithm in Part 2
was actually unfair with a probability that could be made as small
as desired by making the crypto keys long enough.

I wish I remember the title or author of the paper.  Anyway, such
things leave me with the distinct impression that Internet gambling
is no less feasible than any other kind of electronic commerce.

Andrew Koenig  [email protected]

  [For the short-term future, we will see many small-scale efforts
  such as this one, whether or not they are soundly based.
  In the long-term, we still need a secure infrastructure and trusted
  servers and trustworthy individuals and more laws (and lawyers) to
  give it a real semblance of "fair".  (We might refer to this as
  "secure infostructure".)  PGN]

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

Date: Mon, 19 Jun 1995 01:23:24 -0400
From: [email protected] (justin wells)
Subject: The media & risks

It occurred to me that the stories in comp.risks are often sensationalistic
enough to warrant widespread media coverage.  In fact, a good chunk of stuff
posted here is drawn from the media, with commentary added.

One risk commonly mentioned here is that "the public" or "the media" haven't
got enough understanding of computer risks, and that we're all going to
suffer as a result -- recently there's been discussion of lawyers who don't
understand computers, etc.

Well --

Has anyone tried convincing some television producers to add a computer risk
segment to their news programs?  There's easily enough material that's
interesting enough that's already part of their program -- to make it a
proper segment all that would be required is the addition of a brief
editorial highlighting for the public the general nature of the particular
risk.  I think it would be interesting enough to sell (but then as a regular
reader of comp.risks I'm biased :)

I don't have the background or the experience or the connections or
anything else to try and make something like this actually happen, but
I'm sure that somewhere out there in RISKS land, someone does...

Imagine the benefits of having computer risks dealt with sensibly on CNN.
Here in Canada the late night news just ran an extensive segment on the
risks of cellular phones and radios interacting with medical equipment, so
it's not like the media is opposed to the idea.  What with all the hype
about the Internet these days, I think there's a major window of
opportunity...

Justin [email protected]

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

Date: Sun, 18 Jun 1995 06:49:34 -0700
From: Clifford Neuman <[email protected]>
Subject: CFP: ISOC Symposium on Network & Distributed System Security

                          CALL FOR PAPERS
                 The Internet Society Symposium on
              Network and Distributed System Security

                        February 22-23, 1996
          San Diego Princess Resort, San Diego, California

GOAL: The symposium will bring together people who are building hardware
and software to provide network and distributed system security services.
The symposium is intended for those interested in the practical aspects of
network and distributed system security, focusing on actual system design
and implementation, rather than theory.  We hope to foster the exchange of
technical information that will encourage and enable the Internet community
to apply, deploy, and advance the state of available security technology.
Symposium proceedings will be published by the IEEE Computer Society Press.
Topics for the symposium include, but are not limited to, the following:

*  Design and implementation of communication security services:
  authentication, integrity, confidentiality, authorization,
  non-repudiation, and availability.

*  Design and implementation of security mechanisms, services, and
  APIs to support communication security services, key management
  and certification infrastructures, audit, and intrusion detection.

*  Requirements and designs for securing network information resources
  and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS.

*  Requirements and designs for systems supporting electronic commerce --
  payment services, fee-for-access, EDI, notary -- endorsement,
  licensing, bonding, and other forms of assurance.

*  Design and implementation of measures for controlling network
  communication -- firewalls, packet filters, application gateways, and
  user/host authentication schemes.

*  Requirements and designs for telecommunications security especially
  for emerging technologies -- very large systems like the Internet,
  high-speed systems like the gigabit testbeds, wireless systems, and
  personal communication systems.

*  Special issues and problems in security architecture, such as
  interplay between security goals and other goals -- efficiency,
  reliability, interoperability, resource sharing, and cost.

*  Integration of security services with system and application security
  facilities, and application protocols -- including but not limited to
  message handling, file transport, remote file access, directories, time
  synchronization, data base management, routing, voice and video
  multicast, network management, boot services, and mobile computing.

GENERAL CHAIR:
  Jim Ellis, CERT Coordination Center

PROGRAM CHAIRS:
  David Balenson, Trusted Information Systems
  Clifford Neuman, USC Information Sciences Institute

REGISTRATIONS CHAIR:
  Donna Leggett, Internet Society

SUBMISSIONS: The committee invites technical papers and panel proposals
for topics of technical and general interest.  Technical papers should
be 10-20 pages in length.  Panel proposals should be two pages and
should describe the topic, identify the panel chair, explain the format
of the panel, and list three to four potential panelists.  Technical
papers will appear in the proceedings.  A description of each panel will
appear in the proceedings, and may at the discretion of the panel chair,
include written position statements from each panelist.

Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author.  The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.

       Deadline for paper submission:      August 14, 1995
       Notification sent to authors by:    October 16, 1995
       Deadline for camera-ready copy:     November 13, 1995

Submissions must be received by 14 August 1995.  Submissions should be
made via electronic mail.  Submissions may be in either of two formats:
PostScript or ASCII.  If the committee is unable to print a PostScript
submission, it will be returned and hardcopy requested.  Therefore,
PostScript submissions should arrive well before 14 August.  If
electronic submission is difficult, submissions should be sent via
postal mail.

All submissions and program related correspondence (only) should be
directed to the program chair:

                  Clifford Neuman
                  University of Southern California
                  Information Sciences Institute
                  4676 Admiralty Way
                  Marina del Rey, California 90292-6695
                  Phone: +1 (310) 822-1511
                  FAX:   +1 (310) 823-6714
                  Email: [email protected]

Dates, final call for papers, advance program, and registration
information will be made available at the URL:

                  http://nii.isi.edu/info/sndss

Each submission will be acknowledged by e-mail.  If acknowledgment is not
received within seven days, please contact the program chair as indicated
above.  Authors and panelists will be notified of acceptance by 16 October
1995.  Instructions for preparing camera-ready copy for the proceedings will
be sent at that time.  The camera-ready copy must be received by 13 November
1995.   [Program committee and a few others deleted.  PGN]

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

Date: Thu, 15 Jun 1995 19:45:13 -0400
From: [email protected] (Mike Alexander)
Subject: Re: Multo ante natus eram

I, too, am glad to see that Multics is still used.  It is a system that was
far ahead of its time in many respects.

In MTS (the Michigan Terminal System), a system contemporaneous with
Multics which is also still in use, we solved the problem of the operators
entering a bad time in a slightly different way.  During initialization,
the system compares the current time with the time in the last billing
record recorded.  If the current time is earlier or too much later (more
than 12 hours, unless the day is Sunday in which case 18 hours is ok) it
complains and asks the operators to confirm that the time is ok.  This has
several advantages: it doesn't use hard-coded dates, it is a more precise
check, and it never makes the system unusable.  Of course this has become
less important as modern machines maintain the time of day even when not
running and the clock rarely needs to be set at all.

Mike Alexander, Univ. of Michigan  [email protected] [email protected]

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

Date: Fri, 16 Jun 95 19:14:26 -0700
From: [email protected] (Michael D. Crawford)
Subject: Re: Multo ante natus eram

Last fall I worked on the 2Market home shopping CD.  This is a CDROM
catalog with pictures of products from many popular mail-order catalogs,
with QuickTime movies of TV commercials, and sound clips of record albums.

One of the features of 2Market is that items go on sale.  Of course the
sales have to be prepared in advance, and the user will only get it right
if their clock is set.

Knowing my own habit of living in the year 1904, the Macintosh beginning
of history (for no reason I can really fathom), I convinced the designers
to let me put in a warning that your clock is off.  The warning is placed
in the message box that is normally used to inform the users that items
are on sale.  Any date that is before we shipped the CD, or after (I
think) a year after the CD shipped warns the user to reset their clock.
Shorter times afterwards give the user the number to order the next CD.

Let's hope they always remember to update the code when they ship new
versions... I'm not with Medior anymore to remind them.

Mike Crawford  [email protected]

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

Date: Sun, 18 Jun 1995 12:56:27 +1000 (EST)
From: Richard Murnane <[email protected]>
Subject: Prodigy paranoid reaches Tasmania?

The following recent news release from the Wireless Institute of Australia
suggests that some people are getting very nervous, following the Prodigy
defamation case in the USA:

The name of the gateway is just one of those ironic little twists. :-)

     PACKET GATEWAY DEMANDS STAT. DEC. FROM AMATEURS

The Launceston Institute of TAFE [Technical and Further Education]
in northern Tasmania, which runs an amateur radio packet-to-Internet
gateway known under the acronym of LITGATE, is requiring radio
amateur users to file a statutory declaration with them.

The relevant wording of the declaration says: "That I agree to take
full personal responsibility for any information or data which is sent
from my station, or from a station operating under my callsign.

"That I will not hold the Launceston Institute of TAFE responsible for
the content of data received through the LITGATE, whether such data
is of an offensive, improper, illegal or other unacceptable nature."

Basically, what the Launceston TAFE requires is that radio amateurs
wanting access to LITGATE must say they will accept responsibility
for all messages under their callsign, whether pirated or not, and agree
they will absolve the Launceston TAFE from responsibility for any
material placed on its system.

Whether such a statutory declaration is legally binding would be a
matter of conjecture. (Thanks to Victorian Division President, Jim
Linton VK3PC, for details on that item).

[end]

I hope somebody can convince these people of the stupidity of their
decision, as they clearly don't understand some of the technical
issues. For those not involved in Amateur Radio, we "hams" operate
our own computer network, using our radios as the physical layer.

In some places, known as "wormholes" or "gateways", operators transport
message over long distances via Internet, replacing the slower chain of
short-range VHF or UHF radio links. The traffic leaves the net again at some
remote point and rejoins the Amateur packet radio network.

It's important to realise that the wormholes and Internet are merely being
used as a medium for conveying this traffic from one part of the Amateur
packet network to another; the Amateur traffic is effectively "quarantined"
from other Internet traffic because Amateur Radio licence conditions forbid
non-Amateurs (e.g. other Internet users) from conveying message by Amateur
Radio. So, it would be very hard to argue that LIT is a "publisher" of any
Amateur packet radio traffic passing through its gateway.

I might add that it is a trivial matter to "pirate" another Radio Amateur's
callsign.

-Richard Murnane (Amateur station VK2SKY)

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

Date: Fri, 16 Jun 1995 21:00:42 GMT
From: [email protected] (Jim Hill)
Subject: Re: not caring about Prodigy (Morrell, RISKS-17.18)

>hatred against Prodigy, which appears to be practicing the most control of
>any provider (though still nothing like a newspaper) has people cheering
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think the risk is overstated, because (and only because) the underscored
assertion is contradicted by Prodigy's own words:

>     "We make no apology for pursuing a value
>     system that reflects the culture of the
>     millions of American families we aspire to
>     serve. Certainly no responsible newspaper
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     does less when it carries the type of
     ^^^^^^^^^
>     advertising it published, the letters it
>     prints, the degree of nudity and unsupported
>     gossip its editors tolerate."
>(Exhibit J.)

If Prodigy chooses to back off on their editorial control to, say (and the
decision does say), Compuserve's or AOL's level, they won't be liable for
the content they carry.  Until then, they're providing a specific and
valuable -- no irony intended, for any who might think newspapers aren't
valuable -- service, and can be held responsible to the standards of that
service.

Jim Hill  [email protected]

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

Date: Fri, 16 Jun 1995 16:06:34 -0400 (EDT)
From: Bob Morrell <[email protected]>
Subject: Re: not caring about Prodigy

I see your point, and hope you are right that the ruling will not have
the broad effect I fear (though I have already heard it cited in exactly
the manner I have described in a NPR report on another cyber-case)

However, it is worth noting that your exhibit does not prove that Prodigy
wanted to be a newspaper. It merely shows that Prodigy cited as an
example of controlling content, newspapers. They could have cited
restaurants that control dress codes, that would not have made them a
restaurant. To say, when one is tired, that even horses get tired if you
work them too long, does not make one a horse.

To say that you have some rights, similar to one entity does not make you
that entitity. This is the kind of square pegs in round hole legal
thinking that I think harms the emerging character of the net.

Bob Morrell  [email protected]

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

Date: Fri, 16 Jun 1995 13:42:57 -0800
From: [email protected] (Jim Hill)
To: Bob Morrell <[email protected]>
Subject: Re: not caring about Prodigy

"Certainly no responsible newspaper does less" in terms of controlling
content -- "the letters it prints" -- says to me that they are *at least* as
responsible as any newspaper.

It's not just an example, it's an explicitly stated minimum standard.  One
doesn't have to be a prodigy (sorry ;-) to infer liability.

I do agree with you that "rabid" is on target for too much of the
anti-Prodigy froth.

I will also say I was wrong to suggest earlier that moderated groups and
lists should be held to that standard.  Only the ones that claim it for
themselves.

Jim Hill  [email protected]

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

Date: 24 March 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

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

End of RISKS-FORUM Digest 17.19
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.