RISKS-LIST: Risks-Forum Digest Monday 19 November 2007 Volume 24 : Issue 91
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.91.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Reported impending asteroid was actually Rosetta (Paul Saffo)
Ship collision with San Francisco Bay Bridge (PGN)
Village auto crashes blamed on sat nav (Amos Shapir)
Is Car Safety Technology Replacing Common Sense? (Florian Liekweg)
Adi Shamir's bug attack (Jean-Jacques Quisquater)
Timing Glitch Affected Thousands in NYC Marathon (Henry Baker)
Hamilton Township election result flipped: programming error (PGN)
Cardinal sin? Scoreboard message (PGN)
The dangers of machine translation (Shoshannah Forbes)
Security company e-mail undercuts user education (Rex Sanders)
Dangerous Mix of Globalization and Software (Stephen Smoliar via PGN)
Re: Best practices to redact account numbers (Mark Seecof)
Verizon phones make an audible alarm when 911 is dialed (Alex Burr)
ACSAC 2007 (Cristina Serban)
ICRAT - Air Transportation Research Symposium (Dres Zellweger)
REVIEW: "Network Security Hacks", Andrew Lockart (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 14 Nov 2007 14:37:21 -0800
From: Paul Saffo <paul@private>
Subject: Reported impending asteroid was actually Rosetta
[Incoming stone was actually Rosetta stone? PGN]
To make a long story short,
The Minor Planet Center, the world clearinghouse for information about
newly discovered asteroids, raised the alarm last week to track a
threatening celestial body. This would be one of the closest approaches
ever by a sizable asteroid -- its distance away being less than half the
diameter of the Earth. They announced that a previously unknown asteroid
would miss the Earth by just 5,600 kilometers. Then Denis Denisenko, of
Moscow's Space Research Institute (IKI), made an interesting discovery. He
noticed that the incoming asteroid's track matched that of the European
space probe Rosetta on a scheduled flyby of Earth. The Rosetta craft was
launched from Europe's Guiana Space Center in early March of 2004; the
purpose of the space probe is to place itself in low orbit around the
comet Churyumov-Gerasimenko at a distance of 675 million kilometers from
the sun. To get there, the billion-dollar craft will spend ten years
boosting its velocity (using the gravity assist technique) with no fewer
than three flybys of Earth and one of Mars. [Source: Bill Christensen,
Near-Miss Asteroid Found to be Artificial, 12 Nov 2007; PGN-ed. Bill was
reminded of Arthur C. Clarke's Rendezvous with Rama.]
http://www.space.com/businesstechnology/071112-technov-asteroid-mistake.html
[Mark Brader noted a BBC item:
http://news.bbc.co.uk/1/hi/sci/tech/7093402.stm
and *The Register* did an amusing take:
"Muscovite skywatcher Denis Denisenko revealed that the menacing meteor
was in fact [STRUCK THROUGH: a European Union space battleship bent on
world domination] the European Space Agency Rosetta probe, passing close
to Earth for a long-planned gravity-assist "slingshot" manoeuvre.]
http://www.theregister.co.uk/2007/11/13/rosetta_asteroid_spacecraft_patrick_moore_cockup/
------------------------------
Date: Mon, 19 Nov 2007 9:57:01 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Ship collision with San Francisco Bay Bridge
[Despite many reports calling it a tanker,] The Cosco Busan was actually a
container ship, and the fuel on board was solely for the purpose of running
the ship.
http://gcaptain.com/maritime/blog/ship-types-101-san-francisco-bay-bridge-oil-tanker-collision/
The Coast Guard blames the pilot and the captain, and notes that its radar
resolution was inadequate to detect the impending collision.
http://www.latimes.com/news/local/la-me-spill16nov16-ap,0,2939939.story
Other reports of the 7 Nov 2007 incident indicate that some of the ship's
sensors malfunctioned, the GPS was misinterpreted by the captain, and the
pilot believed the captain rather than a radio warning.
------------------------------
Date: Sun, 11 Nov 2007 17:45:57 +0200
From: Amos Shapir <amos083@private>
Subject: Village auto crashes blamed on sat nav
This article from the BBC news site is about a small village in Wales which
had seen a sudden increase of heavy traffic through its narrow streets,
causing a lot of damage. Quote: "Residents were convinced that satellite
navigation was to blame for the damage".
It has become so bad that "In August, the Vale of Glamorgan council became
so concerned over lorries being sent along narrow roads near St Hilary, it
began trials of a sign warning drivers to ignore sat-nav directions."
Read the full story at: http://news.bbc.co.uk/1/hi/wales/south_west/7088105.stm
------------------------------
Date: Thu, 08 Nov 2007 19:38:58 +0100
From: "Dr. Florian Liekweg" <liekweg@private-karlsruhe.de>
Subject: Is Car Safety Technology Replacing Common Sense?
http://blog.wired.com/cars/2007/11/is-safety-techn.html
In this blog post on the autopia blog, filed under "Safety" no less, Matthew
Phenix reports his experience with a Volvo S80, focusing on the wide array
of electronic "safety devices". He generalizes his impression with these
devices - those of the S80 and others - with the words
"Do I feel safer knowing other drivers' cars are doing the things -- like
checking mirrors and applying enough pressure to the brake pedal -- they
should be doing themselves? Not really."
I couldn't agree more to this statement.
After the recent reports about GPS/SatNav-related issues (RISKS-24.66,
"Another sat-nav accident: car destroyed, driver escapes", RISKS-24.65,
"Don't let your navigation system fool you" and many others), Phenix'
article covers a much broader area.
The Volvo "CWBS" has appeared in RISKS-24.33 ("Volvo's self braking car").
------------------------------
Date: Fri, 16 Nov 2007 13:15:06 +0100
From: Jean-Jacques Quisquater <jjqnews@private>
Subject: Adi Shamir's bug attack
http://www.nytimes.com/2007/11/17/technology/17code.html?em&ex=1195448400&en=729de9307626c4e6&ei=5087%0A
Very recently Adi Shamir sent the following announcement to few friends
(reproduced here with full permission from Adi Shamir). One (possibly
hidden and on purpose) bug in any high-level microprocessor as used in any
modern configuration can possibly leak secret keys used by Public-Key
Infrastructures (PKI). Be careful, there is a major risk. J-JQ
[This attack is noted by John Markoff, Adding Math to List of Security
Threats: Electronic System Could Be at Risk, *The New York Times*,
17 Nov 2007, National Edition B4. PGN]
- - - - - - - -
Research Announcement: Microprocessor Bugs Can Be Security Disasters
Adi Shamir, Computer Science Department,
The Weizmann Institute of Science, Israel
With the increasing word size and sophisticated optimizations of
multiplication units in modern microprocessors, it becomes increasingly
likely that they contain some undetected bugs. This was demonstrated by the
accidental discovery of the obscure Pentium division bug in the mid 1990's,
and by the recent discovery of a multiplication bug in the Microsoft Excel
program. In this note we show that if some intelligence organization
discovers (or secretly plants) even one pair of integers a and b whose
product is computed incorrectly (even in a single low order bit) by a
popular microprocessor, then ANY key in ANY RSA-based security program
running on ANY one of the millions of PC's that contain this microprocessor
can be trivially broken with a single chosen message. A similar attack can
be applied to any security scheme based on discrete logs modulo a prime, and
to any security scheme based on elliptic curves (in which we can also
exploit division bugs), and thus almost all the presently deployed public
key schemes will become vulnerable to such an attack.
The new attack (which we call a "Bug Attack") is related to the notion of
fault attacks discovered by Boneh, Demillo and Lipton in 1996, but seems to
be much more dangerous in its implications. The original fault attack
required physical possession of the computing device by the attacker, and
the deliberate injection of a transient fault by operating this device in an
unusual way (in a microwave oven, at high temperature, with high frequency
clock, or with a sudden spike in the power supply). Such attacks are
feasible against smart cards, but are much harder to carry out against
PC's. In the new bug attack, the target PC can be located at a secure
location half a world away, and the attacker has no way of influencing its
operating environment in order to trigger a fault. In addition, millions of
PC's can be attacked simultaneously, without having to manipulate the
operating environment of each one of them individually.
We now describe the basic idea of the new attack. We assume that the RSA
decryption (or signature generation) is using the Chinese Remainder Theorem
(CRT) which speeds up the operation by a factor of 4 compared to naive
implementations, that each multiplication of big numbers proceeds by
breaking them into the largest words which can be handled by the native
multiplier in that microprocessor (typically 32 or 64 bits), and that all
pairs of such words from the two numbers will be multiplied in some
order. Knowing the target's public key n, the attacker can easily compute a
half size number c which is guaranteed to be between the two secret factors
p and q of n. For example, a number c which is the square root of n (rounded
to the nearest integer) always satisfies p<c<q, and any number close to c is
also likely to satisfy this condition. The attacker now chooses a message m
which is equal to c, except that two low order words in it are replaced by a
and b, and submits this "poisoned input" to the target PC.
The first step in the CRT computation is to reduce the input m modulo p and
q. Due to its choice, m will be randomized mod the smaller p, but remain
unchanged mod the larger q. The next step in RSA-CRT is always to square the
reduced inputs mod p and q, respectively. Since a and b are unlikely to
remain in the randomized value of m (mod p), the computation mod p is likely
to be correct. However, mod q the squaring operation will contain a step in
which the word a is multiplied by the word b, and by our assumption the
result will be incorrect in at least one bit. Assuming that the rest of the
two computations mod p and q will be correct, the final result of the two
exponentiations will be combined into a single output y which is likely to
be correct mod p, but incorrect mod q. The attacker can then finish off his
attack in the same way as the original fault attack, by computing the gcd of
n with y^e-m, where e is the public exponent of the attacked RSA key. With
very high probability, this gcd will be the secret factor p of n. This
completely breaks the security of this key.
How easy is it to verify that such a single multiplication bug does not
exist in a modern microprocessor, when its exact design is kept as a trade
secret? There are 2^128 pairs of inputs in a 64x64 bit multiplier, so we
cannot try them all in an exhaustive search. Even if we assume that Intel
had learned its lesson and meticulously verified the correctness of its
multipliers, there are many smaller manufacturers of microprocessors who may
be less careful with their design. In addition, the problem is not limited
to microprocessors: Many cellular telephones are running RSA or elliptic
curve computations on signal processors made by TI and others, FPGA or ASIC
devices can embed in their design flawed multipliers from popular libraries
of standard cell designs, and many security programs use optimized "bignum
packages" written by others without being able to fully verify their
correctness. As we have demonstrated in this note, even a single (innocent
or intentional) bug in any one of these multipliers can lead to a huge
security disaster, which can be secretly exploited in an essentially
undetectable way by a sophisticated intelligence organization.
------------------------------
Date: Thu, 08 Nov 2007 07:31:58 -0800
From: Henry Baker <hbaker1@private>
Subject: Timing Glitch Affected Thousands in NYC Marathon
In this year's New York City Marathon on 4 Nov 2007, runners had chips in
their shoes that were intended to record when they crossed the starting line
and the finish line. This compensates those runners for the time it takes
to reach the starting line. However, the electronic timing system failed to
record 2,300 runners out of a field of more than 38,000. Because good
results in the NY race would enable qualification for the Boston Marathon,
surmounting this problem this was rather crucial to some of those runners.
Fortunately for them, the Boston officials accepted the self-reported times
recorded by the timers of those individuals and accepted by NY. The
"technical problem" was caused by interference (unspecified) that reportedly
disrupted the system for about three minutes at the start on one of three
starting areas. One woman's recorded time was indeed off by almost three
minutes, which may have been just enough to let her qualify for Boston.
(The official results are supposed to be posted on 19 Nov.) [Source:
Abigail Lorge, Timing Glitch Affected Thousands in Marathon, *The New York
Times*, 8 Nov 2007; PGN-ed]
[Considering which weekend this was ("fall back"), I'm amazed that the
timing wasn't an *hour* off... HB]
------------------------------
Date: Mon, 19 Nov 2007 14:12:17 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Hamilton Township election result flipped: programming error
On election day, 6 Nov 2007, the results were reportedly reversed in one
race, for trustee, in Hamilton Township, Lawrence County, Ohio, as a result
of "a programming error" in ES&S software. Because the final two candidates
for the Ironton City Council race were within four votes of one another,
that race was also being reevaluated. In Proctorville, the mayor's race had
a single vote separating the leaders, and the council race had a tie for the
second seat. In Symmes Valley, the fiscal office winner also had a one-vote
margin. And so on. [Source: Mark Shaffer *The Ironton Tribune*, 8 Nov
2007; PGN-ed]
http://www.irontontribune.com/articles/2007/11/08/news/news170.txt
[Of course one of the main problems with many current electronic voting
machines is that recounting is not particularly meaningful if the votes
are already incorrectly recorded, in the absence of a definitive
independent audit trail. PGN]
------------------------------
Date: Sat, 10 Nov 2007 7:57:54 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Cardinal sin? Scoreboard message
An Illinois woman (identified only as C.B.) is suing the St. Louis Cardinals
(damages at least $25K) for allowing a text message that falsely suggested
her 17-year-old daughter (A.B.) has an "STD") (of course, implying a
sexually transmitted disease, rather than a "standard"!) to be posted on the
Busch Stadium jumbotron during a game, apparently requested by a school
classmate of A.B. "The lawsuit, filed Wednesday in St. Louis Circuit Court,
claims the 17-year-old girl was so traumatized by the message last year
during a class trip that she stayed out of school the rest of the semester
and took her finals in a school office to avoid ridicule." More than 48,000
people attended the game. [Source: Lawsuit filed over text message on
St. Louis Cardinals board, KMOV, 9 Nov 2007; PGN-ed]
It seems that anyone can text a cell-phone message and have it displayed,
for a small fee. The expected uses are presumably proposing marriage,
announcing an engagement, wishing happy birthday, and other similar
occasions. However, this service clearly opens up all sorts of
opportunities for misinformation, but also opportunities for intentionally
having defamatory messages posted so that you can sue. Incidentally, KMOV
reminded its viewers that at the first home game of 2006, a proscribed
four-letter word appeared on the screen, which management attributed to a
"technical error". The KMOV website has lots of further discussion.
------------------------------
Date: Tue, 13 Nov 2007 19:23:17 +0200
From: "Shoshannah Forbes" <xslf@private>
Subject: The dangers of machine translation
Sending out machine translation without reading the result resulted in a
diplomatic incident:
http://www.guardian.co.uk/g2/story/0,,2206335,00.html?gusrc=rss&feed=technology
"So when indignant officials at the Dutch foreign ministry received an email
from a group of Israeli journalists that began, "Helloh bud, enclosed five
of the questions in honor of the foreign minister: The mother your visit in
Israel is a sleep to the favor or to the bed your mind on the conflict are
Israeli Palestinian," they might perhaps have guessed what had happened.
Sadly, they did not."
The Guardian claims that the journalists used the popular translation engine
Babelfish, but this appears to be incorrect. Babelfish doesn't handle
Hebrew. Hebrew sources indicate that they may have used Babylon.
Shoshannah Forbes http://www.xslf.com
[Also noted by Mark Brader. PGN]
------------------------------
Date: Wed, 14 Nov 2007 12:42:54 -0800
From: Rex Sanders <rsanders@private>
Subject: Security company e-mail undercuts user education
We've seen many reports of financial institutions sending e-mail virtually
indistinguishable from phishing and spam.
Lately, I've been in the market for new computer security hardware and
software. Security companies seem to have taken email lessons from the
worst financial institutions.
Some common problems in security company emails:
* "Click here if your email program has trouble displaying this email"
* Images and links that point to third party web sites.
* Unsubscribe links that point to third party web sites
These security companies are undercutting user security education. We have
a hard time keeping users from clicking on links in suspicious emails; we
don't need security firms reinforcing bad behavior.
Rex Sanders, USGS http://tinyurl.com/84kdo :-)
------------------------------
Date: Tue, 13 Nov 2007 14:20:38 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Dangerous Mix of Globalization and Software (Stephen Smoliar)
Stephen Smoliar's blog contains various items that might interest RISKS
readers.
There is one rather egregious example of a spelling corrector:
http://therehearsalstudio.blogspot.com/2007/04/dangerous-mix-of-globalization-and.html
The most recent, today, considers some of the problems that the San
Francisco Public Library is experiencing in its attempts to modernize:
http://therehearsalstudio.blogspot.com/2007/11/speak-out-against-defective-technology.html
------------------------------
Date: Fri, 16 Nov 2007 17:51:12 -0800
From: Mark Seecof <mseecof@private>
Subject: Re: Best practices to redact account numbers (Watson, RISKS-24.82)
Tom Watson's message (Risks 24.82) about redacting account
numbers attracted my attention (sorry I'm running behind).
Besides the risk associated with switching methods (access to old and new
redacted numbers revealed complete number), there is a risk with choice of
redaction schemes--and many knuckleheads are choosing wrongly nowadays.
Credit-card systems seem to provide cultural leadership in account-number
hashing. The idea is to show people enough digits so they know which of
their cards you want to refer to, but too few to let an observer guess the
whole number. Four digits works well. By the birthday paradox, it's not
likely you'll get collisions when customers have much less than 100 cards.
Even the shortest credit-card numbers are 12 digits long. The first few
digits identify the bank so they're easy to guess. The last digit is a
checksum so it says something about the rest, but an adversary will still
have to guess, say, four digits. Most cards have 15 or 16 digit numbers
now, making you guess seven or eight digits; an adversary will likely guess
someone else's number.
With (US) Social Security numbers and bank account numbers things are
different. The last four digits of the SSN are the critical ones! The
first five are easy to guess (they encode issuing location and date).
People think that it's smart to ape the last-four-digits scheme used with
credit-card numbers, but we don't show an SSN hash because people have
multiple SSN's, we show it to help distinguish people with similar names.
For that purpose the first few digits are adequate and much less sensitive.
Bank account numbers present a similar problem. The first digits often
identify branch and account type (I will pass over ABA check routing numbers
which are trivial to guess) so the trailing digits are generally more
sensitive. Most people need to see enough digits to tell which account out
of several they have with one bank (checking/savings/etc.) is the subject
of communication. For many banks, the best plan would be to show some
leading digits from the account number--even though they'll be the same for
many customers they'll be different for each account of any one customer.
It appears that someone at Watson's bank was aware of this years ago and set
up the best system. Then (perhaps along with some other "upgrades") some
dimwit decided that since it's good to show "last four digits" with credit
cards, it must also be good to show the last four digits of checking account
numbers. This kind of failure is why RISKS DIGEST will never lack for
material!
------------------------------
Date: Sat, 10 Nov 2007 11:45:18 +0100
From: Alex Burr <ajb44.geo@private>
Subject: Verizon phones make an audible alarm when 911 is dialed
Just the thing for those hostage and robbery situations - I don't think:
http://www.kvue.com/news/local/stories/110907kvueverizonalarm-bm.1f46e16ee.html
"The alarm is not ear-splitting, but it is loud enough to be heard at least
several yards away"
Verizon claims the FCC requires this. The FCC says it's not that stupid.
------------------------------
Date: Sun, 18 Nov 2007 03:02:49 +0000
From: jay-kahn@private
Subject: ACSAC 2007
Twenty-Third Annual Computer Security Applications Conference (ACSAC)
Practical Solutions To Real World Security Problems
December 10-14, 2007
Miami Beach Resort and Spa
Miami Beach, FL, USA
Cristina Serban, PhD, CISSP
2007 ACSAC Conference Chair
Hotel and Conference Registration at http://www.acsac.org/
[This message is unfortunately less timely than it ought to be. 19 Nov is
the deadline for early registration and the discounted hotel rate. PGN]
------------------------------
Date: Wed, 14 Nov 2007 14:47:02 +0000
From: a.zellweger@private (Dres Zellweger)
Subject: ICRAT - Air Transportation Research Symposium
[Dres is a long-time RISKS contributor, educator, and former FAA Advanced
Automation director. He has been relatively quiet in RISKS lately. PGN]
ICRAT 2008: Papers due 31 January, 2008 See www.ICRAT.org.
June 1-4, 2008 at George Mason University, Fairfax, VA
ICRAT is an excellent forum for young researchers within air transportation
to share their work, expand their professional network, and gain new
knowledge and inspiration. This third edition of ICRAT includes one day of
tutorials, two days of technical presentations and a doctoral symposium
where PhD students can expose their research problems to get advice from
established scientists in the field. Parallel invited workshops on Single
European Sky ATM Research and US NextGen initiatives are also expected.
ICRAT 2008 is jointly organized between EUROCONTROL Experimental Centre and
George Mason University, and is sponsored by the US Federal Aviation
Administration, NASA, the European Commission, and by EUROCONTROL.
Financial support for participating in this conference is available to a
limited number of young scientist and PhD students. We expect to be able to
be able to cover travel expenses, room and board for students from the
U.S. whose papers are accepted.
------------------------------
Date: Thu, 08 Nov 2007 15:15:33 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Network Security Hacks", Andrew Lockart
BKNTSCHK.RVW 20070921
"Network Security Hacks", Andrew Lockart, 2007, 0-596-52763-2,
U$29.99/C$38.99
%A Andrew Lockart
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 2007
%G 0-596-52763-2 978-0-596-52763-1
%I O'Reilly & Associates, Inc.
%O U$29.99/C$38.99 707-829-0515 fax: 707-829-0104 nuts@private
%O http://www.amazon.com/exec/obidos/ASIN/0596527632/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596527632/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0596527632/robsladesin03-20
%O Audience i Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 298 p.
%T "Network Security Hacks, 2nd Edition"
Chapter one lists twenty-two tips for using a number of utilities and
programs to enhance the security of UNIX systems. The explanations are
clear and specific, although you would probably have to be really familiar
with UNIX administration to get the full benefit of these suggestions.
Windows gets fourteen hacks in chapter two. While useful, these could have
had more explanation in some cases, in regard to the limitations and
pitfalls of the recommendations. A variety of tools that address aspects of
confidentiality are listed in chapter three. Almost all of the firewall
tools discussed in chapter four are for UNIX, although some do have Windows
versions. (The Windows firewall is discussed, but so poorly that one almost
suspects that the whole purpose is to force the reader to use the suggested
alternative.) Advice on securing various services and applications (mostly
from Guess What Operating System) is given in chapter five. Again, the bulk
of the network security tools discussed in chapter six are for UNIX, with
some Windows editions. The wireless tips, in chapter seven, work best with
UNIX. The same is true with the logging tips in chapter eight, although
there is mention of arranging to have Windows report to a syslogd. Network
monitoring, and some analysis thereof, is in chapter nine. Tunnels and VPN
(Virtual Private Network) products are detailed in chapter ten. Most of the
network intrusion detection material in chapter eleven concerns Snort. (You
are not my NIDS, you are a Snort!) Chapter twelve lists a few recovery and
response tools.
If you run a UNIX system and network, this book enumerates many useful
tasks, settings, and tools that will help to make your systems and network
more secure.
copyright Robert M. Slade, 2004, 2007 BKNTSCHK.RVW 20070921
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 17 Oct 2007 (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 for current volume
or ftp://ftp.sri.com/VL/risks for previous VoLume
<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
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
<http://www.acm.org/joinacm1>
------------------------------
End of RISKS-FORUM Digest 24.91
************************
This archive was generated by hypermail 2.1.3 : Mon Nov 19 2007 - 16:55:26 PST