[risks] Risks Digest 21.55

From: RISKS List Owner (riskoat_private)
Date: Tue Jul 31 2001 - 15:44:43 PDT

RISKS-LIST: Risks-Forum Digest  Tuesday 31 July 2001  Volume 21 : Issue 55

   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.55.html>
and by anonymous ftp at ftp.sri.com, cd risks .

Oxygen tank kills MRI exam subject (PGN)
Software is called capable of copying any human voice (PGN)
Software safeguards prevent Solar Sail from separation? (Stanislav Shalunov)
Firefighter's phone lines disrupted because of a SMS hoax (Stanislav Meduna)
New results on WEP (Adi Shamir via Matt Blaze)
FBI hit with Sircam virus that distributes files on your HD (Declan McCullagh)
Super-accurate atomic clock hates Sundays (Ken Knowlton)
Risks of relationships online (Gary Stock)
Apple DNS Entry hacked (Greg Searle)
University of Pennsylvania cable cut (Rebecca Mercuri)
Cell phones overload 911 in Denver (Richard J. Barbalace)
Qwest Wireless erroneously overbills customers by thousands of dollars 
  (Richard Kaszeta)
Re: FBI arrests Russian hacker visiting U.S. for alleged DMCA breach 
  (Bill McGonigle)
More on the risk of moving and identity theft (Harry Erwin)
REVIEW: Bruce Schneier, "Secrets and Lies: Digital Security in a 
  Networked World (Rob Slade)
Abridged info on RISKS (comp.risks)


Date: Tue, 31 Jul 2001 10:09:32 -0700
From: "Peter G. Neumann" <neumannat_private>
Subject: Oxygen tank kills MRI exam subject

In New York's Westchester Medical Center on 27 Jul 2001, the head of a
6-year-old boy was severely smashed by a metal oxygen tank that had been
attracted by the 10-ton electromagnet during a post-operative MRI (magnetic
imaging resonance) exam.  He died two days later.  The exam was intended to
check his progress after a benign tumor had been removed from his brain.
[Source: Child Killed in MRI Machine, by Jim Fitzgerald, Associated Press
Writer, 31 Jul 2001; PGN-ed; this article noted that in March 2001, "an
accreditation team caught the staff altering a patient's chart and
automatically gave it a ranking that was among the lowest in the country."
The article also noted that in 2000 in Rochester, NY, "an MRI magnet yanked
a .45-caliber gun out of the hand of a police officer, and the gun shot a
round that lodged in a wall."

  [RISKS readers have long noted a tendency toward prolonged disregard for
  warnings of severe risks.  Here is a quote on MRI risks from the
  National Institutes of Health in 1987 (courtesy of Lauren Weinstein):

    The National Institutes of Health stress the danger of leaving objects
    that can be magnetized near the machine.  "The most important known risk
    is the projectile effect, which involves the forceful attraction of
    ferromagnetic objects to the magnet," the NIH concluded after a
    conference studying the devices in 1987.]


Date: Tue, 31 Jul 2001 9:57:13 PDT
From: "Peter G. Neumann" <neumannat_private>
Subject: Software is called capable of copying any human voice

An article by Lisa Guernsey in *The New York Times* on 31 Jul 2001 notes
that AT&T Labs will start selling a system called Natural Voices that turns
printed text into speech -- seemingly in the voice of arbitrary individuals
for whom the system has been tailored after analyzing something like 10 to
40 hours of recordings.  The results are quite remarkable in capturing
personal inflections and intonations -- although by no means perfect.

[The technology is of course fascinating.  However, it will undoubtedly lead
to advertisements mimicking the voices of all sorts of famous folks.  The
risks of course are legion (masquerading, fraud, etc.), and raise many
issues such as who owns the rights to a particular person's voice?  This
technology will of course further muddy the legal waters over real vs
simulated characters doing nasty things.]


Date: 23 Jul 2001 01:48:59 -0400
From: stanislav shalunov <shalunovat_private>
Subject: Software safeguards prevent Solar Sail from separation?

It appears that the reason for failure[1] of the recent Solar Sail launch[2]
from a submerged Russian submarine could have been a software bug (excerpted
from [3]):

> A very preliminary examination of the rocket telemetry data in
> Russia indicates that the separation command was terminated by an
> on-board fail-safe program because dynamic variations were sensed in
> the third stage.  The launch vehicle was pre-programmed to override
> the separation command in the presence of dynamic variation.  These
> variations would not have affected the Cosmos 1 test spacecraft
> performance or its recovery.  This possibility is being examined
> further.

It is, perhaps, worth noticing that similar environment monitoring
techniques are reportedly used on some Russian ICBMs to make it harder
to detonate a stolen nuclear warhead without going through a ballistic
missile launch.  These techniques are believed to have a generally low
probability of false positives.

[1] http://dailynews.yahoo.com/htx/ap/20010721/sc/solar_sail_4.html
[2] http://dailynews.yahoo.com/htx/nm/20010720/sc/space_russia_dc_1.html
[3] http://www.planetary.org/solarsail/Media.htm

Stanislav Shalunov		http://www.internet2.edu/~shalunov/


Date: Sat, 21 Jul 2001 11:56:40 +0200
From: Stanislav Meduna <stanoat_private>
Subject: Firefighter's phone lines disrupted because of a SMS hoax

Phone lines of the firefighters in all regions of Slovakia were severely
overloaded for two days as tens of thousands calls were made to it.
The cause was a hoax SMS spreading in the network of one of the
GSM operators stating that it is possible to make free calls using
this number. The GSM operator itself also had minor problems in some
areas. Despite coverage in main news the calls continued also the
next day.

Many people apparently did not recognize that the number is an emergency
one and blindly called it. Even more people forwarded the message
to all friends without thinking of it or trying it.

Risk 1: You don't need any mail client executing scripts to spread
some piece of info faster than the system is able to handle. A plain
old human stupidity fully suffices and in this case endangered
human lives. Don't assume that if one is intelligent enough to use
services such as SMS, he/she won't respond to this kind of hoax.
That particular operator has less than 700 000 customers, the number
of calls made was quoted as tens of thousands. Go figure...

Risk 2: If the originator was smart enough to use web-to-SMS gateway
via some anonymizer, he is practically untraceable (the individual
would be facing 8 to 10 years in prison). The intent of the callers
and forwarders will be much harder to prove and our justice already 
is overloaded enough, so they probably don't have to fear much.


Date: Thu, 26 Jul 2001 00:50:03 +0300
From: Adi Shamir <shamirat_private>
Organization: Weizmann Institute of Science, Faculty of Mathematics
Subject: New results on WEP (via Matt Blaze)

  [Matt Blaze <mabat_private> sent me this item on a practical 
  WEP attack, and put Adi's paper at
  He notes that "as far as I know WEP isn't used for copy protection,
  so it's still legal to disseminate and traffic in this kind
  of information...  

  Ben Laurie <benat_private> suggests that this exhibits two risks
  for the price of one: (1) Expecting WEP to give you what it claims
  (i.e. Wired Equivalence) is RISKing your data; (2) Doing this kind of
  thing and visiting the US is RISKing your liberty.  PGN]

WEP is the security protocol used in the widely deployed IEEE 802.11
wireless LAN's. This protocol received a lot of attention this year, and
several groups of researchers have described a number of ways to bypass its

Attached you will find a new paper which describes a truly practical direct
attack on WEP's cryptography. It is an extremely powerful attack which can
be applied even when WEP's RC4 stream cipher uses a 2048 bit secret key (its
maximal size) and 128 bit IV modifiers (as proposed in WEP2).  The attacker
can be a completely passive eavesdropper (i.e., he does not have to inject
packets, monitor responses, or use accomplices) and thus his existence is
essentially undetectable. It is a pure known-ciphertext attack (i.e., the
attacker need not know or choose their corresponding plaintexts). After
scanning several hundred thousand packets, the attacker can completely
recover the secret key and thus decrypt all the ciphertexts. The running
time of the attack grows linearly instead of exponentially with the key
size, and thus it is negligible even for 2048 bit keys.

Adi Shamir


Date: Wed, 25 Jul 2001 18:30:09 -0400
From: Declan McCullagh <declanat_private>
Subject: FBI hit with Sircam virus that distributes files on your HD

CERT has (ahem, finally) released a Sircam advisory this afternoon:

Sircam is an amazingly noxious critter. I'll give you an example. At Wired
News, like other news organizations, we have feedback addresses so people 
can send us thoughts on articles. Those have been the same for at least 
three years, so they're well-known and available to programs like Sircam 
that scan hard drives for e-mail addresses.

Since 1 am ET 24 Jul 2001, we've received about 150 MB of mail directed at
those addresses, the vast bulk of it Sircam output. A quick scroll through
the messages says about 90 percent of it by message and probably 99 percent
of it by size is due to Sircam.

Dave Farber wrote on his Interesting People list:

> The person/group who launched the SirCam virus should get the first 
> Cyberspace death-- namely permanent banishment from any network access any 
> place in the world.  We yell endlessly about spam mail but one mess like 
> this makes spam mail almost interesting.

Which I heartily endorse.


  [Declan appended Ted Bridis's *Wall Street Journal* item on 25 Jul 2001,
  sent to him by Ted:
  The essence of that article is that the FBI's cyberprotection unit
  accidently sent private FBI documents by e-mail outside of the FBI.
  It appears that this was the result of the Sircam virus infecting
  an FBI internal computer.  PGN-ed]


Date: Sat, 28 Jul 2001 20:32:49 EDT
From: Ken Knowlton <KCKnowltonat_private>
Subject: Super-accurate atomic clock hates Sundays

The large electronic Millennium Clock display at Ottawa's National Research
Council has been losing an hour every Sunday.  although the clock itself
remains accurate to within a few millionths of a second per year.  The
problem appears to stem from botched software to handle the daylight savings
cutover on 1 Apr 2001.  Incidentally, the display includes a plaque saying
that the Millennium Clock ``celebrates Canada's rich history of leadership
in timekeeping.''  Apparently, the display had been plagued by problems
since it was installed in June 1999 to celebrate the turn of the century,
and intended to exist only through the Y2K cutover.  [Source: Reuters, 30
Apr 2001, from AOL's "News of the Weird"; PGN-ed]

  [Note the unrelated Millennium clock problem reported by Mike Palmer
  in RISKS-21.20.  PGN]


Date: Fri, 20 Jul 2001 07:49:48 -0400
From: Gary Stock <gstockat_private>
Subject: Risks of relationships online

A reminder: 'FRISKY' is just a big F-Y with 'RISK' in the middle :-)


Husband's internet date turns out to be his wife

A married couple in China ended up brawling after realising they had
unwittingly courted each other over the internet.

The pair from Beijing sneaked online to flirt with their mystery girlfriend
and boyfriend at a chat website called the Green, Green Schoolyard.

After a month, the man arranged to meet up with his ideal new friend only to
discover it was actually his wife. He had known only her user name, I Want

They each agreed to carry a certain newspaper to identify themselves, but
were shocked when they came face-to-face and started fighting in the street.

Passers-by eventually alerted security guards who had to separate the two,
reports Norway's main news agency NTB.

Gary Stock, UnBlinking  gstockat_private  http://unblinking.com/


Date: Fri, 20 Jul 2001 10:09:19 -0400
From: "Greg Searle" <greg_searleat_private>
Subject: Apple DNS Entry hacked

I just happened to look up apple.com (this morning), and here is what came out:

Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.


To single out one record, look it up with "zzz", where zzz is one of the
of the records displayed above. If the records are the same, look them up
with "=zzz" to receive a full display for each record.

>>> Last update of whois database: Fri, 20 Jul 2001 01:56:29 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and

  [Note: "x"s changed to "z"s to avoid filtering!  PGN]


Date: Mon, 23 Jul 2001 19:34:16 -0400 (EDT)
From: mercuriat_private
Subject: University of Pennsylvania cable cut

According to the ISC Network Operations Center <nocat_private>, at
5:15pm on 23 Jul 2001, more than a dozen buildings lost their network
connectivity, due to a fiber cut.  [The NOC-wors(h)t is yet to come?  PGN-ed]


Date: Mon, 23 Jul 2001 12:22:36 -0400
From: "Richard J. Barbalace" <rjbarbalat_private>
Subject: Cell phones overload 911 in Denver

The *Rocky Mountain News* reports that Denver's 911 call centers are being
overwhelmed by increasing numbers of phone calls, some of which are never
answered because of staffing problems.  A tragedy has not happened yet, but
the story suggests this is mere luck, noting a shooting in which 911 reports
were ignored.  One-touch 911 buttons make calling easier.  Many calls
now come in to report a minor accident, instead of just a few.  [PGN-ed]

  Then there are the calls operators receive by accident, when someone
  jostles their phone in their purse, pocket or on their utility belt.
  Construction workers, in particular, often dial 911 by mistake while
  leaning over guardrails to assess their work.  "We can hear their entire
  conversation, but they can't hear us because of all the background noise,"
  Hilburn said. "This is a really common thing for us."

The risk is making it too easy for everyone to contact help in an emergency,
resulting in a type of unintentional denial of service attack.

The full article is at:

Richard J. Barbalace <rjbarbalat_private>


Date: Tue, 24 Jul 2001 11:48:40 -0500 (CDT)
From: Richard Kaszeta <kaszetaat_private>
Subject: Qwest Wireless erroneously overbills customers by thousands of dollars

According to

Qwest Wireless apparently had a major error in their billing software,
and appeared to be billing customers at hundreds of dollars per minute
for usage in excess of their alloted monthly limits.

Quoting the article:

  One Minneapolis customer received a bill for $57,346.20.

  Some 14,000 of Qwest's wireless phone customers in 14 states were vastly
  overcharged, said spokesman Bryce Hallowell. The errors resulted from a
  glitch in a new Qwest computerized billing system.  Customers whose calls
  exceeded the number of free minutes on their wireless calling plans were
  billed at excessive rates.  The glitch has since been corrected.

Richard W Kaszeta <richat_private>  http://www.kaszeta.org/rich


Date: Fri, 20 Jul 2001 11:14:26 -0400
From: Bill McGonigle <mcgonigleat_private>
Subject: Re: FBI arrests Russian hacker visiting U.S. for alleged DMCA breach 
  (McCullagh, RISKS-21.53)  

Interesting that this one slipped through the crack without an analysis of
the real risk involved here.  This 'russian hacker' (or 'employee of a
Russian data recovery company' some might say) did his work for a company in
Russia; the company distributed their from there.  As far as I know the DMCA
is a US law and doesn't apply to overseas activities.  Regardless,
Mr. Sklyarov's activity in the US was giving a speech.  The risk here is
assuming a country with supposed constitutional protection for free speech
won't throw you in the clink for the same (or for pissing off a US company).


Date: Fri, 27 Jul 2001 07:50:43 +0100
From: Harry Erwin <harry.erwinat_private>
Subject: More on the risk of moving and identity theft (Re: RISKS-21.54)

The card was requested from a phone in Richmond, Virginia, after I filed a
change of address with the Virginia DMV.  Virginia drivers licenses have the
SSN as the default identifier.  Within a week, charges were being made using
the fraudulent card in Florida and California.

Harry Erwin, University of Sunderland. Computational neuroscientist modeling
bat bioacoustics and behavior. <http://world.std.com/~herwin>

  [Virginia was where in 1991 DMV employees were fraudulently giving out
  bogus licenses.  See the lead item in RISKS-11.41.  PGN]


Date: Mon, 30 Jul 2001 09:54:29 -0800
From: Rob Slade <rsladeat_private>
Subject: REVIEW: Bruce Schneier, "Secrets and Lies: Digital Security in a Networked World"

BKSECLIE.RVW   20001022

"Secrets and Lies: Digital Security in a Networked World", Bruce
Schneier, 2000, 0-471-25311-1, U$29.99/C$41.95
%A   Bruce Schneier schneierat_private
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2000
%G   0-471-25311-1
%I   John Wiley & Sons, Inc.
%O   U$29.99/C$41.95 416-236-4433 fax: 416-236-4448 pfurlongat_private
%P   412 p.
%T   "Secrets and Lies: Digital Security in a Networked World"

"Secrets and Lies" has generated a great deal of interest in the security
community this year.  Much of this interest probably stems from the simple
fact that it isn't every day (or every year) that you get a general security
book, written for the non-specialist, produced by a major name in the field.
But one point seems to have been glossed over in the praise for this work.
Schneier's writing is lively, entertaining, and even playful throughout the
entire book.  Not only is this volume a realistic and useful view of the
security enterprise, but it's a lot of fun.

As the author of "Applied Cryptography," the leading text in the field; the
founder of Counterpane Systems, with its major influence in encryption
consulting; and the publisher of the Crypto-Gram newsletter, regular and
thoughtful analyses of major encryption related issues; Bruce Schneier is,
among the technically and cryptographically knowledgeable, arguably more
influential than many academics whose names might be more widely known in
relation to specific algorithms.  So when Schneier states, in the preface,
that cryptography is not "The Answer(TM)" to security, you have to take him
seriously.  He goes on, in the introductory chapter, to point out that "The
Answer(TM)" does not exist: securing complex systems is a hard job purely
because the systems are complex, and any easy answer is bound to be wrong.
The price of digital reliability is constant vigilance.  As such, don't come
looking to this work for easy answers or cookbook solutions.  What you will
find is a solid introduction, and more, to the problems you have to overcome
to keep your information safe, and some guidelines on how to go about the

Part one is an overview of the field of network operations with a view to
restricting some ideal definition of "secure" to a more achievable goal.
Chapter two describes a number of digital threats (aside from the mention of
salami attacks, quite realistically) and points out that none of the crimes
are new, although the extreme of accessibility is.  Various attacks, and
various motivations, are reviewed in chapter three.  The discussion of
different types of adversaries, in chapter four, provides a reasonable
assessment of the whole range from script kiddies to infowarriors, and
compares relative levels of competency and risk tolerance.  Chapter five
outlines security needs and, again, points out that all computer security
measures have their origins in physical security practices we all take for

Part two looks at the various technology components of security and security
systems.  The writing in this section is a little more mundane and less
sparkling than other parts of the book, but the material is reliable and
convincing.  Chapter six is, of course, an excellent primer on the basic
concepts and applications of cryptography.  The analysis is extended to
"real world" limitations and faults with encryption in chapter seven,
including an intriguing comparison of proprietary protocols and alternative
medicine.  Chapter eight discusses computer security in broad terms, but
concisely expresses concepts and models that many other books waste pages on
without ever making the fundamentals clear.  (It also provides some amazing,
and occasionally amusing, glimpses into the lack of security in Microsoft's
Windows.)  Authentication is described well in chapter nine.  Chapter ten is
oddly unstructured.  Entitled "Networked- Computer Security" it starts off
with viruses and malware, talks a bit about operating system architecture,
and ends up with some Web insecurities.  While there are errors
(particularly in the virus section) most of the material is not really bad:
it just seems strange in comparison to the earlier chapters.  Network
Security, in chapter eleven, returns to the original level of focus, and
explains various concepts using TCP/IP as an example.  Chapter twelve takes
a depressing, but accurate, look at the major network security tools, as
well as making the important, though counterintuitive, point that false
alarms can be worse than no security at all.  Software reliability gets a
fairly standard treatment in chapter thirteen, and much the same is true of
hardware security in chapter fourteen.  As might be expected, the coverage
of certificates and the public key infrastructure, in chapter fifteen,
clearly sets forth all necessary considerations and weak points to examine.
Technical books usually have some catch-all chapters, but not all of them
admit it up front.  Chapter sixteen touches on a number of tricks that
people have relied on to protect data, and uses devastating logic to point
out why said stunts don't work.  Finally, in chapter seventeen, we come to
the largest source of security problems, and the one we can't do anything
about: people.

The first two parts look at problems.  Part three tries to present some
solutions, or at least approaches to solutions.  Chapter eighteen describes
the vulnerability landscape, and suggests following the process of attacking
a system, in order to identify how much security is needed at certain
points, and weak areas that may need to be reinforced somehow.  (This is a
far cry from the "how to hack" tools lists of some of the more sensational
"security" books, and much more useful.)  Risk assessment, in chapter
nineteen, is reasonable and balanced, but not great.  Chapter twenty is
disappointing, in that it is entitled "Security Policies and
Countermeasures" but concentrates on a series of specific examples of good
and bad security systems.  Elsewhere the book promotes the fact that without
a policy you have no security.  It therefore seems a bit of an abdication of
the topic to leave it without much discussion of the actual production of a
policy.  Attack trees might be seen as yet another example of a tool more
useful to the security breaker than the sysadmin, but chapter twenty one's
explanation shows how it can structure the task of analyzing protective
measures.  This process is far more likely to succeed than a vague
injunction to secure everything, and this chapter alone probably makes this
work a "must have" for every security library.  Product testing, in chapter
twenty two, deals mostly with how *not* to evaluate software, and includes a
good discussion of full disclosure and the open source movement.  However, I
can definitely sympathize with the position of the latter part of the
chapter: potential security is pointless, what really counts is how secure a
system is when set up by the typical harried administrator.  The future is
usually left for last, but Schneier takes a solid look at likely trends and
paints an alarming, if not completely apocalyptic, picture.  Chapter twenty
four supports one of the major theses of the book: security is a process,
not a product.  Therefore, the chapter provides a set of guidelines,
attitudes, points, and general principles to be used in looking at security
as a process.  The conclusion, in chapter twenty five, seems to be that lots
of people are trying to avoid their proper responsibility for security, but
the task is achievable.

Quite apart from the general readability of the text, Schneier has ensured
that the content and explanations are accessible to any intelligent reader.
You do not need specialist training to understand the concepts presented
herein.  And the concepts encompass pretty much everything to consider about
security in a networked world.  This is one of the very few books that I
feel I can recommend without reservation to a newcomer concerned about
computer or communications security.  It presents the situation clearly,
with real explanations of the dangers, but no overpromoted sensationalism.
If the volume seems a bit long all I can say, with Schneier, is that
security is complex.  The book has very little wasted space.

I can also say that security professionals will not regret time spent with
it.  We tend to need more frequent reminding than teaching, and the
comprehensive coverage touches on many issues that are important, but may be
ignored as not always being urgent.  However, the book also does an
excellent job of explaining some specialty and esoteric topics.  Hopefully
"Secrets and Lies" will have a prominent position on many security library

copyright Robert M. Slade, 2000   BKSECLIE.RVW   20001022
rsladeat_private  rsladeat_private  sladeat_private p1at_private
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


Date: 12 Feb 2001 (LAST-MODIFIED)
From: RISKS-requestat_private
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) 
 if possible and convenient for you.  Alternatively, via majordomo, 
 send e-mail requests to <risks-requestat_private> with one-line body
 which requires your confirmation to majordomoat_private .  
 [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
 this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
 Lower-case only in address may get around a confirmation match glitch.
   INFO     [for unabridged version of RISKS information]
 There seems to be an occasional glitch in the confirmation process, in which
 case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
   .MIL users should contact <risks-requestat_private> (Dennis Rears).
   .UK users should contact <Lindsay.Marshallat_private>.
=> The INFO file (submissions, default disclaimers, archive sites, 
 copyright policy, PRIVACY digests, etc.) is also obtainable from
 http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
 The full info file will appear now and then in future issues.  *** All 
 contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
 ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
   [volume-summary issues are in risks-*.00]
   [back volumes have their own subdirectories, e.g., "cd 20" for volume 20]
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
   Lindsay Marshall has also added to the Newcastle catless site a 
   palmtop version of the most recent RISKS issue and a WAP version that
   works for many but not all telephones: http://catless.ncl.ac.uk/w/r
 http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
 http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    http://www.csl.sri.com/illustrative.html for browsing, 
    http://www.csl.sri.com/illustrative.pdf or .ps for printing


End of RISKS-FORUM Digest 21.55

This archive was generated by hypermail 2b30 : Tue Jul 31 2001 - 16:24:21 PDT