RISKS-LIST: Risks-Forum Digest Thursday 27 April 2006 Volume 24 : Issue 26
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.26.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
MV-22 Tiltrotor Crash, March 2006 (Peter B. Ladkin)
Verizon's Aggressive New Spam Filter Causing Problems (From Slashdot)
Congress readies new bill to expand DMCA, not shrink it (Declan McCullagh)
Triple DES Upgrades May Introduce New ATM Vulnerabilities (Redspin)
Another security/privacy breach at the University of Texas (PGN)
Super Bowl ticket scam (Connie Paige via Monty Solomon)
Opticon: A cheap way to get to work faster (Jeremy Epstein)
Radar for your PC (Erling Kristiansen)
RFID Zapper (Al Mac)
Personal Electronic Devices on Commercial Aircraft (Peter B. Ladkin)
PDF Hell for SA Bank (Colin Brayton)
Honeypot Cars (Dawn Cohen)
CfP: IEEE S&P special issue on malware (Ivan Arce)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 26 Apr 2006 11:11:57 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: MV-22 Tiltrotor Crash, March 2006
On 27 Mar 2006, an MV-22 tiltrotor aircraft suffered a Class A mishap at
Marine Corps Air Station New River, N.C. No one was injured but the aircraft
was broken. The incident was reported in *Aviation Week*, 10 Apr 2006, p.29,
as well as Flight International, 11-17 Apr 2006, p.9.
*AvWeek* says that during a post-maintenance check, the aircraft performed an
unintended 3.1-second flight during which it climbed to about 7 ft altitude
due to an engine/rotor overspeed. It descended rapidly, with the right
landing gear taking most of the loads of the 9-fps impact. The right wing
broke off at the root, as it is designed to do (the engine is at the end of
the wing).
Flight International reports that the crew was switching between
Full-Authority Digital Engine Controllers (FADECs) during pre-flight checks
after an engine change. The selected controller failed, causing a power
increase to one engine. The control system increased prop-rotor pitch to
prevent an overspeed, which caused the aircraft to lift off rapidly. The
system detected the failure and switched to the good FADEC after 2-3
seconds, causing loss of lift and the rapid descent.
According to *AvWeek*, Marine Corps Col. Bill Taylor said that the root
cause is not yet known, but it is likely associated with the A-FADEC on the
number two engine, as well as a "V-22 idiosyncrasy in how the aircraft
handles an engine overspeed". It is hoped that revised FADEC SW will be
available and certified by October. AvWeek says that Goodrich is the FADEC
supplier; Flight International reports that Rolls Royce is to modify the
FADEC SW.
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Tue, 25 Apr 2006 08:08:57 -0400
From: Monty Solomon <monty@private>
Subject: Verizon's Aggressive New Spam Filter Causing Problems (Slashdot)
[ScuttleMonkey on Slashdot:]
Aviancarrier writes "Verizon DSL has turned on a very aggressive spam filter
that is blocking lots of long-time legitimate e-mails. E-Mails get bounced
with an error: 'XX@private: host relay.verizon.net[206.46.232.11] said:
550 E-Mail from your E-Mail Service Provider is currently blocked by Verizon
Online's anti-spam system. The e-mail "sender" or E-Mail Service Provider may
visit http://www.verizon.net/whitelist and request removal of the block.'
That whitelist web page lets you request one address at a time to be
whitelisted with no guarantee for their response time to process it. I have
tested multiple e-mail sources and only one got through. As a VZ customer, I
just spent 28 minutes on a call to tech support, eventually got a supervisor
who knows nothing about the new spam feature, and would only agree to e-mail
a manager who doesn't work weekends about it. I warned her that VZ has a
public relations problem but she was too clueless to understand." Many users
have submitted this problem so it seems to be a pretty far reaching
problem. There is also a discussion going on over at Google about this
problem. ...
http://it.slashdot.org/article.pl?sid=06/04/24/1538205
------------------------------
Date: Mon, 24 Apr 2006 14:34:28 -0700
From: Declan McCullagh <declan@private>
Subject: Congress readies new bill to expand DMCA, not shrink it
I've placed the text of the draft bill here:
http://www.politechbot.com/docs/house.dmca.copyright.bill.042406.pdf
http://news.com.com/Congress+readies+broad+new+digital+copyright+bill/2100-1028_3-6064016.html
[Revised 24 Apr 2006]
For the last few years, a coalition of technology companies, academics and
computer programmers has been trying to persuade Congress to scale back the
Digital Millennium Copyright Act.
Now Congress is preparing to do precisely the opposite. A proposed
copyright law seen by CNET News.com would expand the DMCA's restrictions on
software that can bypass copy protections and grant federal police more
wiretapping and enforcement powers.
The draft legislation, created by the Bush administration and backed by
Rep. Lamar Smith, already enjoys the support of large copyright holders such
as the Recording Industry Association of America. Smith, a Texas Republican,
is the chairman of the U.S. House of Representatives subcommittee that
oversees intellectual property law.
[...remainder snipped...] [by Declan!]
------------------------------
Date: Mon, 17 Apr 2006 12:23:30 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Triple DES Upgrades May Introduce New ATM Vulnerabilities (Redspin)
[In the following 13 Apr 2006 press release, Redspin (an independent
auditing firm based in Carpinteria, CA) suggests that the recent mandated
upgrades of ATMs to support triple DES encryption of PINs has introduced
new vulnerabilities into the ATM network environment -- because of other
changes that were typically made concurrently with the triple DES
upgrades. http://www.paymentsnews.com/2006/04/redspin_triple_.html]
Redspin, Inc. has released a white paper detailing the problem. Essentially,
unencrypted ATM transaction data is floating around bank networks, and bank
managers are completely unaware of it. The only data from an ATM transaction
that is encrypted is the PIN number.
"We were in the middle of an audit, looking at network traffic, when there
it was, plain as day. We were surprised. The bank manager was
surprised. Pretty much everyone we talk to is surprised. The card number,
the expiration date, the account balances and withdrawal amounts, they all
go across the networks in cleartext, which is exactly what it sounds like --
text that anyone can read," explained Abraham.
Ironically, the problem came about because of a mandated security
improvement in ATMs. The original standard for ATM data encryption (DES) was
becoming too easy to crack, so the standard was upgraded to Triple DES. Like
any home improvement project, many ATM upgrades have snowballed to include a
variety of other enhancements, including the use of transmission control
protocol/Internet protocol (TCP/IP) -- moving ATMs off their own dedicated
lines, and on to the banks' networks.
More and more banks now run their ATMs through their own computer network
before the information goes on to a centralized processor. While having the
ATMs on the bank's network instead of a bunch of individual, dedicated lines
is much more economical and much easier to manage, it greatly increases
their security exposure.
The fact that ATM data isn't encrypted wasn't a problem when the information
was going across dedicated lines, but now that it goes through the bank's
Internet-connected system before going to a processor, it creates unexpected
opportunities for crime and mischief. A hacker tapping into a bank's network
would have complete access to every single ATM transaction going through the
bank's ATMs.
"Our biggest concern is that not many bank managers know this," says
Abraham. "They assume that everything is encrypted. It's not a terrible
assumption, so it's no wonder that most bank managers we've talked to are
unhappy to discover this after spending $60,000 to upgrade an ATM.
"Fortunately," continues Abraham, "prevention isn't that complicated, as
long as bankers are aware that there is a potential problem. ATM machines
need to be kept separate from the rest of the bank's computer network, to
try to recreate that direct line to the processor. Also, Redspin is
developing a tool to help bankers determine their level of
vulnerability. This white paper is all about raising awareness."
------------------------------
Date: Tue, 25 Apr 2006 15:34:42 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Another security/privacy breach at the University of Texas
Nearly 200,000 electronic records at the University of Texas at Austin's
business school have been illegally accessed, including SSNs and possibly
bio info on faculty, students, staff, and alums. The previous breach
occurred in 2003, resulting in a former UT student receiving five years of
probation and having to pay $170,000 in restitution for accessing almost
40,000 SSNs. Last year, a former UT student received five years probation
and was ordered to pay $170,000 in restitution for hacking into the school's
computer system in 2003 and accessing almost 40,000 Social Security numbers.
[Source: University of Texas Probes Computer Breach, Associated Press item,
23 Apr 2006; PGN-ed]
------------------------------
Date: Wed, 26 Apr 2006 00:15:24 -0400
From: Monty Solomon <monty@private>
Subject: Super Bowl ticket scam (Connie Paige)
Michael Deppe is facing six fraud charges. He reportedly offered tickets
for the 2005 Super Bowl on the Internet for about $7500 for a pair of seats,
never delivered tickets to 68 people, and pocketed $370,000. [Source:
Connie Paige, *The Boston Globe*, 23 Apr 2006; PGN-ed]
http://www.boston.com/news/local/articles/2006/04/23/would_you_trust_this_man_to_sell_you_super_bowl_tickets_on_the_internet/
------------------------------
Date: Tue, 18 Apr 2006 06:38:45 -0700
From: Jeremy Epstein <jeremy.epstein@private>
Subject: Opticon: A cheap way to get to work faster
It's been public information that there are devices ("Opticon" seems to be
one brand name) that can cause traffic signals to turn green, intended for
use by emergency vehicles. Not surprisingly, there are black-market devices
that send the appropriate signals (or perhaps they're the real thing, and
not black-market).
What's interesting in the following article is that someone has been
successfully using this technique for two years, and was fined $50. Looking
at it from a cost effectiveness perspective, seems that $50 is a pretty good
(albeit illegal) investment in getting where you're going faster for two
years. IMHO, one has to be something of a sociopath to use such a device,
because it's saying "my convenience is more important than yours" -- not
very different from pushing to the front of a line in a grocery store or
highway.
http://www.cnn.com/2006/US/04/18/traffic.changer.ap/index.html
Incidentally, in RISKS-23.34, Russ Perry Jr mentions an interesting problem
with emergency vehicles using Opticon devices approaching from two
directions at once, but I couldn't locate any other references to this
technology in the RISKS archives.
------------------------------
Date: Thu, 20 Apr 2006 21:05:13 +0200
From: Erling Kristiansen <erling.kristiansen@private>
Subject: Radar for your PC
>From AVWeb, The Internet's Aviation Magazine & News Service
(http://www.avweb.com/newswire/12_16b/briefs/192056-1.html)
> With the AerFlight Virtual Radar
> <http://www.aircraftspruce.com/catalog/avpages/aerflight.php> system, just
> about any desktop PC can be turned into a virtual ATC-style radar
> screen. The AerFlight captures the Mode-S signals emitted by aircraft.
> Users can control parameters such as range, data displayed, waypoints and
> geographic outlines. Online databases provide extensive details for each
> aircraft. AerFlight VR software also can communicate with other users,
> providing real-time, live airspace traffic positioning around the
> world. The system is being marketed as a security asset and to anyone with
> an interest in what's going on in the airspace above them, including
> flight departments, FBOs, flight schools and aviation enthusiasts. Notes
> can be ascribed and activity histories stored. The system consists of an
> antenna, receiver, and software package, and sells for about $900.
[Mode-S is a so-called secondary surveillance radar data link that returns
not only the identity of an aircraft, but also its 3-D position, and maybe
some other flight data, in response to radar interrogation. I suppose a
similar device could be built to eavesdrop on ADS-B (Automatic Dependent
Surveillance - Broadcast), an emerging system in which aircraft broadcast
their position, so ATC and aircraft in the vicinity can form a picture of
the traffic - EK]
If I had any plans to interfere with flying aircraft in a violent manner, I
would buy this device!
[According to a usually reliable RISKS reviewer, Mode S transponders are
required to transmit pressure altitude (in 25-ft increments) but not
latitude-longitude, so a "3-D position" is not necessarily calculable from
a Mode S transponder return. There is space in a Mode S return, however,
to transmit additional data, such as lat-long coordinates from GPS, if the
aircraft has these data and if they are desired for other protocols.
The transponder specs are publicly available from international sources
(they must be: partly because they are administrative law in some
countries which require such equipment in commercial aircraft operating
there). The basic returns are cleartext, public information, and should
remain so (aviators like to know - are required to know - where everyone
else is in the sky). Building a return-decoder as described is technically
straightforward, and whether you put the SW in a proprietary avionics box
or sell it separately seems to me to be basically a business decision. SW
that deciphers transponder returns helps goodies and baddies alike. PGN]
------------------------------
Date: Thu, 20 Apr 2006 10:13:49 -0500
From: Al Mac <macwheel99@private>
Subject: RFID Zapper
You might be interested in this development.
There is a window of opportunity for commercialization.
https://events.ccc.de/congress/2005/wiki/RFID-Zapper(EN)
As the title implies, some hobbyist has come up with what it takes for a
paranoid person to obliterate any RFID tags that might be on consumer
merchandise, or where not expected or wanted. You might also scroll to the
bottom & read the CAUTION = ROFL.
I imagine that there will be a consumer market for this.
People who want one but do not have the personal what it takes to build
stuff in their garage with assurance the contraption works right, and that
they not injure themselves before getting it completed. Call this a niche
industry that will attract a lot of imitators. To be profitable it needs
mass production like on a circuit board assembly line.
* Then the next market needed will be some way to assure purchasers that
the RFID Zapper that THEY got really works.
* Then the next society development will be that objects where RFID was
inserted for purposes of identification, like in ID cards, Passports etc.
will malfunction because someone had used the RFID Zapper on them,
rendering those people's ID unusable for the intended purposes.
* Then stores, and other institutions, will have to institute rules that
people are not allowed to enter their premises carrying an RFID Zapper, so
as to prevent unauthorized usage on the store merchandise.
* Then the next result might be that RFID Zappers will get declared to be
illegal ... although I expect this will be a few years away ... the effort
to illegalze RFID Zappers may get a lot more attention from the general
public than the usual illegalization of technology tools.
There have been several problems with RFID deployment so far.
* There is the mass public panic over conspiracy theories, leading to a ton
of Urban Legends, of which there is a glimmer of validity at the
fringes. There are in fact some risks of abuse, but they are relatively
small risks compared to the frenzy of claims out there.
* There's recent threads on the notion that el cheapo implementation can
lead to security holes, where RFID is no exception to that risk, such as
susceptibility to malware.
* Spread of the RFID Zapper into society and its effects will become
problem area # 3.
------------------------------
Date: Wed, 26 Apr 2006 10:56:31 +0200
From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
Subject: Personal Electronic Devices on Commercial Aircraft
There has been plenty of discussion of the risks of operating personal
electronic devices (PEDs) such as mobile telephones, gameboys and computers
on board commercial transport aircraft. In the U.S., the use of mobile
telephones on board flying aircraft is forbidden by the Federal
Communications Commission, inter alia because such a phone would be within
receiving range of many cells simultaneously and the technology is neither
designed nor implemented to accommodate such cases. However, there is also
the possibility of interference with the aircraft avionics.
The subject was already brought to the attention of the RISKS community by
Martin Howard in 1994 (RISKS-16.23), who quoted extensively from the monthly
bulletin Callback for May 1994, published by NASA's Aviation Safety
Reporting System (ASRS), an anonymised no-fault incident reporting system
for aviation. Lars-Henrick Eriksson relayed an incident reported by the
Swedish CAA in RISKS-16.24. I have synopses of ASRS reports on the
phenomenon from the late 1990's, as well as personal reports from
commercial-pilot colleagues. I wrote a short article "Electromagnetic
Interference with Aircraft Systems: why worry?", report RVS-J-97-03 in 1997,
summarising much of this evidence and there was an article by Alfred
Helfrick on the subject in Avionics News Magazine in September 1996. Both
articles are available under the rubric "Do Passenger Electronics Interfere
With Aircraft Systems?" in the compendium on Computer-Related Incidents with
Commercial Aircraft (CRICA) on my group's WWW site www.rvs.uni-bielefeld.de
It is not a new issue.
More recently, the BBC reported on mobile phones and aircraft:
http://www.bbc.co.uk/dna/h2g2/A6821318
The article is helpful, but refers only vaguely to incident compilations,
and doesn't provide any literature citations. It relates one incident in
which a small commercial aircraft with seven passengers on board departed
below the glideslope on an ILS approach into an airport in New Zealand in
February 1993 and crashed. Despite being below the glideslope, the
navigation instruments were indicating a descent, according to the article
(that must mean that they were indicating that the aircraft was above the
glideslope, even though it was in fact well below it). The pilot was calling
on a mobile phone before the glide slope signal was acquired, and the call
ceased when the aircraft crashed. There is no direct proof of interference
but no other explanation for the incorrect nav indications has been offered.
Phones transmit whenever they are turned on, whether they are being used for
a call or not. It is notoriously difficult to assess the strength or
structure of enclosed electromagnetic fields, such as those formed by a
transmitter in a more-or-less Faraday cage, and all the electrical wiring of
the aircraft is contained within the cage. The U.K. CAA conducted some of
the first studies on EM fields generated within aircraft by cell phones,
reported in 2003 in CAA Paper 2003/3, available from
http://www.caa.co.uk/docs/33/CAPAP2003_03.PDF A more recent report on PEDs
and avionics from November 2005 is available at
http://www.caa.co.uk/docs/33/CAP756.PDF This report references seven other
documents from the CAA, JAA, RTCA, EUROCAE and a private body on EM
interference from PEDs on board aircraft.
NASA wrote a technical memorandum TM-2004-213001 in 2004, "Evaluation of a
Mobile Phone for Aircraft GPS Interference", available at
http://library-dspace.larc.nasa.gov/dspace/jsp/bitstream/2002/11768/1/NASA-2004-tm213001.pdf
Recently, Bill Strauss, Jay Apt, M. Granger Morgan and Daniel D. Stancil
have written an article on the subject for IEEE Spectrum, March 2006,
entitled "Unsafe at any airspeed?", available at
http://www.spectrum.ieee.org/mar06/3069/1 as well as a Viewpoint for
Aviation Week and Space Technology, April 10, 2006 (p.58). The authors are
with the Naval Air Warfare Center (Strauss) and CMU. They conducted a study
on passenger awareness of the issues, which showed that "passengers are not
aware of the reasons for the limitations on inflight PED use. Many doubt
that safety is an issue." They recommend expanding industry/government and
inter-agency cooperation on the issue; augmenting the ASRS; characterising
the in-flight radio-frequency environment more carefully; deploying simple
real-time tools that will help pilots detect RF emissions; and clearly
communicating the problems and dangers of PEDs to aircraft passengers. They
conclude "our study has convinced us that use of personal electronics in
flight should continue to be limited and that no one should be allowed to
operate intentionally radiating devices during critical phases of flight."
As many of us said a decade ago (see my op.cit.) In the meantime, the
problem appears to have worsened thanks to the proliferation of PEDs, in
particular intentional transmitters such as mobile phones, and the casual
attitude most people seem to have towards their use. Thank goodness that
colleagues are staying on the case.
Peter B. Ladkin, Causalis Limited and University of Bielefeld
www.causalis.com www.rvs.uni-bielefeld.de
------------------------------
Date: Thu, 20 Apr 2006 10:43:21 -0400
From: "Colin Brayton" <cbrayton@private>
Subject: PDF Hell for SA Bank
Banks are warning clients who receive Internet "proof of payment" forms from
First National Bank clients to physically check whether a deposit has been
made, because a glitch in FNB's online banking software allows these forms
to be altered by account holders.
And the bank doesn't know how long it will take to sort out the problem.
It has seemingly occurred because FNB opted for a printable document file
(pdf) format for its downloadable "proof of payment" forms. These can be
imported into Adobe Acrobat and the contents manipulated before being sent
on to the recipient of the Internet transfer.
IOL<http://www.iol.co.za/index.php?set_id=3D1&click_id=3D13&art_id=vn20060417024758107C243105>
What do folks know about securing PDF documents? I know that encrypted and
password-protected PDFs are fairly easily cracked ... In a related story,
the U.S. Labor Dept. has an RFP out looking to convert XML to PDF.
Colin Brayton, Bklyn, NY http://blogalization.nu/marketmachines
http://del.icio.us/marketmachine/news cbrayton@private
------------------------------
Date: Tue, 25 Apr 2006 13:45:03 -0400
From: Dawn Cohen <dawn.cohen@private>
Subject: Honeypot Cars
Interesting use of honeypots in the real world: "bait cars" -- Reported on
at http://www.yahoo.com/s/297977 (which links to what I believe is a CNN
report).
These are cars left out by police departments in car-theft prone areas, in
hopes of catching car thieves. Cars include hidden video cameras to observe
the thieves, GPS to track them, and a mechanism to lock the doors so that
the thief cannot exit, until released by a cop (who will presumably arrest
them). I'd have to worry about that last feature -- seems like a safety
hazard, and may involve people besides the thief.
One major difference strikes me between this type of honeypot and the
network honeypot: the attacker (thief) actually gets arrested for attacking
the honeypot (stealing the car). The purpose of a network honeypot is to
secure the real servers by identifying attackers/attacks. But presumably no
one thinks of prosecuting an attacker who was not also caught attempting to
attack a real server. Or do they?
------------------------------
Date: Tue, 18 Apr 2006 16:05:07 -0300
Sender: IEEE Security & Privacy Magazine Task Force <ieee-sp@private>
From: Ivan Arce <ivan.arce@private>
Subject: CfP: IEEE S&P special issue on malware
[Below is the Call for Papers for the IEEE S&P special issue on malware;
spyware, botnets, rootkits and other various forms of malware. The goal
is to have the final printer-ready versions of the selected papers by 4
Aug. Ivan]
Special issue of IEEE Security & Privacy magazine
Botnets, spyware, rootkits and assorted malware, September/October 2006
Deadline for submissions: May 31st, 2006
Guest editor: Ivan Arce (ivan.arce-AT-coresecurity.com)
The continuing evolution of security threats and countermeasures
increasingly points at spyware, rootkits, botnets and a myriad of other
software artifacts - loosely defined as "malware"- as the biggest challenge
to achieve socially acceptable levels of security and privacy in today's IT
environments.
The number of reported incidents and criminal activities attributed to
malware is believed to be growing steadily every year clearly signaling a
topic that merits more focused attention and in-depth analysis from the
information security community.
Consequently, the technological, legal and policy-related aspects of malware
are the topic of an upcoming special issue of IEEE Security & Privacy
magazine.
We are looking for feature articles with in-depth coverage of spyware,
botnets, rootkits and other related malware exploring the following ideas:
* Malware detection, categorization and analysis
* Reverse engineering and static/dynamic binary analysis of spyware,
rootkits and other malware.
* Malware containment and removal.
* Advances in offensive and defensive malware technology
* The global and large scale trends in malware
* Malware economics and metrics
* In-depth research and case-studies of specific rootkits, spyware or
botnet systems.
* Malware-specific computer forensics and incident response
* Malware-specific legal, regulatory and policy considerations
The above list is not complete nor closed, authors are encouraged to
submit articles that explore other aspects of malware.
Submissions are due May 31st, 2006 and will be subject to the peer-review
methodology for refereed papers of the IEEE Security & Privacy
magazine. Submissions will be accepted using the IEEE Computer Society
Manuscript Central site at http://cs-ieee.manuscriptcentral.com
Articles should be understandable to a broad audience of people interested
in computing in science and engineering. The writing should be down to
earth, practical, and original. Authors should avoid theory, mathematics,
jargon, and abstract concepts. They should not assume that the audience will
have specialized experience in a particular subfield. appearance.
Feature articles normally run from 4 to 12 magazine pages, including all
text, the abstract, keywords, biographies, illustrations, sidebars, table
text, and reference entries. Articles should be between 4,500 to 7,000 words
(tables and figures count as 250 words each)
For more information see: http://www.computer.org/mc/security/author.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]
<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.26
************************
This archive was generated by hypermail 2.1.3 : Thu Apr 27 2006 - 12:07:52 PDT