RISKS-LIST: Risks-Forum Digest Thursday 1 March 2007 Volume 24 : Issue 58
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.58.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
USAF F-22A jets grounded by software glitch (PGN, Jeremy Epstein)
Briz-M rocket booster explodes over Australia (Mark Luntzel via PGN)
Software error reportedly contributed to sudden Dow-Jones drop (PGN)
Don't compute and drive at the same time... (Paul Saffo via PGN)
Risk of not knowing technology: jail (Ronald J Bottomly)
The Risks of Updating 80 Year Old Equipment (Chuck Weinstock, Jim Geissman)
RFID tracking (Paul Wallich)
Putting the SSN genie back in the bottle? (Steve Summit)
Re: DNS roots attacked (Robert Graves, R A Lichtensteiger, Joe St Sauver)
Re: Crashing an in-flight entertainment system (PGN)
Re: Amazing boilerplate in Fairfax County e-mail (Mark Brader)
Disposable digital Cameras are truly digital (Jason Mechler)
Carmakers copy and repeat error almost forever (Mark Brader)
WOTE 2007 CfP (Josh Benaloh)
REVIEW: "The Art of Software Security Assessment", Dowd et al. (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 26 Feb 2007 14:32:19 PST
From: "Peter G. Neumann" <neumann@private>
Subject: USAF F-22A jets grounded by software glitch
The F-22 continues to encounter bumps in its first air expeditionary force
deployment to Okinawa. The 12 aircraft from Langley AFB, Va., spent an
unscheduled week at Hickam AFB, Hawaii, after the leading four had to
abort the trip's last leg. As the Raptors reached the International Date
Line, the navigation computers locked up, so the aircraft returned to
Hickam until a software patch was readied. "Apparently we had built an
aircraft for the Western Hemisphere only," says a senior U.S. Air Force
official. When the F-22s arrived at Kadena AB, Okinawa, some Japanese
citizens held a protest against the aircraft's noise. [Source: Aviation
Week & Space Technology, 26 Feb 2007, p.18; thanks to John Rushby and
Martyn Thomas for that item. PGN]
Gene Spafford noted another article:
http://www.dailytech.com/Lockheeds+F22+Raptor+Gets+Zapped+by+International+Date+Line/article6225.htm
------------------------------
Date: Fri, 23 Feb 2007 15:55:52 -0500
From: Jeremy Epstein <jepstein@private>
Subject: USAF F-22A jets grounded by software glitch
Navigational systems failed, planes forced to return to Hawaii [visually
having to follow their tankers to safety]. The problem turns out to be
software (no surprise there). Fix created, "verified", installed, and
they're off again.
"A spokesman for Lockheed Martin this week insisted that the navigation
software problem was minor. 'The issue was quickly identified in a matter of
days and a fix installed in the airplanes, which were flown successfully to
Japan,' he said. 'There are 87 of these exceptional fighters and they are
out there performing exceptionally well, and their pilots continue to fly
them in new and greater ways.'"
Gee, I feel better knowing that.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011691&source=NLT_PM&nlid=8
[Long ago there was an urban legend about the F-16 flipping over and
flying upside down when it crossed over the equator. That report emerged
because a consequential software flaw had actually been DETECTED in
simulation, and had been FIXED before it could have happened in actual
flights. However, the F-22 Raptor was presumably unwrapped without the
benefit of rapter simulation, testing, and other pre-flight analyses.
This smacks of Alpha males doing Beta testing by risking their own Gamma
globulin. PGN]
------------------------------
Date: Thu, 22 Feb 2007 10:02:37 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Briz-M rocket booster explodes over Australia
> Date: February 21, 2007 9:32:24 AM PST
> From: SpaceWeather.com <swlist@private>
> Subject: Major Breakup Event over Australia
>
> Space Weather News for Feb. 21, 2007, http://spaceweather.com
>
> On February 19th, late-night sky watchers across Australia witnessed a
> bright explosion followed by a debris cloud that hung in the sky for
> nearly an hour. At first a mystery, the source of the blast is now
> understood. It was a Russian Briz-M rocket booster misplaced in orbit
> last year by the failed launch of an Arabsat communications satellite.
> The fuel tanks of the Briz-M ruptured on Feb. 19th, producing a vivid
> naked-eye display and more than 1000 pieces of debris. Experts are
> calling this a "major breakup event," comparable to or even worse than
> last month's Chinese anti-sat test. Visit http://spaceweather.com for
> more information and pictures of the Briz-M breakup.
[Thanks for spotting this one to Mark Luntzel, who particularly noted
the ambiguous concept of "misplaced in orbit". PGN]
------------------------------
Date: Wed, 28 Feb 2007 11:37:15 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Software error reportedly contributed to sudden Dow-Jones drop
On 27 Feb 2007, the Chinese stock market experienced a 9% drop. This
apparently inspired heavy selling on the New York Stock Exchange, with a
volume about twice normal. At one time, the calculation of the Dow Jones
Industrial average was running about 70 minutes behind. Recognizing some
sort of computer problem, DJ switched to a backup computer, which over a
period of about three minutes caught up -- resulting in the posted average
dropping about 240 points in those three minutes. This evidently led to
some further panic selling. (At one point, the market was down 546 points,
although it later recovered to close down only 416.) The cause of the
software problem is under investigation. [Sources: Swiftness of Dow Drop
Due to Computers (The Associated Press), *The New York Times*, 27 Feb 2007;
A Glitch in the Financial Matrix: How Heavy Trade Volumes and a 70-Minute
Time Lag Wreaked Havoc Upon the New York Stock Exchange, Dan Arnall, ABC
News, 27 Feb 2007; starkly PGN-ed]
------------------------------
Date: Tue, 27 Feb 2007 12:02:23 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Don't compute and drive at the same time...
[Many thanks to Paul Saffo for finding this item. (He observed that this
gives a new meaning to the concept of a "Windows crash"... PGN]
A man who authorities say appeared to be driving while using his laptop
computer died Monday when his vehicle crossed into oncoming traffic and
collided with a Hummer. After the crash, California Highway Patrol officers
found the victim's computer still running and plugged into the cigarette
lighter of his 1991 Honda Accord. ... [Source: Man in fatal crash thought
to be using laptop, Associated Press, 26 Feb 2007]
http://www.latimes.com/news/local/la-me-laptop27feb27,0,6942169.story?coll=la-default-underdog
------------------------------
Date: Thu, 22 Feb 2007 16:50:36 -0500
From: "Ronald J Bottomly" <bottomly@private>
Subject: Risk of not knowing technology: jail
The AP recently ran a story about a substitute teacher who was convicted of
exposing students to pornography. Her contention that it was inadvertent
because she couldn't keep up with pop-ups seems plausible, but the equally
non-tech-savvy jury didn't buy it (despite the fact that the prosecution
never even made a reasonable case by checking for spyware). What seems
particularly Kafka-esque is the potential 40-year sentence she faces.
http://www.courant.com/news/local/statewire/hc-14013002.apds.m0230.bc-ct--teacfeb14,0,7509985.story
------------------------------
Date: Sun, 25 Feb 2007 21:33:21 -0500
From: Chuck Weinstock <weinstock@private>
Subject: The Risks of Updating 80 Year Old Equipment (Re: RISKS-24.29)
Although the system includes components built 80 years ago, the 25 May 2006
power outage on Amtrak's Northeast Corridor was caused by a youngster -- a
four year old computer system. According to *The New York Times*, 24 Feb
2007, a single command failed to execute on the evening of 23 May 2006, and
no one was alerted. The computer system in question apparently reduced
power at the substation involved during maintenance and the failed command
was to restore the power levels to normal when maintenance was done. The
result was a rush hour on May 25th that took down most of the Northeast
Corridor.
Interestingly the computer that failed was one of a pair designed to provide
redundancy. The second computer was out of service at the time of the
failure.
It apparently is the case that reducing power during maintenance was
unnecessary. When Amtrak asked an unidentified vendor why this was done,
they did not have a good explanation. "After the blackout, the equipment
manufacturer decided that instead of fixing the system ... the whole
procedure should be eliminated..."
``In the old days, you had switches and gauges, and a glance would reveal
that one of them was out of position.'' said William Crosbie, the Amtrak's
vice president for operations.
[Edited down from the original article in *The New York Times*, 24 Feb 2007]
http://www.nytimes.com/2007/02/24/us/24amtrak.html
------------------------------
Date: Fri, 23 Feb 2007 20:31:06 -0800
From: Jim Geissman <jgeissman@private>
Subject: The Risks of Updating 80 Year Old Equipment (Re: RISKS-24.29)
The key is in the Crosbie quote [last sentence in Chuck Weinstock's excerpt
above]. And not at all surprising -- when you're not sure you understand a
technology, you tend to over-engineer and create objects that work forever.
When you think you understand, and are also trying to squeeze every penny
out of the objects, you cut corners (oops, I mean optimize by improving the
design), and then the system may fail wherever your understanding isn't
correct.
------------------------------
Date: Wed, 21 Feb 2007 13:27:41 -0500
From: Paul Wallich <pw@private>
Subject: RFID tracking
<http://www.sciencedaily.com/releases/2007/02/070201164742.htm>
Science Daily: An electronic accountability system developed at Oak Ridge
National Laboratory will result in savings of more than $2 million per year
at one federal facility alone and will ensure 100 percent accountability of
employees.
[... and so forth ...]
The article mentions the difficulties of making sure RFIDs at a classified
site don't serve as a conduit for leaking information, and claims (among
other things) safety benefits from knowing the locations of all employees
during an emergency (of some kind that miraculously manages not to knock out
any part of the tracking computers or their sensor network, or to damage
anyone's RFID).
As an inventory-control system, it quite possibly makes sense, with the
usual caveats. But one does wonder a little about the people-tracking side
of it and the possibilities for mischief if any of the reams of generated
data got into the wrong hands.
[Also, RISKS readers should always be wary of claims of 100%
infallibility. PGN]
------------------------------
Date: Wed, 28 Feb 2007 22:52:58 -0500
From: Steve Summit <scs@private>
Subject: Putting the SSN genie back in the bottle?
There were several stories in the news today about a delay in implementing
new privacy-enhancing legislation in Texas. All SSNs were to have been
stricken from publicly-accessible documents, including title records, deeds,
tax liens and birth and death records, but in response to complaints that
this work could not be completed in time, Attorney General Greg Abbott
issued a letter delaying the requirement by 60 days. (See e.g.
http://www.weatherforddemocrat.com/homepage/local_story_059145859.html .)
On the one hand this is disappointing, because identity theft is bad, so
making SSN's less available is good. But, on second thought, does it even
matter any more?
I get the impression that SSN's are so widely available (i.e., for just
about everyone in the U.S.) that trying to plug any one particular hole is
probably all but futile. I found myself wondering (not for the first time)
what it would take to get U.S. commerce and society to properly separate the
tasks of identification and authentication. Would federal legislation
mandating this separation be effective? Would it be even remotely possible
to get passed? And even if -- somehow -- it were passed, would it be hated,
because of the seeming "inconvenience" of having to remember and use secret
authenticators (as opposed to well-known public identifiers) when performing
transactions that required them?
------------------------------
Date: Fri, 23 Feb 2007 23:12:29 +1100
From: Robert Graves <rgraves@private>
Subject: Re: DNS roots attacked (RISKS-24.57)
> ... attacks lasted for hours but passed largely unnoticed by most computer
> users, a testament to the resiliency of the Internet.
I noticed. I could access some local sites in Australia, but a number of
*major* sites such as Google.com.au were completely inaccessible for me. I
would categorize the Internet as *Severely Damaged* at the time - but then I
am no expert. Sadly, the thoughts that ran through my mind (and I'd guess a
number of those other *unnoticing* computer users) were a) why bother
complaining? and b) to whom to complain? My ISP had no information on its
status page about any problems, and my ability to look at other potential
information sources was limited by the problem itself. So, I turned the
computer off and went to bed. I suspect those quoted "experts" have a
vested interest in downplaying the issue.
RISKS? The very nature of the Internet seems to mitigate against "noticing"
issues such as this. I just hope that the instabilities of the Internet are
resolved before it becomes too critical to our way of life.
------------------------------
Date: Fri, 23 Feb 2007 16:51:27 -0500
From: R A Lichtensteiger <rali@private>
Subject: Re: DNS roots attacked (RISKS-24.57)
< [See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in
< Oct 2002. Perhaps the Internet is somewhat more robust now? PGN]
Certainly the roots are. f.root-servers.net is actually 34 geographically
dispersed nodes using IP anycast. The last numbers I have for the other
roots says i-root has 13 and j-root has 17 unique nodes.
It's harder to DDoS 34 machines than to do it to one. And the effects will
be regionalized. Depending on the distribution of the bots doig the
attacking, one or more nodes will be under greater load than others, so some
people will see worse response rates than others.
As the article you cite said, most folks didn't seem to notice the attack.
Redundancy is good for mitigating some risks (keeping this reponse on
charter! <g>).
------------------------------
Date: Wed, 21 Feb 2007 14:12:50 -0800
From: Joe St Sauver <joe@private>
Subject: Re: DNS roots attacked (RISKS-24.57)
You mentioned the recent attack on the roots... unfortunately I don't think
there's much room to be cheery about the current state of security of the
DNS system... if you're interested, see "Port 53 Wars" from the recent
Internet2/ESNet Joint Techs session on "Security of the Domain Name System
and Thinking About DNSSEC," http://www.uoregon.edu/~joe/port53wars/ (PPT and
PDF formats provided)
------------------------------
Date: Wed, 21 Feb 2007 14:37:09 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Re: Crashing an in-flight entertainment system (Summit, RISKS-24.57)
[Hugh Thompson's blog continues with further discussion. PGN]
http://blogs.csoonline.com/node/151
Submitted by Anonymous on Wed, 2007-02-21 11:25.
Er, Um, avionics software ain't that grand either, if you go by some
examples of Airbus software. An Airbus went off the end of a runway a
while back, and an investigation revealed:
* A leetle bit of water froze in a brake cylinder.
* The brake system software detected the problem, in the secondary brake
system. So far so good. The software then:
* Did its normal thing, disabled the PRIMARY brake system, the good one.
* Put up a misleading error message on an out-of the way display page.
* The pilot eventually noticed this error message, so he pressed a button
to clear the message.
* But he pressed the button for under 50 msec, so one flight control
computer saw the press, but the other one didn't.
* The computers noticed they disagreed, so one of them shut down.
* The pilot noticed the shutdown, so he pressed a "master reset" button.
* But as it turns out, the "master reset" button doesn't really, like,
reset everything, but it tells you it did.
* Therefore when they applied the brakes, only the secondary (frozen
up) brakes were applied.
* The pilots, used to this super double-redundant computer-controlled
brake system, didn't even think to apply the brakes manually.
* Plane went off end of runway, many $$$$$$$$ of damage.
That's just one example of AirBus software wonderfulness.
------------------------------
Date: Wed, 21 Feb 2007 16:21:05 -0500 (EST)
From: msb@private (Mark Brader)
Subject: Re: Amazing boilerplate in Fairfax County e-mail (Goldberg, R-24.57)
> Looks like the "cutting edge" is severing Fairfax from the Internet.
> Being offline would be bad enough, but bouncing e-mail? For three or four
> days? Amazing.
Er, which county-level services is it that are so critical that if they're
unavailable via the Internet over a long weekend it's cause for words like
"hard-to-believe", "amazing", "anger", and "outrage"?
Mark Brader, Toronto, msb@private
------------------------------
Date: Wed, 21 Feb 2007 11:52:49 -0600
From: Jason Mechler <jasonmechler@private>
Subject: Disposable digital Cameras are truly digital (Re: R-24.52,54,56,57)
To end recent debate about the existence of disposable digital cameras,
please see the following 2004 article in *Time* magazine. An acquaintance
of mine bought one of these when they first came out and attempted to hack
so it could be reused. A simple google search now pulls up instructions for
converting these phones to multi-use.
*Time* Article: http://www.time.com/time/gadget/20040825/
Single-to-Multi-Use Hacks: http://www.cexx.org/dakota/
------------------------------
Date: Wed, 21 Feb 2007 16:20:06 -0500 (EST)
From: msb@private (Mark Brader)
Subject: Carmakers copy and repeat error almost forever (McIlroy, RISKS-24.57)
RISKS-16.3, 5 May 1994, contained an account of the shock of being locked
>> locked out automatically after closing the door on a stopped car with
>> the engine running ... The problem was reported for a Chevvy ...
No, it was reported for a Buick Century. The same item mentioned a Chevy,
but *its* misfeature was to *unlock* doors automatically, perhaps posing a
theft risk.
Mark Brader, Toronto, msb@private
------------------------------
Date: Tue, 27 Feb 2007 17:24:51 -0800
From: Josh Benaloh <benaloh@private>
Subject: WOTE 2007 CfP
Workshop on Trustworthy Elections (WOTE 2007),
University of Ottawa, Ottawa, CANADA, 20-21 Jun 2007
Call for Papers [due 9 Apr 2007]
Election technologies have been a major concern in recent years with
numerous questions raised about current methods. The aim of the workshop is
to bring together researchers, policy makers, voting officials, and others
whose work relates to electronic voting systems to present, discuss, and
evaluate promising technologies and schemes to achieve high assurance of
accuracy and privacy in the casting and counting of votes.
Full CfP: http://research.microsoft.com/CONFERENCES/WOTE2007/
[Josh is the program chair. General chairs are David Chaum and Ron
Rivest. Past WOTE meetings have been very worthwhile. This one is held
in conjunction with the 7th Workshop on Privacy Enhancing Technologies,
and organized by IAVoSS, the International Association for Voting Systems
Sciences. The emphasis is on cryptographic voting methods. PGN]
------------------------------
Date: Wed, 07 Feb 2007 13:39:41 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "The Art of Software Security Assessment", Dowd et al.
Mark Dowd/John McDonald/Justin Schuh
BKTAOSSA.RVW 20061214
"The Art of Software Security Assessment", Mark Dowd/John
McDonald/Justin Schuh, 2007, 0-321-44442-6, U$54.99/C$68.99
%A Mark Dowd http://taossa.com/
%A John McDonald
%A Justin Schuh
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2007
%G 0-321-44442-6
%I Addison-Wesley Publishing Co.
%O U$54.99/C$68.99 416-447-5101 fax: 416-443-0948 800-822-6339
%O http://www.amazon.com/exec/obidos/ASIN/0321444426/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321444426/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321444426/robsladesin03-20
%O Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 1174 p.
%T "The Art of Software Security Assessment"
One of the important parts of a book proposal is a review of the
literature that might be related to your topic, and how your book
differs from the competition. The preface states that, unlike other
software security texts, this one doesn't deal with security design
and defensive programming, but concentrates on how to find
vulnerabilities. The authors obviously haven't done their homework:
there are a number of books that talk about finding weaknesses and
loopholes in software. There are even books that specialize in
finding vulnerabilities in specific types of software, such as the
rather spotty "Database Hacker's Handbook" (cf. BKDBHKHB.RVW) and the
much superior "How to Break Web Software" by Andrews and Whittaker
(cf. BKHTBWSW.RVW). And most of them seem to be, like this work,
directed at consultants, security professionals, developers, and
quality assurance people.
"The Art of Software Security Assessment" is somewhat distinctive in
being particularly directed to programmers. Thus, readers from the
consulting, security, and quality assurance fields who do not have a
very strong programming background will probably find themselves at a
loss to navigate the maze of coding examples.
Part one is an introduction to software security assessment. Chapter
one, on software vulnerability fundamentals, starts with a very
verbose definition of "vulnerability" that seems to boil down to the
idea that a vulnerability is something that someone can use against
you. The authors also propose that problems be examined in terms of
design vulnerabilities (this is what some other software development
literature describes as flaws), implementation vulnerabilities (bugs),
and operational vulnerabilities. (The latter seems to be related to
improper requirements specification, or simply use of a program in the
wrong situation.) One section runs through the software development
life cycle (SDLC) noting the types of problems to be addressed in each
phase, but the material is much less useful than that in Gary McGraw's
"Software Security: Building Security In" (cf. BKSWSBSI.RVW). A brief
overview of design review is found in chapter two, along with a larger
section of miscellaneous security technologies. There is also a more-
than-usually helpful explanation of threat modeling using data flow
diagrams and attack trees. Some of the material is idiosyncratic: the
description of "bait-and-switch" attacks seems to be confused with the
birthday attack against hash digests. An unstructured collection of
content about vulnerabilities, more security technologies, and network
models makes up chapter three. Chapter four titularly talks about the
application review process. This medley of ideas about ways to check
code will give you some suggestions if you are starting the operation,
but there is little in the way of analysis of the recommendations.
Part two turns to software vulnerabilities. Chapter five provides
very detailed information about the various types of buffer overflows,
although the explanations are not always clear unless you already
understand the concepts. Important facts about the means of data
representation in the C programming language are listed in chapter
six, and the abstractions are applicable to other languages. Chapter
seven suggests reviewing code in terms of function, such as separately
auditing variable use, procedure calls and returns, and memory
allocation. Problems with common string-handling (and therefore text-
related) statements in C are discussed in chapter eight, along with
the significance of differential handling of not-quite-universal data
representations by various languages (this commonly results in
malformed data attacks). Not quite in a separate part to themselves,
chapters nine through twelve provide internal details of the UNIX and
Windows privilege and permission functions, as well as process
handling. Chapter thirteen deals with process state information,
primarily concerning various race conditions. Unfortunately, the
outlines given are not as helpful as they could be, due to a reliance
on code examples at the expense of explanations. The authors would do
well to emulate the style adopted by Diomidis Spinellis in "Code
Quality: The Open Source Perspective" (cf. BKCQTOSP.RVW) who also
stresses the auditing of source code, but provides extensive textual
background as well.
Part three looks at software vulnerabilities in practice, although limited
to network operations. Chapter fourteen provides details of many of the
basic Internet protocols, noting checks that should be made for dangerous
conditions. The discussion of firewalls, in chapter fifteen, has oddly
little material on application-level proxies (and only tangential mention of
circuit-level proxies), concentrating on the examination of packet headers.
Miscellaneous attacks, with no readily evident theme, are listed in chapter
sixteen. Chapter seventeen details HTTP (HyperText Transfer Protocol) and
other Web technologies, catalogues some attacks, and gives a brief set of
vulnerability checking guidelines. Various vulnerabilities in Web scripting
and programming languages are noted in chapter eighteen.
There is a great deal of valuable information within this volume. However,
there isn't sufficient explanatory content for the work to stand as a primer
for beginners, and the lack of structure reduces the utility as a
professional reference. The reliance on code examples is reasonable for a
work aimed at programmers, but it does limit the audience to that group. In
addition, the practical parts of the book, in particular, greatly emphasize
Web applications. As it stands, this work has much of value to Web
developers and Web software testers, but it could have had much broader
application with minor improvements.
copyright Robert M. Slade, 2006 BKTAOSSA.RVW 20061214
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
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@private
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@private or risks-unsubscribe@private
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@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@private 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]
or http://www.sri.com/risks/risks-VL.IS for VoLume, ISSue as of 28 Feb.
<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.58
************************
This archive was generated by hypermail 2.1.3 : Thu Mar 01 2007 - 14:30:07 PST