Risks Digest 22.35

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Tuesday 5 November 2002  Volume 22 : Issue 35

   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, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.35.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
Online job listing an ID theft scam (Monty Solomon)
Want a driver's license?  How about an ID card instead? (Mark Richards)
The FBI Has Bugged Our Public Libraries (Bill Olds via Forno and Farber)
What if they held an election and the pundits had nothing to say? (NewsScan)
Vote-by-mail in Oregon (Andrew Morton)
Software leaves encryption keys, passwords lying around in memory 
  (Peter Gutmann via Monty Solomon)
Risks of non-obvious user interfaces (Harry Erwin)
Why Telemarketing Is Evil (Neil McManus via Monty Solomon)
Re: BBC News: Fake bank website cons victims (Hal Murray)
Re: Windows daylight saving and file time-stamp (Graham Mainwaring)
Re: Risks of dual-boot systems (Scott Nicol, Tony Finch, Colin Andrew Percival,
  Nick Rothwell, David Crooke)
Wireless networking and security: CERIAS/Accenture roundtable (Gene Spafford)
REVIEW: "Internet Security Dictionary", Vir V. Phoha (Rob Slade)
Digital System Design DSD 2003 cfp (Henry Selvaraj)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 5 Nov 2002 01:29:52 -0500
From: Monty Solomon <monty () roscom com>
Subject: Online job listing an ID theft scam
 
'Background check' used to steal full slate of personal info     
By Bob Sullivan, MSNBC, 4 Nov 2002

It was just the job lead Jim needed: a marketing manager position with
Arthur Gallagher, a leading international insurance broker. And only days
after Jim responded to the job posting on Monster.com, a human resources
director sent along a promising e-mail. We're interested in you, the note
said. The salary is negotiable, the clients big. In fact, the clients are so
valuable and sensitive that you'll have to submit to a background check as
part of the interview process. Eager for work, Jim complied -- and sent off
just about every key to his digital identity, including his age, height,
weight, Social Security number, bank account numbers, even his mother's
maiden name.  IT WAS ALL JUST an elaborate identity theft scam designed to
prey on the most vulnerable potential victims - the increasing ranks of the
unemployed.  ...
  http://www.msnbc.com/news/830411.asp

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

Date: Mon, 4 Nov 2002 21:59:35 -0500
From: Mark Richards <mark.richards () massmicro com>
Subject: Want a driver's license?  How about an ID card instead?

As reported by the Associated Press, 4 Nov 2002, the Massachusetts Registry
of Motor Vehicles' new online renewal system issued Massachusetts
identification cards instead of renewed driver's licenses to 3,600 drivers
requesting renewals between 21 and 23 Oct.  The RMV's request to Digimark
Corporation (which prints the licenses) apparently erroneously included a
field indicating ID cards had been requested.  The problem was then caught
and corrected.  (Each license costs the RMV $1.77.)  [PGN-ed]

[Not mentioned in the article:] The recent (but now former) head of the RMV,
Daniel Grabauskas, is a political appointee who claims to have reformed the
agency and improved efficiency.  On that basis, he is running for State
Treasurer.  On the eve of a State-wide election, this revelation of goof
does not have the most beneficent timing.

http://www.boston.com/dailynews/308/region/Online_license_renewals_fouled:.shtml

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

Date: Tue, 05 Nov 2002 16:40:41 -0500
From: Richard Forno <rforno () infowarrior org>
Subject: The FBI Has Bugged Our Public Libraries (from Dave Farber's IP)

  [Source: A long and provocative article by Bill Olds, *The Hartford
  Courant*, 3 Nov 2002, excerpted here; PGN]
  http://www.ctnow.com/features/lifestyle/hc-privacy1103.artnov03col.story

Some reports say the FBI is snooping in the libraries.  Is that really
happening?  Yes. I have uncovered information that persuades me that the
Federal Bureau of Investigation has bugged the computers at the Hartford
Public Library.  And it's probable that other libraries around the state
have also been bugged. It's an effort by the FBI to obtain leads that it
believes may lead them to terrorists.

Many members of the public regularly use computers in libraries to access
the Internet for research purposes or to locate information about particular
interests. It's also not uncommon for students and others to communicate
with friends and relatives through e-mail from there.

The FBI system apparently involves the installation of special software on
the computers that lets the FBI copy a person's use of the Internet and
their e-mail messages. (Don't ask me how I know about this because I can't
reveal how I was able to collect the information.) Members of the public who
use the library have not been informed that the government is watching their
activities. It's not just the computers. Circulation lists that show which
books someone borrowed are also accessible to the government.

What are the Hartford librarians saying?

"I can't disclose that we were presented with anything," said Louise
Blalock, Hartford's head librarian.

I asked Mary W. Billings, the library's technical services manager, if the
FBI had given her a subpoena or a court order for library information. Her
response: "I cannot answer that question."   [...]

  [Bill Olds, c/o *The Hartford Courant*, Features Department, 
  285 Broad St., Hartford, CT 06115 or docbillo () yahoo com]

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

Date: Tue, 05 Nov 2002 08:14:58 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: What if they held an election and the pundits had nothing to say?

Modern elections have become so much more than counting the votes: they've
become opportunities for political analysts to show off by projecting the
results before the votes are counted, as well as by using demographic data
and exit polls to explain to the politically unwashed what it all really
means, deep down. But there's one little glitch this time: last-day computer
problems with the new system of the Voter News Service, the consortium of
news organizations that does the exit polling. CNN's Tom Hannon said of the
new system yesterday: "It is brand-new and has never been test-driven. This
is the equivalent of a NASA space shot without any test runs. We are going
to learn a few things tomorrow night in real time."  [Great.] Gerald M. Boyd
of the New York Times says: "The use of exit polls has been particularly
important in terms of trying to get a sense of national trends or moods, so
without it, we would have to do the best we can." [And the rest of us will
just have to soldier on bravely.]  [*The New York Times*, 5 Nov 2002;
NewsScan Daily, 5 November 2002]
  http://partners.nytimes.com/2002/11/05/politics/campaigns/05VNS.html

  [A tangible benefit of exit polls arises in the use of today's
  all-electronic voting systems that have essentially zero accountability
  that your vote is correctly recorded and counted: if the exit polls differ
  radically from the officially tabulated reported results, then one might
  have good reason to suspect fraud that would otherwise be largely
  undetectable, or perhaps some egregious internal mishaps.  PGN]

  [The *Times* item was also noted by Ian Alderman, who included this quote:
    "Without all the states, the papers count on the demographic and other
    details from the national poll to explain the reasons for the election
    results in their articles the next day. But Mr. Savaglio said Voter News
    Service could analyze the data for its national poll only after it
    finished analyzing its data by state. That makes the national poll the
    most vulnerable to any problems."
  PGN]

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

Date: Tue, 05 Nov 2002 12:12:40 -0800
From: andrew morton <drewish () katherinehouse com>
Subject: Vote-by-mail in Oregon (Re: Smith, RISKS-22.34)

The ballot originally mentioned was the state of Oregon's. In Oregon, every
ballot is essentially an absentee ballot, they're mailed out several weeks
before the Nov 5th deadline, voters complete the optically scanned ballots
at their leisure and in the privacy of their own home.  Voters are allowed
plenty of time to make their decisions and ensure that the ballot is marked
correctly. The voted ballot can either be dropped off at a collection point
or mailed so that (regardless of postmark) it is received by 8:00 pm on
election day. More details about the system can be found on the Secretary of
State's website.
  http://www.sos.state.or.us/executive/policy-initiatives/vbm/execvbm.htm

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

Date: Wed, 30 Oct 2002 22:31:46 -0500
From: Monty Solomon <monty () roscom com>
Subject: Software leaves encryption keys, passwords lying around in memory

  http://online.securityfocus.com/archive/82/297827 

Date: Thu, 31 Oct 2002 05:11:31 +1300 (NZDT)
From: pgut001 () cs auckland ac nz (Peter Gutmann)
Subject: Software leaves encryption keys, passwords lying around in memory

The following problem was first pointed out (in private mail) by Michael
Howard from Microsoft.  His writeup is now available at
  http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp.  
> From a representative check of a few widely-used open source crypto
programs, this affects quite a bit of software.

The problem he points out is that clearing sensitive information such as
encryption keys from memory may not work as expected because an optimising
compiler removes the memset() if it decides it's redundant.  Consider for
example the following:

int encrypt( const void *key )
  {
  puts( key );     /* Normally we'd encrypt here */
  }

void main( void )  /* Because we can */
  {
  char key[ 16 ];
        
  strcpy( key, "secretkey" );
  encrypt( key );
  memset( key, 0, 16 );
  }

When compiled with any level of optimisation using gcc, the key clearing
call goes away because of dead code elimination (see the MSDN article for
more details on this, which uses VC++ to get the same effect).  While you
can kludge enough stuff around a custom memory-clear call to fool the
optimiser (hacks with 'volatile', touching the memory after it's cleared and
hoping the optimiser is fooled, etc etc) there's no guarantee that it'll
work for anything but the compiler(s) you happen to test it with - any
future enhancement to the optimiser may turn it back into a nop.  What it
really needs is the addition of a #pragma dont_remove_this_code_you_bastard
in the compiler.  Until then, a lot of security code will be affected by
this problem.

  [In RISKS, I tend never to alter British spellings.  However,
  in American English, an "optimiser" must be the ultimate miser.]

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

Date: Tue, 5 Nov 2002 16:02:05 +0000
From: Harry Erwin <herwin () theworld com>
Subject: Risks of non-obvious user interfaces

I'm using a product called WebCT to web-enable a couple of classes that I'm
teaching in the UK. I find I have students listed by WebCT as not having
submitted a project, but when I download the project files, why there they
are! Apparently the students have to take some positive action other than
simply submitting the project for the software to believe they submitted
it. There doesn't appear to be any mechanism, either, for logging marks for
students who did this or submitted the project via some other mechanism. I
used to teach at George Mason University (VA), where we used a similar
package developed at the University of Maryland. The difference was that the
UMD developers actually seemed to have thought through this stuff.

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

Date: Wed, 30 Oct 2002 01:23:49 -0500
From: Monty Solomon <monty () roscom com>
Subject: Are you bothered by telemarketing?

Why Telemarketing Is Evil
Neil McManus, CHEAT SHEET, wired.com, Issue 10.11 - Nov 2002

Telemarketers may be relentless, exasperating, even unethical. But you have
to give them this: They're good. With the help of technology - everything
from autodialing software to cheap overseas labor connected by fiber optics
- they've turned phone solicitation into a $270 billion industry.  The key
to the telephonic onslaught is predictive dialing, a breakthrough of the
mid-'90s. These systems churn through huge databases of phone numbers,
weeding out busy signals and out-of-service numbers, and routing answered
calls to agents. They are mercilessly efficient: Out of an 8-hour day,
agents can work the phones a staggering 7.2 hours. One loan company calling
deadbeat borrowers boosted "promises to pay" by 129 percent.  [...]

  [Nice article.  Read it in its entirety.  PGN]
http://www.wired.com/wired/archive/10.11/start.html?pg=9

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

Date: Tue, 05 Nov 2002 02:44:33 -0800
From: Hal Murray
Subject: Re: BBC News: Fake bank website cons victims (Leeson, RISKS-22.34)

The PayPal scam mentioned in RISKS 22.34 was relatively recent.

The technology was developed several years ago on AOL.  It was common enough
that it inspired the coining of a new term - phishing (for passwords and/or
credit card numbers).  The part I know about was mostly used by spammers.
With a password, they could use the victims AOL account to send spam.  With
a credit card, they could sign up for more throw-away dial-up accounts to
use for spamming.

Feed aolbilling to google-groups for more than you want to know:
aolbilling.com is currently registered to somebody in Korea.

Here is a URL from May, 2000 describing the second wave - Yahoo, Hotmail...
  http://news.com.com/2100-1023-240295.html?legacy=cnet&tag=st.ne.ron.lthd.ni

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

Date: Tue, 5 Nov 2002 15:22:27 -0500 (EST)
From: Graham Mainwaring <graham () mhn org>
Subject: Re: Windows daylight saving and file time-stamp (Jakeman, R-22.34)

In RISKS-22.34, Chris Jakeman reports that Windows "changes the time stamp
on all of its files" when the local time is adjusted due to Daylight Savings
Time. Windows does in fact get it wrong, but not in the way that Mr. Jakeman
describes. Windows, like Unix, stores time stamps as GMT/UTC time. All file
system transactions are performed using this internal representation. When
times are displayed to the user, they are reported in the currently
applicable local time, as adjusted. When the time change occurs, there are
no retroactive changes made to the contents of the filesystem.

The nature of the error is this: On most Unix variants, when a GMT time
value is formatted for display to the user, the locale or timezone files are
consulted to determine whether DST was in effect at the time in question. So
a file that was created at 5:00pm (US) EST on March 1st, 2002 will always be
reported as 5:00pm. Windows, on the other hand, appears to calculate whether
DST is applicable *right now* and apply this offset to all dates
indiscriminately. So a file created at 5:00pm EST on March 1st, 2002 will
say "5:00pm" until the time change occurs on April 7. After that, the
one-hour offset is applied, so this file is now reported to have been
created at 6:00pm EDT. Which is sort of technically correct: If you
interpret "EDT" to be a permanent timezone that is offset by one hour, and
the time change as a movement of a region between EST and EDT, then
reporting the time as "6:00pm EDT" is not actually wrong. It is, however,
very misleading.

The lesson to be learned is that if you are doing any sort of date
comparison, date processing, etc., you really want to compare GMT to GMT
times, not local to local times. If you do all internal processing in GMT
then you don't have to know or care what time zone all your users are
located in. If Mr. Jakeman's replication software had made its comparisons
this way, it would have behaved correctly.

Also note that this specific problem's first mention in RISKS (as far as I
can determine) was in RISKS-6.55 (April 1988) as "Yet Another UnTimely
Risk." The tone of the article was woeful that software engineers had
continued to fail to implement correct solutions to this well-known problem
- and that was more than fourteen years ago. There is also an interesting
reference in RISKS-6.70 to what I assume was the forerunner of the Gnu libc6
locale system.

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

Date: Mon, 4 Nov 2002 21:53:49 -0500
From: "Scott Nicol" <snicol () apk net>
Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34)

This is a well-known problem, and it seems to crop up in risks twice a year.
Windows 98 stores the local time, Windows 2000 stores GMT and calculates the
offset to the current time.  Windows 98 is the real culprit here.  Windows
NT/2000/XP do the right thing, as does unix.  I have no idea what older
MacOS versions do, but I assume OS X does the right thing, too.

Hopefully in a few more years, Windows 98 (also 95 and me) will be dead and
buried.

  [In a response to Graham Mainwaring's item above, Scott also noted
  that "Up until about 5 years ago, RCS and CVS got this wrong."  
  John Trammell said he would not blame this on dual-boot systems.
  "Perhaps a better description of the problem is 'not playing well with
  others,' or more simply, not following the Golden Rule.  PGN]

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

Date: Tue, 05 Nov 2002 03:24:36 +0000
From: Tony Finch <dot () dotat at>
Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34)

It's good to see that the old jokes are still the best.

RISKS items on this specific summer time problem include
(numbers are volume.issue.subject.item from the catless/risks.org archive):

18.3.2.1
18.96.3.1
19.6.9.1
19.11.6.1
19.12.14.1
19.64.7.1

Hilarious. There are at least ten times as many other RISKS articles on
other summer time problems, if you're after more laughs. I think I'd bust a
gut if I listed them all here!  My favourite variation on this theme is the
Windows 95 bug that would set the clock back when summer time ended, then
again an hour later (because that's when summer time ends), and again an
hour later... Who needs to reboot into another OS? What a pity that planned
obsolescence deprives us of such entertainment!

Tony.  f.a.n.finch  <dot () dotat at>  http://dotat.at/

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

Date: Tue, 5 Nov 2002 05:43:08 -0800 (PST)
From: Colin Andrew Percival <cperciva () sfu ca>
Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34)

The problem of adjusting for DST twice is not restricted to dual-boot
systems.  Last year, my computer (running windows 2000) adjusted itself
automatically from 2AM to 1AM; I rebooted it at roughly 1:30AM; and half an
hour later it adjusted itself back to 1AM again.  One imagines that if a
"Reboot" task was scheduled for 1:30AM, the machine might cycle
indefinitely.

While this particular bug has hopefully been fixed by now, the multitude 
of DST-related problems suggests that using UTC (or, even better, TAI) 
internally and treating DST (and leap seconds) as time zones -- restricted 
to user interface purposes only -- would be a much better solution.

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

Date: 5 Nov 2002 13:50:47 -0000
From: Nick Rothwell <nick () cassiel com>
Subject: Re: Risks of dual-boot systems

This is an old problem - we first encountered it about five years ago when
we started building dual-boot Linux/Windows boxes. The only sensible
approach to daylight-savings on such systems is to keep the hardware clock
on UTC and let the operating systems maintain their own local
offsets. Windows systems have, as far as I know, never had this option
(perhaps to discourage users from dual-booting into a competing operating
system?).

I allow Linux to do the Right Thing (hardware UTC, software adjustment) and
when I need to boot into Windows during the summer I just disable the
taskbar clock and use my wristwatch.

nick rothwell -- composition, systems, performance -- http://www.cassiel.com

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

Date: Mon, 04 Nov 2002 19:34:41 -0600
From: David Crooke <dave () convio com>
Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34)

I'd be interested to know the justification for using a dual-boot PC for a
mission critical *anything*.  Personally I wouldn't use Windows at all, far
less a system that isn't even active some of the time, subject to the whims
of a user.

It's yet another example of legacy functionality (MS-DOS requires the
hardware clock to be in current local time as it has no timezone support, so
DOS-based Windows has a workaround, ...) propagating for years and years
into unrelated and inappropriate environments (Win 3.x -> Win 9x -> NT ->
NT5).

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

Date: Mon, 4 Nov 2002 09:48:11 -0500
From: Gene Spafford <spaf () cerias purdue edu>
Subject: Wireless networking and security: CERIAS/Accenture roundtable

In May 2002, CERIAS and Accenture convened a roundtable of experts on
wireless networking and security.  The group met for 2 days to discuss the
security challenges associated with wireless networking.  The results of
that roundtable discussion are now available online.  
  http://www.cerias.purdue.edu/securitytrends/ 
for the full report, executive summary, and "best practices" document.

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

Date: Tue, 5 Nov 2002 08:00:52 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Internet Security Dictionary", Vir V. Phoha

BKINSCDC.RVW   20020824

"Internet Security Dictionary", Vir V. Phoha, 2002, 0-387-95261-6,
U$39.95
%A   Vir V. Phoha
%C   175 Fifth Ave., New York, NY   10010
%D   2002
%G   0-387-95261-6
%I   Springer-Verlag
%O   U$39.95 212-460-1500 800-777-4643 mspano () springer-ny com
%P   259 p. + CD-ROM
%T   "Internet Security Dictionary"

There are a few decent computer dictionaries extant, and at least a half
dozen really good communications dictionaries among the many that have been
published.  However, until this, there was no security dictionary available
in printed form, and there has been a need for one.  (In fact, I've been
working on one for a while, so, boring as it may be, I have to declare yet
another possible conflict of interest.)

There are 1,400 terms defined, but a number are simply minor variations on a
theme.  (There are, for example, twelve phrases beginning with "access.")
Much of the material is based the old US military terminology from the (now,
generally) superseded "Rainbow series" (which is listed), and so there are a
number of traditional but obsolete expressions.  Some new and slang terms
have been included, but some of these are only very vaguely related to the
security topic.  (The phrase "ankle-biter" is defined as a synonym for
"script kiddie," but this term is generally used for a young, or
inexperienced, neophyte in any technical field, and doesn't have a specific
meaning in security.)  Definitions tend to be terse, and may lack necessary
detail.  (The definition of "Chernobyl packet" seems to fit a smurf attack
[also listed], but, due to the lack of information, it is impossible to
tell.)  An attempt has been made to make sure the material is up to date:
Carnivore is listed (but not wardialling or wadriving).  (The definitions
for virus and worm are, as usual, unfortunate.)

Overall, despite the problems, this is a useful reference.  Primarily, of
course, this is because it is the first of its type.  However, it does cover
a reasonable range of the security field, and is, for the most part,
reliable within limits.  However, I would hope that the content is updated,
expanded, and improved relatively soon, and regularly thereafter.

copyright Robert M. Slade, 2002   BKINSCDC.RVW   20020824
rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: Fri, 01 Nov 2002 11:35:59 -0800
From: Henry Selvaraj <selvaraj () unlv edu>
Subject: Digital System Design DSD 2003 cfp

DSD 2003: EUROMICRO SYMPOSIUM ON DIGITAL SYSTEM DESIGN
Architectures, Methods and Tools
Antalya, Turkey, September 3-5, 2003
Submission date for papers: 3 Mar 2003
http://www.egr.unlv.edu/~selvaraj/dsd03

The Symposium on Digital System Design addresses architectures and
implementations of (embedded) digital systems, as well as efficient design
methods and tools. It is a premier discussion forum for researchers and
engineers working on state-of-the-art investigations, development, and
applications of digital systems, processor and memory architectures,
application specific processors, systems-on-a-chip, hardware/software
co-design, circuit design, system validation, and design automation.

The main areas of interest are Processor and memory architectures; Special
architectures; Specification and modeling; Validation; Synthesis;
Systems-on-a-chip; Applications of (embedded) digital systems  [PGN-ed]

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

Date: 29 Mar 2002 (LAST-MODIFIED)
From: RISKS-request () csl sri com
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-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 If Majordomo balks when you send your accept, please forward to risks.
 [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-request () pica army mil> (Dennis Rears).
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> 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 risks () CSL sri com 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 21" for volume 21]
 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 22.35
************************