[RISKS] Risks Digest 25.33

From: RISKS List Owner <risko_at_private>
Date: Mon, 15 Sep 2008 10:45:25 PDT
RISKS-LIST: Risks-Forum Digest  Monday 15 September 2008  Volume 25 : Issue 33

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.33.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Antivirus software in critical systems? (Rob Diamond, Robert P Schaefer, PGN)
Re: States throw out costly electronic voting machines (Patrick J Kobly)
Re: FAA redundancy -- or lack thereof (Mike Martin)
Misleading headline: 'Big bang' experiment is hacked (Gabe Goldberg)
Change name, get off no-fly list (David Magda)
Re: Amos Shapir on Airport Photo ID Checks (Danny Lawrence)
iPhone Takes Screenshots of Everything You Do (Brian X. Chen via Monty Solomon)
Re: UAL, Automated trading gets spoofed! (Howard Israel)
San Francisco officials looking for hidden network device (Gabe Goldberg)
PayPal phishes their own customers (Andrew Pam)
Re: Risks of better security ... (Chris Adams, Ron Garret on David Bliss)
Re: Control-Z vs. Bourne-Again SHell (Philippe Pouliquen)
Re: Weird Clock Issue -- a single bit error (David Magda)
Re: Risks of GPS Devices ... (Sergei Patchkovski)
Re: Automated Bill Payments Are a Cinch: Not So Fast (CBFalconer,
  Sten Carlsen, Erling Kristiansen)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Mon, 15 Sep 2008 23:14:28 +1000
From: Rob Diamond <robd_at_private>
Subject: Antivirus software in critical systems? (Re: jared, RISKS-25.29)

I've worked in real-time (SCADA) software and related areas for years.  More
and more vendors are using Windoze, for the client UI machines and often for
the servers as well (when *will* they learn ?).  Last year I saw a Denial of
Service attack on some client machines by the anti-virus and configuration
management/license checking software. The user might be in the middle of
dispatching a tech. to a job when the anti-virus software would start up --
the client machine would (almost completely) freeze for several minutes,
until the anti-virus or conf. management software had finished running.
It's incredible that the anti-virus software vendors have no idea about
co-operative multi-tasking -- their software grabs the disk by the short
hairs and gets its almost undivided attention until it's finished -- while
the shortcomings of the OS task and I/O scheduler are pretty obvious.

Even funnier (you have to laugh or you'd cry) was the initial attitude of
the IT outsourcer -- "What's the problem ?  *Our* job is to protect the
machines we supply from viruses and manage the software configuration and OS
updates -- and that's what we're doing. If the machines are a bit busy for a
while that's the user's problem. Or buy a more powerful machine."
Eventually the problem was reduced, but not completely eliminated, by
reducing run frequency and cutting back on the checks carried out.

Since this was a public utility with over a million customers the risks of
not being able to dispatch a (possibly safety-critical) job while anti-virus
software runs are pretty obvious.

Rob D. <robd_at_private>  +61-412-607-361

------------------------------

Date: Mon, 15 Sep 2008 11:07:07 -0400
From: "Schaefer, Robert P  \(US SSA\)" <robert.p.schaefer_at_private>
Subject: Antivirus software in critical systems? (Re: jared/pgn, R-25.29)

Virus installation is not needed for the use of the application, but it is
needed for the development of the application.

What may be going on is the way systems are developed today which perhaps
was not so true 10 years ago.  Many critical systems and embedded systems
are Windows based, you can get Windows on a single card computer, or an
industrial PC, etc. The principal driver is familiarity and cost.  For
software development, the critical system is connected to the corporate LAN
and the Internet, for many reasons, particularly file sharing, corporate
configuration management.  Access to the Internet allows access to vendor's
device drivers, documentation and to register third party code.  You can
even test the system on the LAN from your corporate desktop, once you've
walked over to the lab to flip the power-on switch.  (All sorts of risks
internal to the corporation here with visible IP addresses providing access
to embedded and shared devices.)

Corporate policy for responsible corporations is, if your computer is on the
LAN or the Internet, then Virus protection must be installed, no ifs, ands,
or buts.  The sneaker-net still exists where LAN access is not available for
embedded systems in the corporate world, but today the memory device is the
thumb-drive and no longer the floppy disk.

------------------------------

Mon, 15 Sep 2008 8:26:34 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Antivirus software in critical systems? (Re: Schaefer, R-25.33)

There is usually a huge gap between theory and practice.  It clearly
dominates this discussion.

In principle, voting systems and other critical systems should not be
developed on untrustworthy operating systems with unreliable development
tools and flawed software engineering.

Even more important, election systems should not have to rely on easily
compromisible operating systems -- especially when there is essentially no
accountability, poor configuration control, poor documentation, and perhaps
even some Internet access for distributing results or even for voting, as
well as unaudited devices for special user needs or for real-time
operational maintenance.

Anyone with access to such an OS can completely compromise elections -- in
the development process, in configuration and set-up, and in execution.
More than anything else, we need trustworthy operating systems and
trustworthy application software with thorough accountability.  But that
is still nowhere near enough, considering all of the extrinsic problems
in registration, voter authentication, and so on.

Similar concepts should apply to critical infrastructure systems -- many of
which somewhat surprisingly have live direct or indirect Internet
connections.  By contrast, consider gambling systems -- which are held to an
enormously higher standard.

Antivirus software should be unnecessary by construction of those systems.
HOWEVER, in practice, Robert implies, well, that's impossible because that's
just the way it is.  That is a terrible state of affairs.

------------------------------

Date: Thu, 11 Sep 2008 20:02:35 -0600
From: Patrick J Kobly <patrick_at_private>
Subject: Re: States throw out costly electronic voting machines (RISKS-25.30)

One of the frustrating things about this discussion has always been how few
people who comment on the subject are actually aware of the history.

I would suggest that anybody who thinks that open source will be able to
provide the solution to the disaster that is eVoting read about why Jason
Kitcat shut down the GNU.FREE (Free Referenda & Elections Electronically)
project in 2002.

http://www.free-project.org/files/free_software_odyssey.pdf

As an aside, the suggestion that jurisdictions ought to provide existing
equipment to researchers is a non-starter.  Contractual (and legislative)
restrictions on the jurisdictions exclude them from providing access to this
equipment.

Patrick Kobly, 56 388 Sandarac Dr NW, Calgary, Alberta T3K 4E3
http://www.kobly.com 1-403-274-9033

  [The contractual restrictions may get changed sooner than you think,
  at least in certain states.  PGN]

------------------------------

Date: Sun, 14 Sep 2008 09:35:11 +1000
From: "mike martin" <mke.martn_at_private>
Subject: Re: FAA redundancy -- or lack thereof (PGN, RISKS-25.31)

The outage on 26 August in the FAA Flight Planning System was more likely
due to a design deficiency than, as reports claimed, lack of capacity or
redundancy.

I struck a similar issue some years ago with a real-time system that drove a
large number of NCR automatic teller machines. The machines were capable of
processing withdrawal transactions while off-line to the central computer, a
measure intended to provide a degree of customer service in the event of
central computer or communication link failure.

As first implemented, if the central computer went down for any length of
time it was virtually impossible to bring it back up again. Every time we
tried it would collapse under the onslaught of accumulated off-line
transactions in the ATMs that were waiting to be posted.

The subsequent report from Gabe Goldberg suggests that something similar
happened with the FAA system. He quotes FAA spokesman Paul Takemoto:

"Basically, all the flight plans that were in the system were kicked out,"
Takemoto said... The system switched to the FAA's backup flight planning
computer in Salt Lake City, which was quickly overwhelmed by airlines trying
in vain to enter flight plans. "They just kept hitting the 'Enter' button.
So the queues immediately became huge," Takemoto said. "On top of that, it
happened right during a peak time as traffic was building. Salt Lake City
just couldn't keep up." The Georgia computer was fixed in two-and-a-half
hours but it wasn't until the FAA asked airlines to stop filing flight plans
that the backlogs started to clear.

Yes, you _could_ build in sufficient capacity and redundancy to handle the
anomalous peak. Or you could do what we did with the ATM system, and
sequence the start-up so that communication links were brought online
progressively, presenting a load that remained within maximum processing
capacity.

Presumably the next generation flight planning system will be design to
fail-over seamlessly, thus avoiding an accumulation of backlog transactions.
Then this problem will never happen again -- until it does.

------------------------------

Date: Mon, 15 Sep 2008 11:25:53 -0400
From: Gabe Goldberg <gabe_at_private>
Subject: Misleading headline: 'Big bang' experiment is hacked

After hackers inserted a message onto the CERN website, a spokesman for CERN
(which houses the Large Hadron Collider, LHC) said that "The computer is
used to monitor one of the experiments at the LHC, it's nothing to do with
the LHC accelerator itself or any of the control systems."
  http://news.bbc.co.uk/2/hi/technology/7616622.stm

So the collider wasn't hacked. But was the Web site hacked or was an
experiment control system hacked?  Unless they're experimenting with Web
servers, those are different...

  [Well, the monitoring system is only a Collide-O-Scope, so perhaps what
  you see is only an apparition anyway?]

------------------------------

Date: Fri, 12 Sep 2008 09:19:48 -0400
From: David Magda <dmagda_at_private>
Subject: Change name, get off no-fly list

And this illustrates just how completely useless no-fly lists are:

  The U.S. Department of Homeland Security wrote a letter to Labbé in 2004,
  saying he had been placed on their watch list after falling victim to
  identity theft. At the time, the department said there was no way for his
  name to be removed.

  Although Labbé wrote letters to the U.S. department, his efforts were in
  vain, prompting him to legally change his name.  "So now, my official
  name is François Mario Labbé," he said.

  "Then you have to change everything: driver's license, social insurance,
  medicare, credit card--everything."

  Although it's not a big change from Mario Labbé, he said it's been enough
  to foil the U.S. customs computers.

http://www.cbc.ca/canada/montreal/story/2008/09/11/nofly-name.html
http://www.boingboing.net/2008/09/12/canadian-man-changes.html

------------------------------

Date: Mon, 15 Sep 2008 10:08:26 -0400
From: "Danny Lawrence" <dantemann_at_private>
Subject: Re: Amos Shapir on Airport Photo ID Checks (RISKS-25.32)

> The newly formed U.S. TSA has a serious problem: they have to supply
> Security, but they have no idea how (and it seems that they are unaware
> that nobody else does, either).  But they do know that Security causes
> Harassment, and they do know how to do Harassment.  So the obvious logic
> is, the more Harassment they'd do, the more Security will be produced. QED

Another problem is the blind reliance on "The Rules" without understanding
why "The Rules" are there and what they are supposed to prevent.  Case in
point, a woman with pierced nipples tries to board a plane, and sets off the
metal detector.  The TSA screeners insist that she must pass through the
metal detector without setting it off, instead of noting the nipple rings
and realizing that they aren't a threat.

Admittedly in this case the TSA admitted that its "procedures were faulty",
but didn't seem to think that the screeners did any thing wrong.

http://cbs2.com/local/nipples.piercings.rings.2.686169.html

  [The rules can also be questioned, For example, confiscating a toothpaste
  tube that is 90% empty because the label says 5 ounces seems rather silly.
  But I suppose rules of that kind are intended to prevent screeners from
  using any intelligence.  PGN]

------------------------------

Date: Sat, 13 Sep 2008 22:03:37 -0400
From: Monty Solomon <monty_at_private>
Subject: iPhone Takes Screenshots of Everything You Do (Brian X. Chen)

iPhone Takes Screenshots of Everything You Do
By Brian X. Chen September 11, 2008 | 1:26:34 PM

Your iPhone is watching you.

If you've got an iPhone, pretty much everything you have done on your
handset has been temporarily stored as a screenshot that hackers or
forensics experts could eventually recover, according to a renowned
iPhone hacker who exposed the security flaw in a webcast Thursday. ...

http://blog.wired.com/gadgets/2008/09/hacker-says-sec.html

------------------------------

Date: Mon, 15 Sep 2008 10:47:15 -0400
From: Howard Israel
Subject: Re: UAL, Automated trading gets spoofed! (Re: RISKS-25.32)

"As Tribune Co. and Google Inc. pointed fingers at each other over the
glitch that cratered UAL's stock [on 8 Sep 2008,] blame spread to the
computers that robotically troll the Web for news stories and execute stock
trades automatically."  [Source: Shira Ovide and Jessica E. Vascellaro, UAL
Story Blame Is Placed on Computer, *The Wall Street Journal*, 10 Sep 2008;
PGN-ed]
http://online.wsj.com/article/SB122100794359017593.html?mod=3Dhpp_us_whats_news

------------------------------

Date: Fri, 12 Sep 2008 15:09:45 -0400
From: Gabe Goldberg <gabe_at_private>
Subject: San Francisco officials looking for hidden network device

As Deep Throat (Woodstein's, not the movie star) almost said,
"Follow the packets..."

San Francisco officials are trying to find a device on the city's computer
network that was allegedly left there by an IT worker who was jailed for
refusing to divulge passwords to the city network, the IDG News Service
reported on Thursday.

San Francisco network administrator Terry Childs was arrested in July on
four felony charges of taking control of the city's computer network and
locking administrators out. He remains in jail on $5 million bail despite
giving up the passwords to the mayor in a secret jail cell meeting a week
later.

The device, which appears to be a router providing remote access to the
city's fiber Wide Area Network, was discovered on August 28, the report
says.

However, officials didn't know where the device was located and didn't have
the user name and password to access it. When they tried to log in, a
message was displayed that said the system was the "personal property of
Terry S. Childs," according to a screenshot officials filed with the court.

http://news.cnet.com/8301-1009_3-10039650-83.html

  [Earlier items on this case in RISKS-25.24-25).  PGN]

------------------------------

Date: Mon, 15 Sep 2008 12:25:35 +0930
From: Andrew Pam <xanni_at_private>
Subject: PayPal phishes their own customers

... Your monthly account statement is available anytime; just log in to your
account at https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HISTORY. To
correct any errors, please contact us through our Help Centre at
https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HELP.

The error.com domain does not belong to PayPal.

Andrew Pam  Serious Cybernetics  http://www.sericyb.com.au/

------------------------------

Date: Thu, 11 Sep 2008 19:21:39 -0400
From: Chris Adams <chris_at_private>
Subject: Re: Risks of better security ... (Garret, RISKS-25.32)

> The fact that the process started on an insecure page and ended on a
> secure one didn't seem relevant.

I'm a bit surprised that this is considered risks-worthy: this is how web
security should work. It allowed a legitimate user access to a network
resource without distracting away from the actual task they wanted to
perform. It didn't provide a password which had not previously been sent to
the remote server, would not have blindly continued had the x509 checks not
passed, etc.

The drawback appears to be that Ron's Keychain didn't have one of the extra
confirmation options enabled. Password managers have various permutations on
this theme but with the exception of locking when the system is suspended to
disk they're largely false security: if someone untrusted gets physical
access to your computer they might not be able to login to etrade
immediately but they can still trivially install malware, a physical
keyboard sniffer, etc.

Usability is a security feature and I think this is the right balance: more
prompts would lead many users to either disable them entirely or blindly hit
okay, even when they get the one legitimate warning in the flood of
false-positives. The major security improvement I'd make would be adding a
password generator into the browser to make the use of site-specific
passwords even easier.

------------------------------

Date: Thu, 11 Sep 2008 14:57:49 -0700
From: Ron Garret <ron_at_private>
Subject: Re: Risks of better security ... (Garret, RISKS-25.32)

[In response to a message from David Bliss <david_at_private>, interstitiated
here to simplify reading.  PGN]

>> I find myself at a loss to suggest how this particular risk might have
>> been avoided.

> Really?  How about "prohibit the provision of features to 'remember'
> passwords, the entire point of which being to verify the identity of
> *people*, not *software*"?

Prohibit?  How?

> Or at the very least refuse to use such features.  I do.

This "feature" is enabled by default on OS X.  I was not aware of its
existence until this incident.  As soon as I figured out what had happened I
disabled it (which was in itself a non-trivial exercise).

> I don't think the web designers are the ones guilty of idiocy.

Indeed not.  I never meant to imply that they were.

> (yes, yes, I know you thought you understood how that "feature" worked and
> thought it would prompt you for a different password before helping
> itself.  Surely someone of your experience should know better than to have
> any faith in any software, ever?)

Please read:
  http://cm.bell-labs.com/who/ken/trust.html
and then explain to me how you propose to get along in today's world without
some faith in some software sometimes.

------------------------------

Date: Fri, 12 Sep 2008 08:44:56 -0400 (EDT)
From: Philippe Pouliquen <philippe_at_private>
Subject: Re: Control-Z vs. Bourne-Again SHell (jidanni/chau, RISKS-25.31-32)

jidanni_at_private wrote that
  $ sleep 55; launch_rocket
causes the "launch_rocket" application to run immediately if Ctrl-C is used
during the sleep period, and that replacing the ";" with "&&" cures the
problem.

However, David Chau replied that the "&&" has its own problem with respect
to stopping the sleep command (if the intent is to temporarily halt the
count-down sequence).

It seems to me that this problem can be solved by putting the two commands
into a shell script, so that the Ctrl-C or the Ctrl-Z applies to the script
as a whole, not the individual commands.

This can also be performed on the command-line with:

$ ( sleep 55 ; launch_rocket )

The caveat is that I only tested this on a FreeBSD and on a Linux system,
and that job-control may be somewhat operating-system dependent...

To go a little further, I use the following script for playing music (I have
stripped out the code comments in the interest of brevity):

   for song in *.mp3
   do
     /usr/local/bin/mpg123 "${song}" &
     trap "kill $! ; sleep 1" SIGQUIT
     wait
   done

With the above code, Ctrl-C stops playback completely, Ctrl-Z pauses
playback (fg resumes) and Ctrl-\ (SIGQUIT on FreeBSD) skips to the next
song.  Note that the "sleep 1" after the kill is a hack to allow the sound
card buffer to drain, otherwise the next mpg123 may abort if the sound
resources appear to be already in use.

  [Similar comment noted by Michael Loftis.  PGN]

------------------------------

Date: Sat, 13 Sep 2008 11:40:19 -0400
From: David Magda <dmagda_at_private>
Subject: Re: Weird Clock Issue -- a single bit error (Greenwald, RISKS-25.32)

> I have a battery operated clock that syncs via radio signal reception with
> the atomic clock in Boulder ...  It currently shows the correct time (as
> of writing: 9:05 PM EDT) but shows the date as Saturday September 27th
> 2008 instead of the correct date of Monday August 18, 2008!

If you want to know the time, use a clock:
  http://www.radiocontrolledclock.com/radconwalclo1.html

If you want to the know the date, use a calendar:
  http://www.calendars.com/

Which day it is only changes once a day, so you only have to check in the
morning and not have to worry about it changing until midnight. :) Ditto for
day of the week.

  [Well, a caveat is needed.  The date changes somewhere on the planet every
  hour (and in some places on the half-hour).  PGN]

------------------------------

Date: Fri, 12 Sep 2008 17:24:03 +0000
From: "Sergei Patchkovski" <serguei.patchkovskii_at_private>
Subject: Re: Risks of GPS Devices ... (Brader, RISKS-25.32)

>   When you are directed to press a key, you should press and quickly
>   release the key.  (You may need to [hold it] down for a period of time
>   to start a secondary function, when the instructions tell you to do so.)
      [Bracketed PGN correction to simplify the discussion.]

Given the right circumstances, this may be the right design choice to make,
odd as it sounds. A similar approach is often taken on wrist-mounted dive
computers -- a short press of a button would activate a more common function
-- such as switching between the current and maximum depth display, or
advancing to the next page of the dive log. A two-second sustained push
would activate a less common function -- such as setting the oxygen content
or the surface altitude.

The rationale is simple -- making an externally-protruding push button
waterproof is not easy, especially if they have to operate at a few bar
external pressure in a salt-water environment. Having too many of those
buttons may significantly increase the chances the device will leak and ruin
your dive (or worse).

------------------------------

Date: Thu, 11 Sep 2008 20:36:24 -0400
From: CBFalconer <cbfalconer_at_private>
Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

I have a simpler, and, I believe, safer system.  My bank (and others) allow
you to set up delayed payments from your account, or regular at stated
intervals.  These create checks from me to an organization, identified with
my account number, etc.  This handles everything without any fuss, except
the telephone, which doesn't allow you to set up a constant monthly payment.
The other outlays go on one of two credit cards.  So, each month, I only
need to set payments to the credit cards and the phone co.  I pay the credit
cards off entirely, so they don't have any interest involved.

------------------------------

Date: Sat, 13 Sep 2008 13:40:26 +0200
From: Sten Carlsen <sten_at_s-carlsen.dk>
Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

In Denmark the normal function of this system is different:

After the setup of this agreement:

Every month the bank will send you (paper or electronic form) a list of
payments that have been reported by those covered by the agreement and will
be due during the next month.

When this is received you have about 10 days to protest any payment to the
bank; if you do, the payment will not be made and you have to settle the
matter with the other party by other means.

In my case the agreement with the bank is such that if the bank makes an
error, the bank will pay to correct it, if I make the error, I have to take
the consequences. Seems reasonable to me.

Example: you have an account with your hairdresser (usually not big
amounts), one month he has reported to your bank that he wants 20,000.00$
from you. If you sleep and do not read your statement, he will be paid; if
you notice that this is wrong and ask the bank to stop the payment, he is
not paid but you will have to go down there and ask him what ... he is
thinking.

This is a simplified version, there are of course more details to it than
this but this is how it works. This has been available from before online
banking was even possible in roughly the same shape.

The risks of this are not so big specially compared with who takes the
penalty if errors occur. We very rarely hear that this goes wrong.

------------------------------

Date: Sat, 13 Sep 2008 19:18:10 +0200
From: Erling Kristiansen <erling.kristiansen_at_private>
Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

An automatic payment scheme like the one described has been in operation in
The Netherlands for many year, to almost everybody's satisfaction.  There
was some reluctance in the beginning, but it subsided rather quickly.

I think the key to success is that you have one month to ask your bank to
undo the transaction, no questions asked. You need not give a reason, you
need not prove that anybody made a mistake.  You may, of course, have to
fight it out later with the company that charged you, if they think you owe
them money.  You can file the cancel request through on-line banking, or go
to your bank branch.

I barely hear about any mishaps or incidents with the scheme. If people know
that transactions can be reversed, the incentive for wrong-doing is greatly
reduced.

An additional advantage is that you avoid the mistakes you might make if you
do the transfer yourself. I recently typed the wrong account number on a
rather large transfer. The bank said they could not reverse the transaction,
and I had to rely on the good will of the erroneous recipient. To my great
relief, he returned the money promptly.

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_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_at_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_at_private or risks-unsubscribe_at_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_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_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.33
************************
Received on Mon Sep 15 2008 - 10:45:25 PDT

This archive was generated by hypermail 2.2.0 : Mon Sep 15 2008 - 11:11:46 PDT