RISKS-LIST: Risks-Forum Digest Tuesday 2 August 2005 Volume 23 : Issue 96
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/23.96.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
20th Anniversary of RISKS! (PGN)
Bogus EAS Alerts in Florida, Nevada (Kevin Poulsen)
Electronic voting -- oops (Richard Schroeppel)
Timezones and appointments (Nick Rothwell)
Re: Partisan e-mail censorship as spam filtering (Craig A. Finseth)
Re: Embedded Systems vs Us (Michael Kohne, Jay R. Ashworth)
Re: Too many features in medical device (Russell N. Sheptak)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 1 Aug 2005 15:37:27 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: 20th Anniversary of RISKS!
Somehow it escaped my attention when I put out RISKS-23.95 a few minutes
ago, that it was exactly the 20th anniversary of the day on which I had put
out RISKS-1.01, on 1 Aug 1985 -- using a primitive line-by-line editor on a
huge (not-so-)Silent 700 with an acoustic coupler over a very slow
cross-country phone line. Since then, the various technologies have of
course increased dramatically. Unfortunately, the risks have also -- in
that the same kinds of problems still recur with respect to safety,
reliability, security, survivability, interoperability, human culpability,
and so on, seemingly ad infinitum, combined with the reality that so many
more people are now dependent upon computers and their interconnectivity.
I imagine that I won't keep it up for *another* 20 years (for example, I
observe that my ratio of puns seems to have declined), but hopefully one (or
some) of you will want to continue the tradition when the time comes. It
would be a real shame to let the Risks Forum disappear. Even though the
same or similar problems keep recurring, there is an important message
herein -- and just another reminder of the needs for constant vigilance,
increased awareness, better education, and -- above all -- BETTER SYSTEMS.
Cheers to all! PGN
------------------------------
Date: Mon, 1 Aug 2005 16:45:50 -0700
From: "Kevin Poulsen" <klp@private>
Subject: Bogus EAS Alerts in Florida, Nevada
Two regional false alarms over the Emergency Alert System last week: one
apparently a hardware glitch, another a user error that resulted in the
National Weather Service rethinking the interface to their alert-issuing
software. [EASy does it? PGN]
http://www.wired.com/news/technology/0,1282,68363,00.html
Bogus Homeland Alerts Hit the Air, Wired.com, 1 Aug 2005
By Kevin Poulsen </news/feedback/mail/1,2330,0-1323-68363,00.html>
As if Florida didn't have enough to worry about this hurricane season, some
residents of the Sunshine State were alerted to a nonexistent radiological
emergency last Wednesday after a National Weather Service operator
fat-fingered a routine test of the Emergency Alert System.
The EAS, a 1997 replacement for the Cold War-era Emergency Broadcast System,
transmits emergency audio and text information to the public over
weather-alert radios and by interrupting commercial television and radio
broadcasts.
A digital header at the top of every EAS alert dictates how long it's in
effect and how far the message should be propagated. It also identifies the
type of event by a three-letter code.
The Florida gaffe occurred when an operator at the National Weather
Service's Tallahassee forecast office inadvertently entered the code "RHW"
instead of "RWT," keying a radiological hazard warning instead of a required
weekly test.
The warning was broadcast to the Florida panhandle and parts of southern
Georgia, said National Weather Service warning-coordination meteorologist
Walt Zaleski. Fortunately, it failed to cause panic, in part because the
audio accompanying the message still identified it as "only a test," and the
office moved rapidly to quash the false alarm.
"They quickly alerted every radio and television station within their
viewing and listening area that the ID had gone out incorrectly and there
was no emergency to speak of," said Zaleski.
A similar glitch at a Las Vegas radio station a day earlier falsely alerted
cable companies, radio and TV stations in five counties to a national crisis
that didn't exist.
That error occurred Tuesday afternoon when KXTE-FM tried to send out a
message canceling an earlier Amber Alert, and instead transmitted an EAN, or
emergency action notification -- a special code reserved for the president
of the United States to use in the event of a nuclear war or similar extreme
national emergency.
KXTE ("X-treme Radio"), which didn't return phone calls about the incident,
serves as the local primary feed for southern Nevada and parts of
California, which means broadcasters in that region are tuned to the station
24 hours a day to pick up and propagate EAS messages.
Under FCC regulations, those broadcasters must interrupt their regular
programming when they receive an EAN code. But anomalies in the header, the
absence of accompanying audio and the fact that there has never been a
genuine national activation caused stations to question Tuesday's message,
said Nevada EAS chair Adrienne Abbott. "A lot of stations caught it and did
not forward it out," Abbott said.
The error apparently resulted from a hardware problem in the station's EAS
encoder-decoder. "We think that the internal battery had failed, the
programming had scrambled itself," said Abbott.
The FCC is in the midst of a comprehensive review of the EAS network, with
an eye to updating the system for the internet age. But experts say the
public has already developed some immunity to bogus warnings. "Research
into the behavior of warning recipients suggests that a single false alarm,
without corroboration from other credible sources, generally elicits only
limited reaction from the public," a report from the nonprofit Partnership
for Public Warning noted last year.
Carolyn Levering, plans and operations coordinator for the Office of
Emergency Management in Clark County, Nevada, says equipment failure is a
fact of life in a system as complex as the EAS. "There wasn't a lot that
could have been done to avoid it," Levering said.
But the human error behind Florida's false alarm is more easily dealt
with. The National Weather Service said last week that as a result of the
Tallahassee incident, it's adding a confirmation process to its alerting
software nationwide that should make issuing a serious alert at least as
difficult as deleting a folder from a Windows desktop.
"Now when the operator calls up on their computer screen what particular
three-letter ID they'd like to send, another window will pop up and say, 'Do
you really want to issue this radiological hazard warning?'" said Zaleski.
More stories </news/storylist/0,2339,1323,00.html> written by Kevin Poulsen
------------------------------
Date: Tue, 2 Aug 2005 14:15:42 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Car computer systems at risk to viruses
Car industry officials and analysts say hackers' growing interest in writing
viruses for wireless devices puts auto computer systems at risk of
infection. As carmakers adjust on-board computers to allow consumers to
transfer information with MP3 players and mobile phones, they also make
their vehicles vulnerable to mobile viruses that jump between devices via
the Bluetooth technology that connects them. [Source: Reuters, 1 Aug 2005,
thanks to Lauren Weinstein; PGN-ed]
http://www.cnn.com/2005/TECH/08/01/viruses.cars.reut/index.html
------------------------------
Date: 02 Aug 2005 02:14:16 -0700
From: Geoff Kuenning <geoff@private>
Subject: (Not) Combating Identity Theft with "Smart" Social Security Cards
I just received an e-mail from my Congressman, David Dreier, touting his
efforts to put RFID chips in Social Security cards. Dreier, never noted for
clear thinking, writes:
There is a common sense solution to thwarting identity theft and the
fraudulent use of Social Security cards: the cards must be made
counterfeit-proof... H.R. 98...improves the integrity of the Social
Security card by adding a digitized photo of the cardholder. These Smart
Cards will also contain a unique electronic encryption code that will
allow employers to verify each applicant's work eligibility prior to
hiring. Smart Cards will decrease Social Security information theft and
prevent illegal immigrants from using fake or stolen Social Security
information to get a job.
Note that HR 98 doesn't do anything to actually address identity theft,
which isn't performed using Social Security cards in the first place.
Sensible measures, like making the Social Security Number self-checking,
decoupling it from identification, and penalizing corporations who fail to
protect SSNs or who misuse them, are notably absent. Instead we have yet
another case of technology as a panacea.
But in the current hysterical climate, and with the popular fascination with
overhyped technology, I have no doubt that the bill will pass. I also have
no doubt that it will have no effect on its true target, illegal
immigration, since it will be easy to find low-paid insiders to help forge
the "impossible to forge" cards.
Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/
------------------------------
Date: Mon, 1 Aug 2005 18:19:49 -0700 (MST)
From: Richard Schroeppel <rcs@private>
Subject: Electronic voting -- oops
Excerpting an article about the recent US House of Representatives vote on
CAFTA, which was preceded by some pretty intense politicking:
Hayes switched his vote, and the agreement passed 217-215. Hayes wasn't
the only North Carolina Republican voting for CAFTA. Sixth-term Rep. Sue
Myrick, who represents a safe Republican district in Charlotte, announced
her support for the treaty several weeks ago. Rep. Charles Taylor, who
represents western North Carolina, also had pledged a no vote but missed
the roll call. Taylor said he voted no but that it wasn't recorded because
HIS ELECTRONIC VOTING CARD FAILED. [my emphasis -- rcs]
------------------------------
Date: 2 Aug 2005 09:37:19 -0000
From: Nick Rothwell <nick@private>
Subject: Timezones and appointments (Re: Proposed DST, RISKS-23.95)
As something of an aside: some years ago I had a PDA which did the same
thing. I populated its diary program with appointments prior to a trip to
the US (I live in the UK), and when I arrived and set the device's local
time all the appointments jumped forward several hours (throwing some of
them into the next day).
I can see some limited use for UTC-based appointments - times for phoning
home from abroad, maybe? - but by and large diary entries really do mean "in
local time".
The vendor of the diary program refused to acknowledge this behaviour
as a bug.
nick rothwell -- composition, systems, performance -- http://www.cassiel.com
------------------------------
Date: Tue, 02 Aug 2005 13:35:00 -0000
From: "Craig A. Finseth" <news@private>
Subject: Re: Partisan e-mail censorship as spam filtering (Klammer, RISKS-23.95)
> In the run-up to the 2004 election, I found activist messages about
> (against) Arnold Schwarzenegger were being screened by ACM's e-mail
> screening service controlled by Postini. I was only able to verify this,
> and retrieve my messages, because I had chosen the "quarantine" option,...
Probably because you asked them to: Postini is an anti-spam service which
provides mechanisms for you to control what is filtered (as well as a heck
of a lot of stuff that they do for you). My ISP uses it and offers me full
control over the amount of filtering done, including complete disabling.
So, I have no problem with them doing exactly what I asked them to.
The issue that you bring up has nothing to do with Postini or any other
optional service.
------------------------------
Date: Tue, 02 Aug 2005 10:02:39 -0400
From: Michael Kohne <mhkohne@private>
Subject: Re: Embedded Systems vs Us (Paddock, RISKS-23.95)
>The dealer said that a tachometer feedback sensor had gone bad "and the van
>didn't know what speed it was going so it shut down to be safe".
I propose a slightly different interpretation of the facts: The dealer
doesn't know what he's talking about beyond the sensor being bad. He has
absolutely no idea why that made the van shut down, and he makes something
up.
Another alternative is that he doesn't mean 'safe' the way you mean safe. He
means 'it shut the engine down as an alternative to revving up until it
explodes'. Because I guarantee that if the van's CPU let a bad sensor
destroy the engine you'd be plenty po'd, and you'd probably be screaming
even louder.
Frankly, there are lots of risks involved in designing a car, and the
engineering team may well not have balanced them correctly. On the other
hand, you've got only the words of a dealer for what the engineering team
was trying to accomplish, and no knowledge of what they were REALLY
doing. They may well have had some perfectly valid reason for designing the
system the way they did.
Any complex system has many failure modes and many risks. Very seldom are
all of them evident to the casual observer.
------------------------------
Date: Tue, 2 Aug 2005 18:56:38 -0400
From: "Jay R. Ashworth" <jra@private>
Subject: Re: Embedded Systems vs Us (Paddock, RISKS-23.95)
The problem may not be solely the sensor.
The A604 automatic is apparently *critically* sensitive to the ATF you use,
since it *assumes* the viscosity and pressure characteristics of the fluid,
rather than *responding* to them as hydraulically controlled automatics do.
You *must* use Chrysler ATF-3 or ATF-4, in order for that transmission to
function properly and last it's full life, or so I was told.
(I'm now driving an '87 BMW 635 with a stick, which has it's own
problems. Paid for it with the total check from the Voyager. :-)
Jay R. Ashworth <jra@private>, Ashworth & Associates, St Petersburg FL USA
http://baylink.pitas.com +1 727 647 1274
------------------------------
Date: Tue, 2 Aug 2005 12:12:19 -0700
From: "Russell N. Sheptak" <rsheptak@private>
Subject: Re: Too many features in medical device (RISKS-23.95)
Colin Percival may not have understood the notice he received and wrote
about in his posting (RISK-23.95), or else there's been a rash of similar
problems with multiple brands of blood glucose meters. Like Colin, I
received in July a notice recently about my Lifescan One Touch Ultra blood
glucose meter, noting that if the meter momentarily loses power such as when
it gets dropped, that it may change the units (mg/dL versus mmol/L) and/or
the code number used to correct for a particular batch of test strips, and
that users should be sure to check which units are being displayed, and the
code number before taking a reading. The Lifescan press release noting the
problem is here:
http://lifescan.com/company/about/press/pruom/
Lifescan notes it will modify future models of the same glucometers to
eliminate this problem, but isn't recalling the existing 4.7 million
glucometers with this "feature". Rather they are advising people to verify
the units displayed are correct, and that the correct code number is
displayed each time they take a reading. Both are a good practice even if
the "feature" wasn't an issue.
I suppose that its possible that Colin's medical provider is voluntarily
recalling and replacing these meters, but Lifescan is not. I find it
somewhat alarming that the press release was issued in mid-April, but my
health-care provider took until July to notify me! Misreading and
misunderstanding one's blood glucose reading can be life-threatening over
time if undetected.
Rus Sheptak <rsheptak@private> Research Associate
Archaeological Research Facility, University of California, Berkeley
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Mailman can let you subscribe directly:
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.
INFO [for unabridged version of RISKS information]
.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!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> 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 23.96
************************
This archive was generated by hypermail 2.1.3 : Tue Aug 02 2005 - 16:58:26 PDT