[3930] in RISKS Forum
Risks Digest 24.13
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed Dec 28 19:35:23 2005
From: RISKS List Owner <risko@csl.sri.com>
Date: Wed, 28 Dec 2005 16:35:08 PST
To: risks@mit.edu
RISKS-LIST: Risks-Forum Digest Weds 28 December 2005 Volume 24 : Issue 13
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/24.13.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Oil blaze hits hospital systems (Paul Bennett, Pete Mellor)
The drunks may save our election system (Danny Burstein)
Risks of spreadsheets (Fernando Pereira)
James Reason on Absent-mindedness and risk management (James Cameron)
Yet another leap year error (Bruce Hamilton)
Kansas Lottery Picks Same Number Three Nights in a Row (PGN)
No one lost or made $225 million... (Bob Heuman)
Re: A Little Sleuthing Unmasks Writer of Wikipedia Prank (Ian Halliday)
Re: In-car GPS navigation (Gary G. Taylor, Dan Jacobson, Sean Dunn,
Alex Colvin)
Re: False WHOIS Data Still Bedevils (Dag-Erling Smørgrav, Dave Bell)
Re: Miniature Golf Course on Terror Target List (Rick Jones via PGN)
Countering Trusting Trust through Diverse Double-Compiling
(David Wheeler via Curt Sampson)
REVIEW: "The Art of Computer Virus Research and Defense", Peter Szor
(Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 13 Dec 2005 17:23:56 -0000
From: Paul.Bennett@jet.uk (Paul Bennett)
Subject: Oil blaze hits hospital systems
In the light of the Buncefield Oil Depot explosion, we should all consider
what local events beyond our control may do to our precious computer and
control systems.
A computer system at a Cambridge hospital used for patient information
such as admissions and discharges experienced some problems because of a
fire at the Buncefield oil depot in Hertfordshire. A company providing
some IT services to Addenbrooke's Hospital was based at the industrial
park near the depot and was destroyed in the fire. It was expected to
take a week to get the computer system up again, although reportedly no
medical services were affected. [BBC report; PGN-ed]
Paul E. Bennett, Systems Engineer, UKAEA-JET, Culham Science Centre
Abingdon, Oxon OX14 3DB Tel: 01235-464884
------------------------------
Date: Sat, 17 Dec 2005 17:12:37 +0000 (GMT)
From: Pete Mellor <pm@csr.city.ac.uk>
Subject: Oil blaze hits hospital systems
The explosion and fire at the fuel depot near Hemel Hempstead, Hertfordshire:
http://images.thetimes.co.uk/TGD/picture/0,,250768,00.jpg
Connection with computers? Well, several nearby installations were wrecked
(amazingly, no-one was seriously injured), one of which contained the
electronic patient records of Addenbrooke's Hospital, Cambridge. The
hospital reported that it would have to rely on paper records for several
days until the computer files could be restored.
On the positive side, at least they had back-up. On the other
hand, their disaster recovery planning seems to be a bit slack.
Peter Mellor, Centre for Software Reliability, City University, London EC1V 0HB
+44 (0)20 7040 8422 Pete Mellor <p.mellor@csr.city.ac.uk>
------------------------------
Date: Fri, 16 Dec 2005 06:59:11 -0500
From: danny burstein <dannyb@panix.com>
Subject: The drunks may save our election system (WSJ)
Fascinating... Per the attached clip from the *Wall Street Journal*, Florida
(FLORIDA!) courts have been agreeing that defendants in "driving while under
the influence" cases have a right to full disclosure of the software used in
the equipment doing the measuring.
Imagine if this logic followed through to the equipment being slid into
election vote counting!
"A court fight in Florida over the software used in the instruments that
detect alcohol in breath could threaten the ability of states and
localities to prosecute drunk drivers.
"The battle is over the source code of breath analyzers made by CMI Group,
a closely held maker of breath-alcohol instruments. Defense lawyers have
challenged the use of the device and asked to see the original source code
that serves as its computer brain, saying their clients have the right to
examine the machine that brings evidence against them.
"Last February, a state appeals court in Daytona Beach ruled that Florida
had to produce 'full information' about the test that establishes the
blood-alcohol level of people accused of driving under the influence, or
DUI. Otherwise, the court said, the evidence is inadmissible...
rest at:
http://online.wsj.com/article_print/SB113470249958424310.html
------------------------------
Date: Fri, 23 Dec 2005 10:30:58 -0500
From: Fernando Pereira <pereira@cis.upenn.edu>
Subject: Risks of spreadsheets
Ivars Peterson, The Risky Business of Spreadsheet Errors
*Science News*, Week of 17 Dec 2005
http://www.sciencenews.org/articles/20051217/mathtrek.asp
Spreadsheets create an illusion of orderliness, accuracy, and integrity. The
tidy rows and columns of data, instant calculations, eerily invisible
updating, and other features of these ubiquitous instruments contribute to
this soothing impression. At the same time, faulty spreadsheets and poor
spreadsheet practices have been implicated in a wide variety of business and
financial problems.
[PGN-excerpted from a nice article with a bunch of references, including
Ivars' 1996 book, Fatal Defect: Chasing Killer Computer Bugs, which itself
cited some earlier RISKS reports. The last two references are particularly
relevant:
The European Spreadsheet Risks Interest Group (EuSpRIG) has a Web site
at http://www.eusprig.org/.
Spreadsheet Research, maintained by Ray Panko of the University of
Hawaii, is a repository for research on spreadsheet development,
testing, use, and technology: http://panko.cba.hawaii.edu/ssr/.]
------------------------------
Date: Mon, 19 Dec 2005 10:48:49 +1100
From: James Cameron <james.cameron@hp.com>
Subject: James Reason on Absent-mindedness and risk management
Here is an interview that is very suitable for passing on to your
non-technical friends who don't understand why you are so morbidly
fascinated with risks.
The interviewee is James Reason, Emeritus Professor of Psychology,
University of Manchester in the U.K. Professor Reason appears in RISKS a
few times (4.52, 10.31, 21.48, 23.24) and is well known for the "Swiss
Cheese Model".
The interview was released by the Australian Broadcasting Corporation (ABC)
this morning, a repeat from 16th May 2005, and covers;
* Absentmindedness,
* the Tenerife disaster (1977, two Boeing 747s collide),
* no remedial benefit from blame,
* root cause analysis,
* the Gimli Glider.
It's available as an MP3 file:
http://abc.net.au/rn/podcast/feeds/health_20051219.mp3
A transcript:
http://www.abc.net.au/rn/talks/8.30/helthrpt/stories/s1529677.htm
James Cameron http://ftp.hp.com.au/sigs/jc/
------------------------------
Date: Mon, 19 Dec 2005 13:18:29 -0800
From: <bruce_hamilton@agilent.com>
Subject: Yet another leap year error
Last month my wife got a CAN 0.03 credit on her Toronto Dominion Visa bill,
labelled "Leap year -- interest credit." The note says "The leap year
interest credit on your statement is a correction for an over charge in the
2004 leap year."
I don't remember seeing one of these for 2000. Interesting that they would
get that right and 2004 wrong.
Incidentally, the bill has our US ZIP code printed with Canadian spacing:
"940 25".
bruce_hamilton@agilent.com Tel: +1 650 485 2818 Fax: +1 650 485 1103
Agilent Technologies MS 24M-A, 3500 Deer Creek Road, Palo Alto CA 94303
------------------------------
Date: Tue, 20 Dec 2005 19:06:59 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Kansas Lottery Picks Same Number Three Nights in a Row
The same three numbers (5-0-9) came up in the same order on 16, 17, and 18
Dec 2005 in the Kansas Lottery Pick Three. On the third night, many people
apparently chose 5-0-9, costing the lottery nearly twice what was paid in.
Lottery security officials insist that the system was working normally.
(Perhaps the random-number generator had gone to seed?) [PGN-ed. Thanks to
Lauren Weinstein for spotting this one.]
http://abcnews.go.com/US/story?id=1425383
------------------------------
Date: Mon, 12 Dec 2005 21:16:27 -0500
From: RsH <rsh@idirect.com>
Subject: No one lost or made $225 million... (Re: RISKS-24.12)
Re: Trading Error Leads to $225 Million Loss for Japanese Firm
As per the information in the Reuters item
http://asia.news.yahoo.com/051211/3/2c7vk.html
the actual loss may be lower or more than the $225 million as the amount of
the premium that will need to be paid to by back shares is still to be
determined. The sale order was for about 41 times the actual number of
shares actually outstanding, incidentally.
It turns out that the Tokyo Stock Exchange's own software was responsible
for part of the problem, as it prevented the cancellation of the order from
being processed!
See http://www.yomiuri.co.jp/dy/business/20051210TDY08010.htm
which says:
Observers also said the TSE held some responsibility for the incident
because it accepted the unusual sell order. The TSE does not have a
system to automatically detect an unusual order, and the bourse will come
under pressure to remedy this situation.
Also note that this is NOT the first time this has happened at the TSE, and
they have yet to fix their system! RSH
[From the same article...]
Incident not without precedent
Thursday's incident was not the first time a large-scale errant order was
placed in the nation. In November 2001, UBS Warburg (Japan) Ltd. (now UBS
Securities Japan Ltd.) issued an order to "sell 610,000 shares at 16 yen
each," instead of "sell 16 shares at 610,000 yen each," for newly listed
Dentsu Inc. stock on the First Section of the TSE. It is believed that UBS
Warburg incurred significant losses due to this erroneous order. In
December of the same year, Deutsche Securities Ltd. made a massive sell
order for Isuzu Motors Ltd. stock, but the order was not processed because
it was made soon before the market closed. In both cases, the price and
amount of shares were inadvertently mixed up.
Note added Mon, 26 Dec 2005:
[More fallout from the error... with a better number on the loss
actually suffered.]
Exchange chief resigns over 'fat finger' error, From Leo Lewis in Tokyo
The Times, 21 Dec 2005
http://business.timesonline.co.uk/article/0,,13133-1948579,00.html
The president of the Tokyo Stock Exchange resigned yesterday to take
responsibility for the ``fat-finger'' trading error that sparked a day of
mayhem on Tokyo markets earlier this month. Takuo Tsurushima resigned along
with Sadao Yoshino, the bourse's managing director, and Yasuo Tobiyama, its
head of computer systems. The incident has left considerable turmoil in its
wake: Mizuho Securities lost 40 billion yen (£195 million) on the
botched trade and two Japanese day traders made Y2.5 billion in a few
minutes.
Western investment houses who made money from the error have been publicly
criticised by the Japanese Government and agreed to pay the profits they
made into an investors' protection fund.
Losses from the trade were sufficient to force Mizuho to cancel all
end-of-year bonuses from the securities arm. The trader, believed to be a
24-year-old woman relatively inexperienced on the dealing floor, had wanted
to sell one share in J Com, a new telecoms firm, for Y600,000. She mistyped
the order and sold 600,000 shares at Y1 each.
------------------------------
Date: Tue, 13 Dec 2005 07:57:33 +0000
From: Ian Halliday <ian.halliday@gmail.com>
Subject: Re: A Little Sleuthing Unmasks Writer of Wikipedia Prank
The claim that "he thought Wikipedia was a gag site" (RISKS-24.12)
seems unlikely, and I see it on a par with those who say "no, I was
just doing research" when caught hacking/visiting dubious web sites.
Yet this seems to have caught the attention of some parts of the media
who don't usually see visiting those sites as plausible research.
The suggestion is that it is reasonable for somebody to be so mistaken
as to think Wikipedia is a "gag" site. While some of the information
there may not be 100% accurate, it's hard to see how this apparently
mistaken view can be seen as a genuine defence.
Ian W Halliday, BA Hons, SA Fin, ATMG, CL
------------------------------
Date: Fri, 23 Dec 2005 06:17:05 GMT
From: "Gary G. Taylor" <gary@notdonavan.org>
Subject: Re: In-car GPS navigation (Scott, RISKS-24.10)
Desite the fact that there are many different map atlas programs for the US
(although this entry concerns UK), they all use the same map database. Why?
Because there is *only one available,* unless you care to compile your
own. But this presents problems.
For example: Using *any* map atlas program for the US, tell it to show you
the intersection of Amboy Road and Wilson Road in Twentynine Palms, CA.
This is a remote desert area and only Amboy Road is paved ... in a manner of
speaking. Any of these programs will show a Mercedes-Benz-logo-shaped triad
of three roads running south from this intersection. Take it from one who
lived in that area for many years: none of those roads exist. The database
was compiled from USGS topo maps and the one for that area is dated (ISTR)
1953, and if you are told to "turn right" at that point and blindly do you
will piss off a lot of local residents because you will take out their
mailboxes.
And The Moral Is: Such programs should ALWAYS be taken with a grain of salt,
even in urban areas. And: The farther from urban areas you get, the less
reliable these programs are likely to be.
------------------------------
Date: Thu, 15 Dec 2005 03:38:21 +0800
From: Dan Jacobson <jidanni@jidanni.org>
Re: In-car GPS navigation (Scott, RISKS-24.10)
< if a sat nav system told you to jump off a cliff
Pals armed with my cliff top estate coordinates ended up at the bottom of
the cliff, and had to pay a local boozer to guide them the wasted 15 km. to
the top. Moral: X,Y perhaps 100% but without considering Z, your sat nav
system just gets you into more trouble.
------------------------------
Date: Thu, 08 Dec 2005 11:09:47 -0500
From: "Sean Dunn" <sad14159@hotmail.com>
Re: In-car GPS navigation (Scott, RISKS-24.10)
Accepting instructions that are reasonably obviously wrong (e.g. one-way
streets tend to have signs that indicate the restriction) can be a small
problem. Pinpoint lane accuracy can be a problem in specific locations where
divergent destinations depend on this accuracy. A harder-to-address problem
with GPS navigation can be the reliance upon simple geography...
When I was consulting to IBM in Los Angeles some years ago, one of the team
was given a Hertz car with the NeverLost system. Traveling together, we had
to ignore its turning suggestion after encountering roadwork and were
impressed - a route recalculation showed us the new way to reach the same
destination.
We experimented with how clever this system was. And discovered a limitation
we had not considered. After heading west back towards LA very late at
night, we turned off the freeway and asked the system to see if it could
find us a new route to central LA. Alas, the route it chose took us through
what could most charitably be called a 'rundown' area. In fact, we were
horrified to discover we seemed to have found a route through what we later
found out was one of the most dangerous areas in Los Angeles.
GPS systems can hardly be programmed to avoid seedy neighborhoods without
political uproar. On the other hand, there are roads that shouldn't be
traveled at some times of the day...
------------------------------
Date: Tue, 13 Dec 2005 02:01:16 +0000 (UTC)
From: Alex Colvin <alexc@TheWorld.com>
Subject: Re: In-car GPS navigation (Scott, RISKS-24.10)
Note that road coordinates are not known with perfect accuracy either.
Unless someone with a GPS has surveyed the road recently, the coordinates
may have been lifted from a paper map and translated through several datums.
For that matter, driving directions may use outdated one-way and turn
restriction information. This used to be especially obvious in Boston during
the big dig, where the airport exit changed every few weeks.
In the end, it's a lot of fuzz.
------------------------------
Date: Tue, 13 Dec 2005 12:32:48 +0100
From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
Subject: Re: False WHOIS Data Still Bedevils (Wagner, RISKS-24.12)
> ... This provides anonymity for spammers, scammers, phishers, and other
> illegal activities, and untraceability for malware-containing sites.
It also provides relative anonymity for people like paralegal Pamela Jones,
who operates groklaw.net, an award-winning web site dedicated to reporting
on and analyzing "legal events important to the [Free and Open Source
Software] community". Her relentless digging into the SCO lawsuits has made
her the target of harassment and defamation by SCO and its supporters, such
as journalist Maureen O'Gara - ask Google for the sordid details.
Dag-Erling Smørgrav - des@des.no
------------------------------
Date: Tue, 13 Dec 2005 09:38:47 +0000
From: Dave Bell <zhochaka@gmail.com>
Subject: Re: False WHOIS Data Still Bedevils (Wagner, RISKS-24.12)
I just hope that the GAO knows the difference between "unknown" and
"withheld". My domain name is registered in the UK, and because of UK
and European data protection laws applying to personal data, the WHOIS
doesn't return certain information.
------------------------------
Date: Tue, 13 Dec 2005 9:25:38 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Re: Miniature Golf Course on Terror Target List
[Rick Jones submitted this comment on the item in RISKS-24.12.
Many thanks! PGN]
<http://www.kron.com/Global/story.asp?S=4226663>
While the RISKS text talks as if the Golfland was on a terrorist watch
list as in a list of presumed potential terrorists, a close look at the
text on kron.com shows:
"The moment we realized it was on the list, it was taken off," said San
Jose police officer Rubens Dalaison, who handles "critical
infrastructure assessment" for the department. "I myself took it off."
Now, the rest of the text says things like "watch list" which sounds like
the Mr. Smith Will Go to Guantanamo list, however, IIRC the "critical
infrastructure assessment" bit suggests that someone listed the Golfland
as a piece of critical infrastructure, that is as a potential terrorist
target, not as a potential terrorist.
Is the Risk in what KRON published, how it was read by different people,
that a Golfland was on a list in the first place, or all of the above?-)
What is left open is if any of the _other_ Golfland's are considered
critical infrastructure, and perhaps how many people feel that a Golfland
is more critical infrastructure than say Fortress US Capitol...
[I think PGN was in Goofland not Golfland when he PGN-ed the item. PGN]
------------------------------
Date: Fri, 16 Dec 2005 09:24:51 +0900 (JST)
From: Curt Sampson <cjs@cynic.net>
Subject: Countering Trusting Trust through Diverse Double-Compiling
Here is a clear, relatively concise (13 pages) and detailed description and
demonstration of a solution to a particular RISK that we're probably all
familiar with.
- --------- Forwarded message ----------
Date: Mon, 12 Dec 2005 17:03:54 -0500
From: David A. Wheeler <dwheeler@ida.org>
To: bugtraq@securityfocus.com
Subject: Countering Trusting Trust through Diverse Double-Compiling
Everyone here should be familiar with Ken Thompson's famous
"Reflections on Trusting Trust." If not, see:
http://www.acm.org/classics/sep95/
The "trusting trust" attack subverts the compiler binary;
if attacker succeeds, you're doomed. Well, till now.
I've written a paper on an approach to counter this attack. See:
"Countering Trusting Trust through Diverse Double-Compiling"
http://www.acsa-admin.org/2005/abstracts/47.html
Here's the abstract:
"An Air Force evaluation of Multics, and Ken Thompson's famous Turing award
lecture "Reflections on Trusting Trust," showed that compilers can be
subverted to insert malicious Trojan horses into critical software,
including themselves. If this attack goes undetected, even complete analysis
of a system's source code will not find the malicious code that is running,
and methods for detecting this particular attack are not widely known. This
paper describes a practical technique, termed diverse double-compiling
(DDC), that detects this attack and some unintended compiler defects as
well. Simply recompile the purported source code twice: once with a second
(trusted) compiler, and again using the result of the first compilation. If
the result is bit-for-bit identical with the untrusted binary, then the
source code accurately represents the binary. This technique has been
mentioned informally, but its issues and ramifications have not been
identified or discussed in a peer-reviewed work, nor has a public
demonstration been made. This paper describes the technique, justifies it,
describes how to overcome practical challenges, and demonstrates it."
I think you'll find this interesting.
--- David A. Wheeler
------------------------------
Date: Mon, 19 Dec 2005 10:13:23 -0800
From: Rob Slade <rMslade@shaw.ca>
Subject: REVIEW: "The Art of Computer Virus Research and Defense", Peter Szor
BKACVRAD.RVW 20050731
"The Art of Computer Virus Research and Defense", Peter Szor, 2005,
0-321-30454-3, U$49.99/C$69.99
%A Peter Szor pszor@acm.org
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2005
%G 0-321-30454-3
%I Addison-Wesley Publishing Co.
%O U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O http://www.amazon.com/exec/obidos/ASIN/0321304543/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321304543/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321304543/robsladesin03-20
%O Audience s+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 713 p.
%T "The Art of Computer Virus Research and Defense"
The preface states that the book is a compilation of research over a
fifteen year period. While it is not explicitly stated, Szor seems to
indicate that the primary audience for the work consists of those
professionally engaged in the field of malware research and
protection. (He also admits that his writing might be a little rough,
which is true. While his text is generally clear enough, it is
frequently disjointed, and often appears incomplete or jumpy.
Illustrations are habitually less than helpful, although this can't be
attributed to a lack of command of English.) Given the stature of
people he lists in the acknowledgments one can hope for good quality
in the technical information.
Part one deals with the strategies of the attacker. Chapter one
describes games and studies of natural ecologies relevant to computer
viruses, as well as the early history (and even pre-history) of these
programs. I could cavil that he misses some points (such as the
1980-81 Apple virus programs at two universities in Texas), or glosses
over some important events (such as Shoch and Hupp's worm experiments
at Xerox PARC), but the background is much better and broader than
that found in most chronicles. The beginnings of malicious code
analysis are provided in chapter two, although it concentrates on a
glossary of malware types (albeit incomplete and not always
universally agreed) and the CARO (Computer Antivirus Research
Organization) naming convention. The environment in which viruses
operate, particularly hardware and operating system platform
dependencies, is reviewed in chapter three. This material is much
more detailed than that given in any other virus related text.
(Dependencies missing from the list seem to be those that utilize
protective software itself, such as the old virus that used a function
of the Thunderbyte antivirus to spread, or the more recent Witty worm,
targeted at the BlackIce firewall. Companion viruses utilizing
precedence priorities would seem to be related to operating system
functions, but are not included in that section.) Unfortunately, the
content will not be of direct and immediate use, since it primarily
points out issues and relies on the reader's background to understand
how to deal with the problems, but nonetheless the material is
fascinating and the inventory impressive. Chapter four outlines
infection strategies and is likewise comprehensive. Memory use and
infection strategies are described in chapter five. The issue of
viral self-protection; tactics to avoid detection and elimination; are
given in chapter six. Chapter seven reviews variations on the theme
of polymorphism, and also catalogues some of the virus generation
kits. Payload types are enumerated in chapter eight. Oddly, botnets
are mentioned neither here, nor in the material on worms, in chapter
nine. (Szor's use of a modified Cohenesque definition of a virus as
infecting files means that some of the items listed in this section
are what would otherwise be called email viruses. His usage is not
always consistent, as in the earlier mention of script viruses on page
81.) "Exploits," in chapter ten, covers a multitude of software
vulnerabilities that might be used by a variety of malware categories
for diverse purposes. This content is also some of the best that I've
seen dealing with the matter of software vulnerabilities, and would be
well recommended to those interested in building secure applications.
Part two moves into the area of defence. Chapter eleven describes the
basic types of antiviral or antimalware programs, concentrating
primarily on various forms of scanning, although change detection and
activity monitoring/restriction are mentioned. It is often desirable
to find and disable malware in memory. The means of doing so,
particularly in the hiding-place riddled Win32 system, are described
in chapter twelve. Means of blocking worm attacks are discussed in
chapter thirteen, although most appear to be either forms of
application proxy firewalling, or (somewhat ironically) activity
monitoring. Chapter fourteen lists generic network protection
mechanisms, such as firewalls and intrusion detection systems,
although the section on the use of network sniffers to capture memory-
only worms is intriguing to the researcher. Software analysis, and
the tools therefore, is covered in chapter fifteen, emphasizing
functional aspects of the malware. Chapter sixteen concludes with a
register of Websites for further study and reference.
For those involved in malware research, Szor's book is easily the best
since Ferbrache's "A Pathology of Computer Viruses" (cf.
BKPTHVIR.RVW). It contains a wealth of information found nowhere else
in book form. On the other hand, it is demanding of the reader, both
in terms of the often uneven writing style, and the background
knowledge of computer internals and programming that is required. The
text does not provide material that would be suitable for general
protection of computer systems and networks. On the other hand,
intelligent amateur students of malicious software will find much to
reward their investigation of this book.
copyright Robert M. Slade, 2005 BKACVRAD.RVW 20050731
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)
The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. The mailman web interface can
be used directly to subscribe and unsubscribe:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@csl.sri.com
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@csl.sri.com or risks-unsubscribe@csl.sri.com
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
=> The complete INFO file (submissions, default disclaimers, archive sites,
copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in RISKS issues.
*** Contributors are assumed to have read the full info file for guidelines.
=> .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay 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/> .
==> 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 24.13
************************
