RISKS-LIST: Risks-Forum Digest Monday 25 February 2008 Volume 25 : Issue 06
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/25.06.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Securing The Wrong Spaces: A Lesson (Paul Ferguson via Gregory Hicks)
Software problem at London Heathrow Terminal 4 affects baggage (Peter Mellor)
YouTube outage blamed on Pakistan (Amos Shapir)
One way not to conduct Internet voting (Peter Kaiser)
Being declared dead ruins life (Andrew Koenig)
New RFID ticketless bus system in Brisbane goes live... with glitches
(George Michaelson)
US Treasury "TreasuryDirect" Web site security enhancements (Jonathan Kamens)
EU money for 4 small businesses IT risk mgmt pilot (Patrick O'Beirne)
Cold Boot Attacks on Disk Encryption (Jacob Appelbaum, Declan McCullagh)
Illegal drag race kills eight (John Curran)
Free-to-download password cracker (Peter Mellor)
Re: the GPS miracle (Steven M. Bellovin)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 21 Feb 2008 01:41:57 -0800 (PST)
From: Gregory Hicks <ghicks@private>
Subject: Securing The Wrong Spaces: A Lesson
- - Begin Forwarded Message - -
From: "Paul Ferguson" <fergdawg@private>
Date: Thu, 21 Feb 2008 07:08:58 GMT
Excerpt from techdirt.com.
A brand new Japanese warship that apparently has the country's latest and
greatest radar system, was unable to spot a fishing boat in its path,
leading to a collision and two missing fishermen. This is raising all
sorts of questions about the quality of the radar system, but some are
saying that the collision was really due to human error and that the radar
system is designed more to watch out for missiles in the air, rather than
ships below it.
That's a fair enough response, but does point out that vulnerabilities
come from all directions -- and you can make the best system in the world,
but if it's looking for the wrong thing, it won't stop something bad from
getting through. It does seem rather ironic to set this ship up to be the
best in the world at spotting threats from the sky -- and forget to
include a decent system to find threats right next to it in the sea.
Link: http://techdirt.com/articles/20080219/021718291.shtml
There is a great security lesson to be learned here -- if you're focused on
securing only a subset of the entire threat landscape, the insecurities will
generally occur in the places you're not focusing on.
Focus on the Big Picture.
"Fergie", a.k.a. Paul Ferguson, Engineering Architecture for the Internet
fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
[Gregory Hicks, Cadence Design Systems, 555 River Oaks Pkwy, San Jose,
CA 95134 408.576.3609]
------------------------------
Date: Thu, 21 Feb 2008 19:44:45 EST
From: MellorPeter@private
Subject: Software problem at London Heathrow Terminal 4 affects baggage
On 19 Feb 2008, the British Airports Authority (BAA) warned passengers via
its website that a software problem was causing a reduction in baggage
handling capacity. http://www.heathrowairport.com/ (According to the same
website, the system is now fully operational.)
British Airways (BA) went one better and warned passengers via its website
that long-haul passengers who turned up with check-in bags would not be
allowed to fly! This ban affected economy class only. (Of course. What
did you expect?) http://www.britishairways.com/travel/home/public/en_gb (An
update on BA's website dated 21st February also announces that the system
has been reinstated.)
BA's ban extended to transfer passengers. Precisely what a long-haul
passenger who transferred to a BA flight at T4 already laden with hold
baggage was supposed to do, was not explained.
Source of story:
http://www.theregister.co.uk/2008/02/20/heathrow_software_glitch/
Peter Mellor; Mobile: 07914 045072; email: MellorPeter@private
Telephone and Fax: +44 (0)20 8459 7669
------------------------------
Date: Mon, 25 Feb 2008 17:21:11 +0200
From: Amos Shapir <amos083@private>
Subject: YouTube outage blamed on Pakistan
Pakistan's attempts to block access to YouTube have been blamed for a near
global blackout of the site on Sunday. Full story at:
http://news.bbc.co.uk/1/hi/technology/7262071.stm
(This looks like a misguided attempt to change DNS routing).
------------------------------
Date: Tue, 19 Feb 2008 23:18:05 +0100
From: Peter Kaiser <djc@private>
Subject: One way not to conduct Internet voting
Democrats Abroad, the US Democratic Party's organization for its members
living outside the USA, sends delegates to the party's nominating
convention. This year Democrats Abroad held a "Global Primary" to select
the delegation's candidate. People could vote in person in a few places,
but the intention was for most of the voting to be over the Internet.
Howard Dean, Democratic Party chair, said that the party would be observing
the process closely, because it would be significant if Democrats Abroad
held a secure, well-run election over the Internet.
But the "Global Primary" wasn't secure or well-run.
To begin with, registration to vote over the Internet was managed on
unsecured web pages, an extraordinarily basic error. I brought this to the
attention of a party official immediately; to her credit, she brought the
objection up to the national organization, which responded that it didn't
matter, because the actual voting would be secure. That's a serious lack
of understanding: if registration isn't secure, then voting isn't secure
because the registree's information can be hijacked. That information is
also the kind that's used for identity theft.
Voting was supposed to be secure because it required a "ballot number" and
PIN. These were distributed by email. Oops! Someone who could capture or
eavesdrop the outgoing mail stream delivering that information could own
the vote in its entirety. Someone who could eavesdrop the mail coming to a
particular address could steal that vote.
Then there was the actual process of voting, which was handled (on secured
Web pages) by a third-party company. I observed a vote. After supplying
the "ballot number" and PIN, the voter was informed that his browser lacked
an essential plugin which would have to be installed before the process
could continue. The "plugin" was Java. The voter was on a slow, expensive
dialup line which would have made it very painful to find and download the
software, but luckily I happened to have the Java installer with me, and I
started it up.
Oops! The voter was using a Windows account without the privilege to
install that software. The sketchy voting instructions indicated nothing
about what would happen if the voter had to interrupt the process. Was the
signin for one time only? If the user stopped the browser, would the
process time out and give him another chance to vote later? There was no
way to know: it was certain only that the process couldn't continue until
the browser could use Java, and the user hadn't the privilege to install
the software. In the event, I used Windows "run as" to install Java from
the administrative account, and the voter was able to carry the voting
process to the end. Could most users have done this? I doubt it.
The vote itself was interesting, because along with the legitimate
candidates it presented some who had formally withdrawn their candidature
-- e.g., John Edwards, and there was no indication what to do about that.
What happened to votes for non-candidates? No way to know. And why can't
an Internet vote be kept current as of when it begins by simply not
presenting non-candidates?
Near the end of the process, after submitting his vote, the voter was given
the choice of quitting or printing out a page showing his vote. Democrats
Abroad had encouraged people to print out their votes, but it's hard to
imagine why, since the special vote-printing popup page indicated clearly
that it wasn't binding. So why bother?
There are well-known risks at every stage of the episode, so I repeat: that
whole process was neither secure nor well-run; moreover, its collection
of personal information using unsecured Web pages exposed participants to
the risk of information theft, and delivering notionally secure information
by email is painfully bad judgment. The episode proves nothing except that
well-intentioned people continue to make elementary but serious errors in
designing and setting up processes that must be safe at every step if they
are to be meaningful.
Perhaps someone will bring this up to Mr Dean. My mail to the Democratic
National Committee hasn't been answered.
------------------------------
Date: Tue, 19 Feb 2008 09:54:46 -0500
From: "Andrew Koenig" <ark@private>
Subject: Being declared dead ruins life (Re: RISKS-25.05)
That item reminds me of something that happened many years ago.
I had two colleagues who I'd rather not name, as you'd surely recognize
them. One of them had the habit of letting (paper) mail pile up in his
inbox for a week or two, then dealing with it all at once. The other was a
bit of a practical joker, who one day took all of the mail piled up in the
inbox, wrote "DECEASED" on each piece, and put in the outbox.
I am told that it took many months to sort out the resulting mess.
------------------------------
Date: Sat, 23 Feb 2008 15:47:11 +1000
From: "George Michaelson" <ggm@private>
Subject: New RFID ticketless bus system in Brisbane goes live... with glitches
Brisbane has deployed an RFID based ticketless smartcard bus system its
calling the 'go' card. The integrated travel system is described at
http://en.wikipedia.org/wiki/TransLink_%28South_East_Queensland%29
And the ticketing system provider is Cubic
http://en.wikipedia.org/wiki/Cubic_Transportation_Systems%2C_Inc.
The system has been under test in the northern part of the network, and will
be deployed citywide on Monday the 25th. Its actually already live, its just
the card supply/distribution issue which is formally released next week.
The system demands you cardswipe on and off, and computes journey values,
and inter-system transfers. It uses GPS in buses and ferries, and station
boundaries. From my observations, the system uses GPS quite heavily, and the
drivers have a low level of engagement (at this time at least) in the
system, concentrating on the (hopefully fewer) cash paying fares.
I got myself and my son a card, and we found it was live on friday, so used
it.
>From one days use, I had one problem, for 2 journeys. One was that because
the bus uses GPS, and bus drivers in extremis stop at non-scheduled stops,
but the readers are designed to not enable card operations except either
when commanded by the driver, or at scheduled stops, it was not able to
cardswipe me off. (presumably, after driver training, they will know how to
enable this).
The second was that having not been recorded off, yet getting on another bus
inside 5 minutes, while I was carded off the first bus by the system, it
refused to consider it a legal transfer, and recorded two journeys, one for
the maximum fare. Refund pending, 10 day turnaround, after I rang in.
There is a third fault, recorded in local newspapers: the system doesn't
work in underground stations without driver overrride, presumably because
the GPS can't work. Again, resolved after training, if they
command/override.
The system already had a 'upgrade day' failure when an attempted test at a
few locations accidentally took down a major portion of the network for
railway stations.
My observation: Any new system is going to have glitches, but from my
experience, failure for a random singleton is a bit of a worry. At least my
son had a perfect score on his one. Operator training would have resolved my
problem, if its still lacking 2 days before official launch, you have to
worry that the refund phone desk is going to melt down next week. So if I
take the best case, from 2 sample individuals for 4 journey instances on 8
buses, thats still 12% failure. On a lightly loaded system (both of us were
the only card users for our journeys)
I could complain that the system uses simply AWFUL warning messages such as
"card reader not in service" when the bus is moving, rather than something
human-centric such as "bus in motion: swipe off disabled" (or something)
-the system as a whole is quite obviously working, the readers should not be
implying they are dysfunctional.
But more worryingly, the systems designers seem to be making some system
design mistakes here. Humans and Human systems ARE NOT BLACK BOXES. So by
designing a system with GPS, which attempts to forbid fare dodges by
refusing to card off except at scheduled stops, they have taken two very
useful 'side effect' behaviours out of the bus system: getting off the bus
at non-scheduled stops, and getting off the bus between stops. Both are very
common, both are until now entirely normal for many users of the system but
both are apparently outside their system design plan and both have a strong
financial penalty if the driver now doesn't (or can't) command/override the
system. And designing a system with GPS, but which can't work in underground
stations, when the system has at least two, with several more in planning,
seems odd.
Thirdly, it seems unfortunate that they can card me off the first bus when I
card on the second, but can't short-circuit the excess fare reclaim. I'm
trying to understand the likelihood that what that represents is an
attempted gaming of the system, vs a legitimate user who is continuing their
trip. I would have expected that it was within the system loss tolerances to
at least try to start it preferencing the good case. Instead of which, if
you don't register online, and audit your card, you can wind up loosing
quite significant amounts of money if the journey you don't card 'off' on
has a high maximum value. For instance, the stop I did get off on, and the
stop I did get on the next bus were within 150m of each other. I wonder if
the GPS precision has been dialed up too high? (nobody should care about bus
journeys under 150m, and the same card being used inside 30min inside 150m
distance looks to ME like a valid event)
I still laud Brisbane Transport for doing this. Integrated ticketing is
wonderful, as anyone who has used the Hong Kong system, or any of the
worldwide 'Oyster' card deployments which I believe followed on from it. By
comparison Sydney transport has just imploded on a smartcard contract, and
their bus operator is buying up surplus ex-Brisbane driver-operated ticket
consoles, to expand the pre-RFID/smartcard system.
On the more security-conscious level, bus passengers who use the system, and
register the card (you have to, to claim refunds or ensure against cardloss,
which can hold up to $AU 200 in value) are now positionally accurate when on
a bus to within 10m, which presumably has some Philip-K-Dick manifestation
for the (police)man amongst us.
------------------------------
Date: Tuesday, January 29, 2008 8:06 PM
From: "Jonathan Kamens" <jik@private>
Subject: US Treasury "TreasuryDirect" Web site security enhancements
The US Treasury offers www.TreasuryDirect.gov for purchasing and managing a
portfolio of securities issued by the Federal government.
They've made some effort over time to make the site secure, and they've
recently been beefing up security. I'd like to share details about two of
their new security features.
When you log into the site, it asks you for your account number and your
password. However, you can't type your password. Instead, you are
presented with a "virtual keyboard" whose keys have been scrambled, such
that you have to hunt around for the characters in your password and click
them one by one in order to enter it.
Above the keyboard, it says, "A virtual keyboard, with keys that display in
random order, is available to deter others from learning your password."
The words "virtual keyboard" are a link, which pops up the following text
(from
<http://www.treasurydirect.gov/indiv/help/TDHelp/help_ug_274-SecFeaturesProt
ectAcctLearnMore.htm>
<http://www.treasurydirect.gov/indiv/help/TDHelp/help_ug_274-SecFeaturesProt
ectAcctLearnMore.htm>) when you click on it:
Virtual Keyboard: The virtual keyboard is one of many new security
features introduced in TreasuryDirect as part of our on-going commitment to
heightened password and account security to protect our customers'
investments. The advantage of using the virtual keyboard, with keys that
display in random order each time you log in, is that others are deterred
from learning your password and Access Card information.
When Java-Script is enabled, each time you arrive at the "Access your
TreasuryDirect Account" page to log in, you will be presented with this
virtual keyboard to enter your password. You'll use your mouse with the
virtual keyboard to enter the letters, numbers, and special characters that
are contained in your password.
If you have received your Access Card, you'll also use the virtual keyboard
to enter your Access Card values.
(More about the Access Card in a minute.)
To enter my password with this new keyboard, I must move my mouse slowly
over it, search for each of the characters in my password, and pause over
each one while I click it and then look at and count the number of
characters in the password field to confirm that the last one was entered
correctly. Then I have to do it all over again because I made at least one
mistake the first time. All this on a "keyboard" in full view of anyone who
can see my screen.
It is unfathomable to me how the people who designed this feature could
possibly think that it is more secure than typing a password on a keyboard.
Now, about those "Access Cards". A few weeks ago, I got email from the
Treasury notifying me that they were going to be sending me an access card
which would be required in the future for accessing my account. About a
week ago, they sent me a separate email message notifying me that the card
would be arriving very soon, and I should contact them if I did not receive
it within ten days. They also said that shortly after I received the card,
I would no longer be able to log into the site without it.
The card itself has a bar code, a nine-digit decimal serial number, and a
grid with ten columns labeled A through J and five rows labeled 1 through 5.
At the intersection of each row and column is a random letter or number, for
a total of fifty. Once the access card is enabled for my account, after I
enter my username and password, the site will display a drop-down list with
several serial numbers, only one of which is actually mine, and with three
grid coordinates (e.g., "C2"). To finish logging in, I will have to select
the correct serial number and then enter (using the virtual keyboard) the
three characters corresponding to the displayed grid coordinates. A
demonstration of how this works can be viewed at
<http://www.treasurydirect.gov/indiv/help/TDTutorial/tutorial.htm>
<http://www.treasurydirect.gov/indiv/help/TDTutorial/tutorial.htm>.
I don't know whether this technology was purchased from a third party or
invented by the Treasury. It's an interesting attempt to implement
inexpensive two-factor authentication. It's better than nothing, but it's
obviously useless at preventing illicit access by people who are in physical
proximity to the account owner, since they can simply sneak a photocopy of
the card when the owner isn't looking.
------------------------------
Date: Thu, 21 Feb 2008 10:11:00 +0000
From: "Patrick O'Beirne" <pob@private>
Subject: EU money for 4 small businesses IT risk mgmt pilot
http://www.enisa.europa.eu/pages/micro_enterprises_pilot.htm
Building information confidence with micro enterprises
Pilots for the introduction of Risk Management process
ENISA issues a call to identify potential pilots to participate in a Risk
Management promotion activity. The selected pilots will be financially
supported by ENISA with maximum 20000 euros to install Risk Management
within their IT infrastructure and perform an initial Risk Assessment. The
selection criteria are stated below (see Background).
Potential pilots are requested to use the attached form to send information
relevant to their organisation and to the scope of a possible Risk
Management introduction project. Proposals can be sent to ENISA until 29 Feb
2008.
Main criteria for the pilots are their size, sector and geographical spread
among different areas of Europe. In order to select potential pilots ENISA
will use the following selection criteria:
With the pilot ENISA wants to support small and micro enterprises in the
introduction of Risk Management The potential pilot can be performed in
cooperation with a multiplier organisation that guarantees the inclusion of
multiple small/micro enterprises (i.e., small SMEs) The benefits from the
pilot for the participating enterprises must be evident The pilot will
maximise inclusion of multiple stakeholders (e.g. dissemination potential)
The pilot consists of a group of small/micro organisations building up a
network (e.g. part of a supply chain, independent members of a distributed
structure etc.) The subject of the pilot must be the available ENISA
material or alternatively an existing good practice in the area of Risk
Management in Europe The pilot activity will be defined in some detail
(plans, participants).
Patrick O'Beirne, Systems Modelling Ltd. http://www.sysmod.com/
(+353)(0) 5394 22294
------------------------------
Date: February 21, 2008 12:34:09 PM EST
From: Jacob Appelbaum <jacob@private>
Subject: Cold Boot Attacks on Disk Encryption (via Dave Farber's IP)
With all of the discussions that take place daily about laptop seizures,
data breech laws and how crypto can often come to the rescue, I thought
the readers of IP might be interested in a research project that was
released today. We've been working on this for quite some time and are
quite proud of the results.
Ed Felten wrote about it on Freedom To Tinker this morning:
http://www.freedom-to-tinker.com/?p=1257
"Today eight colleagues and I are releasing a significant new research
result. We show that disk encryption, the standard approach to
protecting sensitive data on laptops, can be defeated by relatively
simple methods. We demonstrate our methods by using them to defeat three
popular disk encryption products: BitLocker, which comes with Windows
Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used
with Linux. The research team includes J. Alex Halderman, Seth D.
Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A.
Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten."
"Our site has links to the paper, an explanatory video, and other
materials."
"The root of the problem lies in an unexpected property of today's DRAM
memories. DRAMs are the main memory chips used to store data while the
system is running. Virtually everybody, including experts, will tell you
that DRAM contents are lost when you turn off the power. But this isn't
so. Our research shows that data in DRAM actually fades out gradually over a
period of seconds to minutes, enabling an attacker to read the full contents
of memory by cutting power and then rebooting into a malicious operating
system."
Our full paper with videos and photos can be found on the Princeton
website: http://citp.princeton.edu/memory/
------------------------------
From: Declan McCullagh <declan@private>
Date: February 21, 2008 3:57:43 PM EST
Subject: Re: Cold Boot Attacks on Disk Encryption (via Dave Farber's IP)
The paper published today makes some pretty strong claims about the
vulnerabilities of Microsoft's BitLocker, Apple's FileVault, TrueCrypt,
Linux's dm-crypt subsystem, and similar products.
So I put the folks behind it to a test. I gave them my MacBook laptop with
FileVault turned on, powered up, encrypted swap enabled, and the screen
saver locked.
They were in fact able to extract the 128-bit AES key; I've put screen
snapshots of their FileVault bypass process here:
http://www.news.com/2300-1029_3-6230933-1.html
And my article with responses from Microsoft, Apple, and PGP is here:
http://www.news.com/8301-13578_3-9876060-38.html
Bottom line? This is a very nicely done attack. It's going to make us
rethink how we handle laptops in sleep mode and servers that use encrypted
filesystems (a mail server, for instance).
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
------------------------------
Date: Tue, 19 Feb 2008 13:30:00 -0500
From: "Curran, John" <John.Curran@private>
Subject: Illegal drag race kills eight
Last weekend an illegal drag race in the Washington, DC suburbs ended in
tragedy when a car (not involved in the race) plowed into a crowd of people
who had gathered to watch the race. This column from the *Baltimore Sun*
puts an interesting light on the idea of risks for those who routinely take
part in something like the race.
The writer spoke to a scientist who specializes in risk perception. The key
remark from the piece:
"Peters is a research scientist who specializes in risk perception, a
psychologist who works for a think tank called Decision Research that
studies, basically, why people do what they do. I had called seeking wisdom
on why someone - or many someones, as it turns out - would gather on a dark,
desolate highway in the middle of the night and wander onto it to watch
people drive like maniacs.
Peters had seen news reports of the crash, and was struck by the seemingly
festive nature of the gathering, until it turned fatal, that is.
"Everyone's out there, it seems like it's good old-fashioned fun, it's a
very party-like atmosphere," she said. "There's the familiarity of it -
people had done this before, and it had never been a problem before."
Peters said it's that familiarity that makes even the obviously risky -
walking onto a thoroughfare, after two fast and furious cars have screamed
past you - seem like perfectly normal behavior."
http://www.baltimoresun.com/news/local/bal-md.marbella19feb19,0,2107578.column
John Curran, OMM Program IT Security Manager, CISSP, CISM, IAM 703-787-1712
[See also The Psychology of Risks, Dr. Leonard S. Zegans, in the December
2007 Inside Risks column in the *Communications of the ACM*.
http://www.csl.sri.com/neumann/insiderisks07.html#211]
------------------------------
Date: Mon, 25 Feb 2008 09:59:59 EST
From: MellorPeter@private
Subject: Free-to-download password cracker
If this is as good as it purports to be, let's hope that only the white-hats
use it!
RainbowCrack is a general propose implementation of Philippe Oechslin's
faster time-memory trade-off technique. In short, the RainbowCrack tool
is a hash cracker. A traditional brute force cracker try all possible
plaintexts one by one in cracking time. It is time consuming to break
complex password in this way. The idea of time-memory trade-off is to do
all cracking time computation in advance and store the result in files so
called "rainbow table". It does take a long time to precompute the
tables. But once the one time precomputation is finished, a time-memory
trade-off cracker can be hundreds of times faster than a brute force
cracker, with the help of precomputed tables.
http://www.antsight.com/zsl/rainbowcrack/index.php
Peter Mellor; +44 (0)20 8459 7669 MellorPeter@private
------------------------------
Date: Tue, 19 Feb 2008 04:28:57 +0000
From: "Steven M. Bellovin" <smb@private>
Subject: Re: the GPS miracle (Mintz, RISKS-25.05)
I'm glad it's worked for you. I find that it *usually* works well for me.
However, mine -- purchased just 2.5 months ago -- tried to steer me through
dead-end streets twice on a single drive within 20 miles of my house in New
Jersey... The first time, I decided to see if the Dead End sign was wrong.
It wasn't; the GPS was.
The other thing I noticed -- from getting it wrong a couple of times -- is
that at complex intersections or where two possible turns are very close to
each other, it's very easy to misunderstand which turn it wants you to make.
I doubt there's any good technical solution to that short of a heads-up
display showing the route it wants you to take, overlaid on reality.
It is great, and I still use it. But I'm much less sanguine about the
correctness of its database.
Steve Bellovin, http://www.cs.columbia.edu/~smb
------------------------------
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 25.06
************************
This archive was generated by hypermail 2.1.3 : Mon Feb 25 2008 - 12:00:11 PST