Subject: RISKS DIGEST 17.67

Subject: RISKS DIGEST 17.67

RISKS-LIST: Risks-Forum Digest Thursday 25 January 1996 Volume 17 : Issue 67

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:
Risks of military technology in civilian life? (Howard Chalkley)
Unintended missile launches (Mary Shafer)
Turning off virus protection? (Dave Wagner)
WebCard Visa: It's everywhere you (don't) want to be? (Doug Claar)
I won't tell if you won't... (Ed Ravin)
New Book on Cyberculture (Gary Chapman)
"Civilizing Cyberspace" by Miller (Rob Slade)
Dangers of Ambiguous Headlines (Matt Welsh)
Warning on Thefts of Laptops (Tom Zmudzinski)
Re: Single computer breaks 40-bit RC4 in under 8 days (Paul C. Kocher)
Re: Cost to crack Netscape Security falls... (Peter Curran)
Re: Security hole in SSH 1.2.0 (Mike Alexander)
Dirty word filters: Sidewinder (Henry G. Baker)
Re: Antispamming technology (Cancelmoose, Jay Prince, Rob Slade)
Re: Hey, your mailing list is sending me viruses! (Phil Hammons,
Joe A. Dellinger, Mitch Wagner)
ABRIDGED info on RISKS (comp.risks)

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

Date: Thu, 25 Jan 1996 11:54:38 GMT0BST1
From: "Howard Chalkley" <[email protected]>
Subject: Risks of military technology in civilian life?

This anecdote has started spreading around the net...

A snippet spotted in Pilot Magazine and entered in Bike Magazine: The
article was entitled "In a hurry are we, sir?" ( British Police Wit).

Two members of the Lothian and Borders traffic police were out on the
Berwickshire moors with a radar gun recently, happily engaged in
apprehending speeding motorists, when their equipment suddenly locked-up
completely with an unexpected reading of well over 300 mph. The mystery was
explained seconds later as a low flying Harrier hurtled over their heads.
The boys in blue, upset at the damage to their radar gun, put in a complaint
to the RAF, but were somewhat chastened when the RAF pointed out that the
damage might well have been more severe. The Harrier's target-seeker had
locked on to the `enemy' radar and triggered an automatic retaliatory
air-to-surface missile attack. Luckily(?), the Harrier was operating unarmed.

Howard Chalkley, GST Technology Ltd, Meadow Lane, St Ives, Huntingdon PE17 4LG
UK +44 1480 496789 Fax: +44 1480 496189 [email protected]

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

Date: Thu, 25 Jan 1996 14:30:27 -0800 (PST)
From: [email protected] (Mary Shafer)
Subject: Unintended missile launches

The problem of unintended missile launches from aircraft is not a new one.
I have a friend who was flying CAP (Combat Air Patrol) in the Gulf when a
radar-guided missile launched itself from his fighter. Subsequent
investigation determined the cause, but he was told at the time that there
had been at least three other such incidents, with the same aircraft/missile
combination.

In his case, the missile was heading for another Coalition aircraft, but
lock was broken when he turned off his radar. This does not, of course,
work for IR-guided missiles like that in the Japanese F-15/Sidewinder
shootdown that was reported in RISKS-17.65 on 23 Jan 1996.

(Forgive my vagueness above, but I'm just not sure how public the story is
and don't feel it proper to give more details, since it's not my story. I
only heard it when I asked Gus why he was called Gus--after Gus Grissom, of
course.)

I have read of numerous spontaneous launches in Vietnam. I also believe
that there was an incident some time ago onboard a carrier in which a
missile "launched" itself while being attached to the aircraft (I think when
it was connected electrically to the airplane) causing injuries to the
arming personnel and other ground crew.

Mary Shafer, SR-71 Flying Qualities Lead Engineer, NASA Dryden Flight Research
Center, Edwards, CA URL http://www.dfrc.nasa.gov/People/Shafer/mary.html

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

Date: Thu, 25 Jan 1996 09:32:00 -0600 (CST)
From: Dave Wagner <[email protected]>
Subject: Turning off virus protection?

I just got my fancy TurboTax "Deluxe" CD in the mail the other day, and
decided to install it (Windows 3.1). I dutifully put in the CD, and entered
d:\setup, and off it went installing the software seemingly correctly.
However, when I tried to run it, the program either crashed or hung.
Searching the "help", I find it says to make sure that you turn off all
virus checking software. Hmm. Just to see, I did that, and it installed
the same, but (after turning on the virus checker) it finally ran normally.
The risks here are pretty obvious..

- Since viruses have shown up in shrink-wrapped software, it seems
pretty chancy to turn off protection while you run a program (the
installation)

- Should we become used to turning off this when asked by the software
(This is maybe a similar risk to the Java protections - "To get the
most out of this web page, please turn off ...")

- And finally, for my own info, what is this install doing that's causing
this problem??

Dave Wagner [email protected]

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

Date: Wed, 24 Jan 1996 19:23:54 -0800
From: Doug Claar <[email protected]>
Subject: WebCard Visa: It's everywhere you (don't) want to be?

Just read an article in the *San Jose Mercury News* that Visa International
and Block Financial will offer a special "WebCard Visa". The card will
allow users to access their account statements via Internet. The article
goes on to say "The service will get around security concerns by never
transmitting the account number over the Internet. Users will type in a
password instead." As if somehow that will solve all the security problems!
In that Visa and Microsoft have co-developed the "Secure Transaction
Technology" specification (STT), there is probably/hopefully more to the
story than the newspaper lets on. I haven't seen any discussion of how
secure STT is, but it is described at
http://www.microsoft.com/intdev/inttech/wire15dx.htm

Doug Claar

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

Date: Tue, 23 Jan 1996 20:32:37 -0500 (EST)
From: Ed Ravin <[email protected]>
Subject: I won't tell if you won't...

I just found this browsing through a router manufacturer's "Frequently
Asked Questions" file:

Q3 I have a bridge/router, and I have forgotten my password. I am
no longer able to log in and configure the device(s). What do I do
now?

Do not panic! Enter the following password at the password
prompt:XYZZYHIMOM. This should get you into the unit. Notice!! This is
a back door to the units, and should not be made available to people
who do not need to know about it!

And I don't even own one of these routers -- I found this in a reseller's
online catalog. Back doors in devices that are often hooked directly to
external networks are a Bad Idea, if you ask me. At least the manufacturer
documented it...

(password above changed to protect the guilty)

Ed Ravin +1 212 678 5545 [email protected]

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

Date: Thu, 25 Jan 1996 16:16:12 -0600
From: [email protected] (Gary Chapman)
Subject: New Book on Cyberculture

New and Recommended:

Escape Velocity: Cyberculture at the End of the Century

By Mark Dery

Grove Press, 1996

A pretty wild and entertaining look at "cyberculture," including all the
hype and a healthy dose of skepticism, from a journalist who has a distinct
and rather baroque style of writing that I find fun. Covers all the
personalities of cyberpunk, raves, computer sex, music, "posthuman" beings,
and all the other nutty things going on these days. Lots of fun and
educational too.

Mark and I went to college together, years ago, so I'm happy to flog his
new book (in which I also appear -- but NOT in the chapter on cybersex!).
He previously edited another fun and useful collection, Flame Wars, which
includes my essay, "Taming the Computer" (Duke University Press, 1994).
(Together, we'll sell some books!)

Gary Chapman, The 21st Century Project, LBJ School of Public Affairs, Drawer Y,
Univ. Texas, Austin, TX 78713 512-471-8326 [email protected]

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

Date: Wed, 17 Jan 1996 14:56:27 EST
From: "Rob Slade" <[email protected]>
Subject: "Civilizing Cyberspace" by Miller

BKCVLCYB.RVW 960108

"Civilizing Cyberspace", Steven E. Miller, 1996, 0-201-84760-4, U$26.85
%A Steven E. Miller [email protected]
%C 1 Jacob Way, Reading, MA 01867-9984
%D 1996
%G 0-201-84760-4
%I Addison-Wesley Publishing Co./ACM Press
%O U$26.85 800-822-6339 617-944-3700 Fax: (617) 944-7273 [email protected]
%P 413
%T "Civilizing Cyberspace: Policy, Power and the Information Superhighway"

On the rising wave of information superhighway books, and the increasing
backwash of anti-net tomes, no single author has been able to produce a work
that even remotely compares with Miller's. Neither dazzled by technical
brilliance nor dreading the cyborg juggernaut, he provides the fruits of a
working relationship with the technology, thorough research, and insightful
analysis.

The book specializes in public policy, but since that can touch everyone and
everything it is not a limitation. Miller is thus able to examine all aspects
of information structures and strictures. His material is clear and well
reasoned: it does not provide ready answers at every point, but raises all
pertinent issues. Even esoteric topics are handled well: obviously not all
areas can be covered in depth, but Miller knows more than he says and gives
accurate and helpful resumes.

One shortcoming in the book is the less than rigorous division of topics.
While many issues in public policy interrelate, many chapters seem to flow
together without an obvious break. This may be difficult to resolve, but it
was rather odd to find the same (fairly lengthy) quote used in almost identical
discussions on both pages 64 and 204.

copyright Robert M. Slade, 1996 BKCVLCYB.RVW 960108
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected] [email protected]

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

Date: Thu, 18 Jan 1996 13:34:10 EST
From: [email protected] (Matt Welsh)
Subject: Dangers of Ambiguous Headlines

An article in ClariNet's clari.tw.computers newsgroup caught the eye
of a colleague of mine this morning. The headline is:

> Subject: Lotus in Security Compromise

Immediately alarm bells began to ring: The security in Lotus 1-2-3 has
been compromised?

But, alas, the article is of a tamer nature:

> SAN FRANCISCO (AP) -- Lotus Development Corp. announced a
> compromise with the federal government Wednesday that will allow it
> to put better security features into the international version of
> its Notes program.

The RISK here is obvious (although the implications may be subtle).
Ambiguous newspaper headlines have always been comic relief for some, but
now that our news stories and information are presented electronically, I
find it not difficult to believe that automated agents will soon be reading
our news for us, either presenting articles of interest or (worse)
attempting to summarize the content. (Indeed, I already employ the
``killfile'' feature of my newsreader to automatically select articles which
match certain expressions). Keywords such as ``Security Compromise'' would
certainly be targets for a reader who wishes to stay on top of current
happenings in computer and electronic security.

M. Welsh, [email protected] Cornell University Robotics and Vision Laboratory

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

Date: Wed, 24 Jan 96 11:09:41 EST
From: "Tom Zmudzinski" <[email protected]>
Subject: Warning on Thefts of Laptops (fwd from Buddy Guynn)

The following advisory is being provided by Mr. Buddy Guynn, DMC Montgomery
Security Manager. He received the information from the Army Material
Command regarding the security of Laptop Computers during travel.

1. The following information is valid not only for laptops but
also for other items of value such as briefcases while you are
in domestic or international travel status:

"Laptop computers have become a premium target for theft
throughout Europe. Every international traveler who is
anticipating on carrying a laptop computer with them must
remain on constant alert as they traverse through all
airports.

Two methods of theft have already occurred at separate
airports and the techniques that were used to steal the
laptop computers can occur at any airport. Both methods
involved two thieves to carry out the theft.

Recently, Brussels Airport security advised that one method
involved the use of security x-ray machines. The first
thief would precede the traveler through the security check
point and then loiter around the area where the carry-on
luggage had already been examined. When the traveler places
his laptop computer onto the conveyer belt of the x-ray
machine, the second thief would step in front of the
traveler and set off the metal detector. While the traveler
was being delayed, the first thief would remove the
traveler's laptop computer from the conveyer belt just after
it had gone through the x-ray machine and quickly disappear.

The most recent method of theft just occurred at the
Frankfurt International Airport, Germany, while the traveler
was walking around a crowd of people in the airport
terminal. The traveler, who was carrying his laptop
computer on his rollbag, was preceded by the first thief.
Just as the traveler got around the crowd of people, the
first thief stopped abruptly, causing the traveler to stop
abruptly. When they stopped momentarily, a second thief,
who had been following just behind them, quickly removed the
traveler's laptop computer from his rollbag and disappeared
in the crowd."

2. All travelers, both international and domestic, are urged to
be alert to the above methods used in stealing computers and
always be mindful of any abrupt diversions during your travels.
Report any losses immediately to authorities. Keep serial
numbers, make, and model information of your laptop computers, or
of any items of value, separate from the item so you can give
precise information to authorities if the items are stolen.

3. Request widest dissemination of this correspondence.

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

Date: Wed, 24 Jan 1996 16:20:42 -0800
From: [email protected] (Paul C. Kocher)
Subject: Re: Single computer breaks 40-bit RC4 in under 8 days (Weimer, 17.66)

> ... I'm certainly not going to be concerned about what it is costing
> someone else for me to > crack keys.

On the contrary, many security weaknesses aren't prevented because people
*don't* consider the cost to break into the overall system, and instead
focus on the encryption. For example, cryptographers (myself included, I
confess) like to use triple DES because a "fair" brute force attack will
take millions of years. But in practice, the assumption that attackers will
actually use brute force makes about as much sense as wearing bright red
uniforms in the forest...

Brute force is almost never the simplest attack to mount -- it's the
simplest to understand and quantify. For example, how much would it cost to
mail out free "demo" disks to unsuspecting users? Although this isn't
playing "fair" by the cryptographer's rules (which require that the two
endpoints of a secure connection be secure), the cost per "break" is under
$10 once the trojan software has been written.

Unfortunately the number of key bits doesn't have much correlation to actual
security; estimated dollars per successful break-in is a much more useful
figure. On a typical PC, there are just too many other security weaknesses
for there to be much practical difference between 3DES and 40-bit RC4.

Paul Kocher ([email protected]) Cryptography consultant

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

Date: Thu, 25 Jan 1996 14:52:52 GMT
From: [email protected] (Peter Curran)
Subject: Re: Cost to crack Netscape Security falls... (Peterson, RISKS-17.65)

>P.S. Don't blame Netscape, they are just abiding by ITAR.

IMHO, this is letting Netscape off the hook far too easily. There is a
simple solution to the ITAR problem - develop the software in a location not
subject to US export laws (i.e. almost anywhere else in the world). Anyhow
who is claiming to be addressing the problem of network security, etc., on a
global basis should be adopting this solution. The USA has no monopoly on
software development expertise, and there is no reason the world should be
held ransom to US military nonsense.

Peter Curran [email protected]

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

Date: Thu, 25 Jan 1996 13:44:17 -0500
From: [email protected] (Mike Alexander)
Subject: Re: Security hole in SSH 1.2.0 (RISKs of being "too careful"?)

The bug in ssh described by Barry Jaspan is a good example of a whole class
of Unix security bugs that result from the fact that Unix associates all
access controls with users and has no way to assign access rights to a
program independent of the user running the program. This is not true of
all operating systems. One (certainly not the only) example is MTS (the
Michigan Terminal System). Each program in the system is assigned a Program
Key and access to files and other system resources can be granted to the
program (or a combination of a program and a user) as well as to a user.
This makes it much easier to write programs such as ssh since they never
have to masquerade as a super user.

Of course there are lots of other problems one has to solve. The algorithm
for switching program keys as control switches among different code in the
same process is important, for example. One also needs to make sure that
users can't sniff at the memory of a process that holds important
information (such as passwords). In MTS this is done by making the memory
of a process invisible when a "run only" program is loaded in it. Using
Program Keys, a run only program is one whose file is permitted to the
program loader, but not to the user running it. Hence a program may be run
only to one person and not to another. All in all this scheme has worked
quite well for the last 25 years or so.

Mike Alexander, University of Michigan [email protected] [email protected]

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

Date: Wed, 24 Jan 1996 11:23:13 -0800 (PST)
From: [email protected] (Henry G. Baker)
Subject: Dirty word filters: Sidewinder

Apparently, 'dirty word filters' for email (and presumably for news, as
well) are almost here.

Quoting from http://www.sidewinder.com/:

" FAQ Backdrop Image Sidewinder Frequently Asked Questions
..
6. What is type enforcement?
..
... Future releases will provide application layer
filters that can detect some irregularities on incoming electronic
mail addresses, validate traffic based on cryptographic
signatures, check for restricted legends in outgoing files, and so
on.
..
8. How does Sidewinder control network traffic?

Sidewinder uses the following (Rule Setting and Filtering)
techniques to control your network traffic:
..
+ Content Based Access Control

NOTE: This following is a set of capabilities we intend to
provide in future Sidewinder releases.

Sidewinder will be able to allow or prevent the delivery of
data based on the data contents. For example, Sidewinder
could enforce access control based on user names in
electronic mail messages.

Sidewinder could also control access based on the presence or
absence of key words in a message, file, or Web page (i.e.
PROPRIETARY or FOR PUBLIC RELEASE).

9. How are new controls and access limitations added?

Controls and access limitations for existing services are
controlled through configuration files. These configuration files
may only be modified by authorized administrators accessing the
files via the internal network or a directly connected terminal."
..
" FAQ Backdrop Image Sidewinder Frequently Asked Questions
SIDEWINDER(TM) INTERNET CLIENT SERVICES

This section provides questions and answers related to the services
that Sidewinder(tm) provides to Internet clients (external users).
..
3. How is the mail passed? Does Sidewinder "read" the entire mail
message?
..
Future versions of Sidewinder will provide an e-mail filter that
applies access control and other security checks."

End of quote.
-----

I also seem to recall seeing a picture of theirs showing how this
product filters email with a 'Dirty Word Filter'.

I believe that this product has the capability of causing alarms under
programmed conditions. I presume that one could configure this program
to ring a bell every time a certain 'dirty word' was detected in anyone's
email or on usenet news.

The RISKS to civil liberties here are obvious.

Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html

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

Date: Thu, 25 Jan 1996 05:41:22 GMT
From: "Cancelmoose[tm]" <[email protected]>
Subject: Re: Antispamming technology

For about 5 months I've been working on a project to reliably detect Usenet
spam, and allow people who are bothered by it to avoid seeing it. The
"Automoose" is a daemon which scans usenet articles, and when it sees the
same message that has been posted too many times, it notifies the world via
a NoCeM notice.

These notices are PGP signed to prevent forgery. They are read by special
clients which check the signatures, and mark spam messages as 'read'. NoCeM
has no effect on those who aren't interested, and the user can control whose
notices are applied by adding or removing keys from the keyring.

For more information see http://www.cm.org or email me: [email protected].

[Let's bring back Monty Python, who spammed spam itself. PGN]

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

Date: Wed, 24 Jan 96 18:46:27 TZ
From: Jay Prince (EDP) <[email protected]>
Subject: Re: Antispamming technology (Kealey, RISKS-17.66)

Martin proposes an excellent idea for locking potential spams:

One fault of his proposal is this: If it becomes very popular, scanning for
the string "send a message with `unlock.87326482376' " and extracting the
unlock code would be a simple matter for a spammer to script. Thereby, the
return address on the spam would be a daemon that watches for your Anti-Spam
message and then immediately sends the unlock message.

It would be a simple matter for the spammer to change the domain name
of the originating spams (As well as usernames) to get around them then
being locked out by AntiSpam after unlocking the first message.

So, your idea suffers because it relies on the other side of the spam being
a person (for whom it would be a hassle to change their address if they are
blocked) rather than a professional spammer. But, it is a great start.

Jay

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

Date: Wed, 24 Jan 1996 13:19:13 EST
From: "Rob Slade" <[email protected]>
Subject: Re: Antispamming technology (Kealey, RISKS-17.66)

>I'm working on an idea that I hope will increase the cost of
>advertising by requiring manual intervention for each separate
>recipient, while not stopping messages from valid senders.

The system would halt e-mail from an unknown site/account, and require a
manual response in order to have the sender placed on an "approved" list in
order to allow his/her/its mail into the system.

>Some risks that I can see: [...]

I can see quite a variety of problems.

- dealing with any listserver, mailbot or other automated agent. I use
them a lot.

- the 48 hour limit would frequently be a problem with systems (see
recent situations with AOL and MSN) that have become overloaded with mail,
and also with users who only check mail once a week or so. (I know that
many high volume listservers have this response limit, but in that case
you do have recourse to a human list owner.)

- our site has had four or five changes to the mail gateway in the past
two years. Each has meant a change in the address. (Also, I am listed at
least five times in Godin's "Internet White Pages" simply because of changes
to my "real name".)

- as described, the "approved" list would apply to an entire site. This
would mean that a moments impatience or inattention could get someone barred
from a whole site. Conversely, one could get around the restriction by
sending an innocent message to someone at the site, become "approved", and
then spam the site. (Many Freenets, and no few ISPs, use numbered accounts.
Someone recently spammed Mindlink in Vancouver using this method. Mindlink
has now blocked mail to account numbers: the sender must use the recipient's
"alias".)

I could go on, but I think this indicates that such a program would quickly
become very complex. I suspect that spamming is a natural risk of email in
much the same way that telemarketing is a risk of telephones and viruses are
a risk of computers. It just goes with the territory. So far, the net has
proven to have protections against the most flagrant violators. Today I saw
a note in Edupage which reported that MCI now has a policy which allows them
to terminate the accounts of spammers. (It takes a lot to get corporate
monoliths to respond in this manner.)

Now, if you want a *real* risk to the net, look at the Web ... :-)

[email protected] [email protected] [email protected]
Author "Robert Slade's Guide to Computer Viruses" 0-387-94663-2 (800-SPRINGER)

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

Date: Wed, 24 Jan 96 15:13:40 PST
From: Phil Hammons <[email protected]>
Subject: Re: "Hey, your mailing list is sending me viruses! (Dellinger, 17-66)

In his remarks, Joe comments on modems that disconnect on "+++". Like the
Internet Goodtime virus, this has a grain of truth in it. With the (sic)
"Hayes-compatible" Modems, when this string is sent into the serial port of
the modem (i.e. from the calling station), it causes the modem to go into
command mode. The connection is not hung up at this time. If you know what
you are doing, you can drop back into data mode. (How many do? Quien Sabe?).
If received via the phone port, it is just another string of bits. "Too
little knowledge is very bad and not enough is still confusing. Mil Gracias.

[Actually, I meant to mention in RISKS-17.66 that the +++ problem
is discussed in RISKS-14.45,46,47, back in April 1993. PGN]

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

Date: Thu, 25 Jan 96 10:38:28 CST
From: [email protected] (Joe A. Dellinger)
To: Phil Hammons <[email protected]>
Subject: Re: Hey, your mailing list is sending me viruses!

Phil, I agree that what you describe is what is SUPPOSED to happen. But not
all "Hayes-compatible" modems behave exactly as they are supposed to. There
is also a risk in believing that "compatible" products are indeed 100%
compatible as advertised.

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

Date: Thu, 25 Jan 1996 22:08:15 GMT
From: [email protected] (Mitch Wagner)
Subject: Re: Hey, your mailing list is sending me viruses!

> I'm told some brands of modem will promptly disconnect if they see
>the string "+++" go by at any point in the data stream.

I'm told that the string "NO CARRIER", with the "N" at column one, will
cause some comm software to hang up.

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

Date: 11 January 1996 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED info on RISKS (comp.risks)

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.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. [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

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, nonrepetitious, and without caveats
on distribution. Diversity is welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form. Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]

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

End of RISKS-FORUM Digest 17.67
************************