RISKS-LIST: Risks-Forum Digest Tuesday 28 December 2004 Volume 23 : Issue 64
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.64.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
New Year's Privacy Resolutions (Marc Rotenberg)
Tsunami: Natural Disaster Imminent: Whom to tell? How? E-mail!
(Dan Vergano via Harry Crowther)
"April Fools and Ho-Ho-Ho" Combo (James Bauman)
More on computer glitches and laboratory result reporting (Robert L Wears)
Cell phones for eavesdropping - finally some public "chatter" (Gadi Evron)
T-Mobile Cripples the Blackberry (Jason D. O'Grady via Monty Solomon)
Did a 16-bit counter shut down Comair? (Dan Foster via Richard M. Smith)
Re: Y2K? Never heard of it... (Scott Nicol, Ray Blaak)
Re: Pirates, Automeds (Charles Jackson)
Re: Why adding more ... may make systems less secure (R. Geoffrey Newbury)
Re: RFIDing babies (Ray Todd Stevens)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 23 Dec 2004 16:51:21 -0500
From: Marc Rotenberg <rotenberg@private>
Subject: New Year's Privacy Resolutions
[Thanks to Chris Hoofnagle for compiling.]
Protect Your Privacy in The New Year:
Privacy Tips from the Electronic Privacy Information Center (EPIC)
Top Ten Consumer Privacy Resolutions
1. Engage in "privacy self defense." Don't share any personal information
with businesses unless it is absolutely necessary (for delivery of an item,
etc.). Don't give your phone number, address, or name to retail stores. If
you do, they can sell that information or use it for telemarketing and junk
mail. If they ask for your information, say "it's none of your business,"
or give "John Doe, 555-1212, 123 Main St." Don't return product warranty
cards. Don't complete consumer surveys even if they appear to be anonymous.
Profilers can build in barely-perceptible codes that link you to the survey,
and this data goes straight to direct marketers.
2. Pay with cash where possible. Electronic transactions leave a detailed
dossier of your activities that can be accessed by the government or sold to
telemarketers. Paying with cash is one of the best ways to protect privacy
and stay out of debt.
3. Install anti-spyware, anti-virus, and firewall software on your computer.
If your computer is connected to the Internet, it is a target of malicious
viruses and spyware. There are free spyware-scanning utilities available
online, and anti-virus software is probably a necessary investment if you
own a Windows-based PC. Firewalls keep unwanted people out of your computer
and detect when malicious software on your own machine tries to communicate
with others.
4. Use a temporary rather than a permanent change of address. If you move
in 2005, be sure to forward your mail by using a temporary change of address
order rather than a permanent one. The junk mailers have access to the
permanent change of address database; they use it to update their lists. By
using the temporary change of address, you'll avoid unwanted junk mail.
5. Opt out of prescreened offers of credit. By calling 1-888-567-8688, you
can stop receiving those annoying letters for credit and insurance offers.
This is an important step for protecting your privacy, because those offers
can be intercepted by identity thieves.
6. Choose Supermarkets that Don't Use Loyalty Cards. Be loyal to
supermarkets that offer discounts without requiring enrollment in a loyalty
club. If you have to use a supermarket shopping card, be sure to exchange it
with your friends or with strangers.
7. Opt out of financial, insurance, and brokerage information sharing. Be
sure to call all of your banks, insurance companies, and brokerage companies
and ask to opt out of having your financial information shared. This will
cut down on the telemarketing and junk mail that you receive.
8. Request a free copy of your credit report by visiting
http://www.annualcreditreport.com. All Americans are now entitled to a free
credit report from each of the three nationwide credit reporting agencies,
Experian, Equifax, and Trans Union. You can engage in a free form of credit
monitoring by requesting one of your three reports every four months. By
staggering your request, you can check for errors regularly and identify
potential problems in your credit report before you lose out on a loan or
home purchase. Currently, these reports are available to residents of most
western states. By September 2005, all Americans will have free access to
their credit report.
9. Enroll all of your phone numbers in the Federal Trade Commission's
Do-Not-Call Registry. The Do-Not-Call Registry (http://www.donotcall.gov or
1-888-382-1222) offers a quick and effective shield against unwanted
telemarketing. Be sure to enroll the numbers for your wireless phones, too.
10. File a complaint. If you believe a company has violated your privacy,
contact the Federal Trade Commission, your state Attorney General, and the
Better Business Bureau. Successful investigations improve privacy
protections for all consumers.
Available online at http://www.epic.org/privacy/2004tips.html
For more information about privacy, visit the Electronic Privacy Information
Center at http://www.epic.org/
------------------------------
Date: Tue, 28 Dec 2004 11:18:17 -0500
From: "Harry Crowther" <crowther@private>
Subject: Tsunami: Natural Disaster Imminent: Whom to tell? How? E-mail!
[There are huge lessons for disaster recovery in the aftermath of the
Sumatra earthquake/tsunami. PGN]
[Following item by Dan Vergano, *USA TODAY*, PGN-ed]
Suppose you know a disaster is imminent, but don't know whom to tell?
Or how to tell them? Is e-mail the answer? Suppose those to be effected
have no plans to deal with impending disaster?
Minutes after a massive earthquake rocked the Indian Ocean on Sunday,
international ocean monitors knew that a tsunami would likely follow. But
they didn't know whom to tell. "We put out a bulletin within 20 minutes,
technically as fast as we could do it," says Jeff LaDouce of the National
Oceanic and Atmospheric Administration. LaDouce says e-mails were dispatched
to Indonesian officials, but he doesn't know what happened to the
information.
The problem is that Sunday's earthquake struck the unmonitored Indian
Ocean. An international system of buoys and monitoring stations - the
Pacific Tsunami Warning Center based in Hawaii - spans the Pacific, alerting
nations there to any oncoming disasters. But no such system guards the
Indian Ocean. [where there are many earthquakes, although detector buoys
used elsewhere are not deployed there; also risks of false alarms, as the
evacuation in Hawaii in 1986, which reportedly cost more than $30
million...; also the critical needs for evacuation plans and training]
[Source: Scientists in USA saw tsunami coming, by Dan Vergano, *USA TODAY*]
http://www.usatoday.com/news/world/2004-12-28-tsunami_warning_usat_x.htm
------------------------------
Date: Tue, 28 Dec 2004 10:25:40 -0500
From: "Bauman, James" <James.Bauman@safety-kleen.com>
Subject: "April Fools and Ho-Ho-Ho" Combo
Alek Komarnitsky, a computer specialist, two years ago created a Web site
that supposedly allowed browsing users to turn his outdoor Christmas lights
on and off, blinking on command. However, it turns out it was a hoax,
intended "to spread holiday cheer", as he recently confessed to *The Wall
Street Journal*. At first, he used a series of still photographs with
lights on or off, and varying amounts of snow. This year, his wife manually
controlled the lights while a TV helicopter even hovered overhead. [Source:
`Web-controlled' Christmas lights just a holiday hoax, *Chicago Tribune*, 28
Dec 2004; PGN-ed]
------------------------------
Date: Mon, 27 Dec 2004 09:37:20 -0000
From: "Robert L Wears, MD, MS" <wears@private>
Subject: More on computer glitches and laboratory result reporting
I'd like to add one more case to the series of computer glitches causing
failures in reporting patients' laboratory results to the proper people (see
RISKS-23.63 and 23.19, at least).
A hospital recently changed its method for testing for a sexually
transmitted disease (GC); the new instrument reported its results into the
hospital information system in a free text field, where it could be viewed
by clinicians looking up an individual patient's result.
The system for ensuring no results were missed was based on a custom report
written locally (because the vendor's report packaged with the system was
too difficult to manage). This report covered all bacteriology cultures,
not just those for the GC, and looked at a binary field for a positive or
negative value for GC, reporting only the positives. Under the new system,
that field was empty, and so no cases positive for GC were listed by the
report. Because the other cultures were still being reported normally, the
report superficially looked normal (ie, it was not entirely empty).
The person who normally reviewed the report to follow up on all positive,
untreated cases was away on vacation during this change. Some time after
returning, she began to think it odd that no positive GC cases were showing
up, and discovered the foregoing. A corrected report showed that several
hundred cases positive for GC had been missed and had also not been treated
with antibiotics; a non-negligible proportion were in children (where a
positive result might be an indication of abuse).
There are organizational level, management level, and programming level
risks here. At the organizational level there is the risk of increasing
dependency on computer systems in an industry whose experience with these
systems is immature (compared to other settings) and whose investment in
informational infrastructure is low. At the management level, one failure
is not tracking dependencies among system modifications. And at the
programming level, the classic mistake of assuming a missing value means
negative, instead of unknown. (I'm reminding of the aphorism that database
programming would be much easier if missing values did not exist).
The case also indicates the value of experienced workers, who know what the
normal pattern of laboratory abnormalities looks like and have some insight
into the potential seriousness of anomalies. Although it did take them some
time to become aware that something was persistently odd, I'm not sure how
or when it would have been detected otherwise.
Bob Wears, Robert L Wears, MD, MS, University of Florida wears@private
and Imperial College London +44-(0)791-015-2219 r.wears@private
------------------------------
Date: Mon, 27 Dec 2004 20:39:48 +0200
From: Gadi Evron <ge@private>
Subject: Cell phones for eavesdropping - finally some public "chatter"
/Pun intended on the subject line!/
Okay, so, we have all known cell phones are "dangerous".
Stepping out of the cellular protocols security and vendor-side systems, and
forgetting for a second about interception of transmissions through the air,
Trojan horses/worms that may install themselves on the cell phone and even
bluetooth risks, there is the long talked of risk of "operating" a regular
un-tampered cell phone from a far and the risk of modified devices.
Sorry for stating the obvious, but cell phones are transmitters.
For years now paranoid people and organizations claim that eavesdropping
through a cell phone is a very valid risk. Much like somebody pressing
"send" by mistake during a sensitive meeting is a very valid yet different
risk.
Some of the stricter organizations ask you to do anything from (top to
bottom) storing the cell phone in a safe, through shutting it off or
removing the battery, and all the way to *only* "don't have that around here
while we are in a meeting". Then again.. *most* haven't even heard of this
risk.
Forgetting even this risk, many of us even ignore the obvious. I usually ask
people who talk to me while I'm on the phone "even if the NSA (for example)
is not interested in what I have to say or not capable of intercepting it
and even that I don't care if they heard my conversations... Should the
person I talk to hear our conversation?"
Lately there seems to be some more awareness about the "dangers" of cell
phones. Knowing which risk is more of a threat than the other is another
issue.
It seems to me that other than in the protocols, where there has been a
serious learning curve (and GPRS seems very promising), cellular companies
keep doing the same mistakes, and we can see the security problems of the PC
world reappearing in cell phones, much like those of the main frames
re-appeared in PC's (to a level).
History repeated. Heck, I can't even disable Java or the web browser in
most cellular computers (we really should refer to them as computers now).
Here are some URL's on the subject:
Here is one about modified cell phones, which also mentions the risk of
eavesdropping through a cell phone as mentioned above:
http://www.interesting-people.org/archives/interesting-people/200206/msg00031.html
Here is a product for sale, a cellular phone BUILT for eavesdropping:
http://wirelessimports.com/ProductDetail.asp?ProductID=347
Also, check out the IEEE Pervasive article that mentions this problem area,
although discusses more the issue of malware:
http://csdl.computer.org/comp/mags/pc/2004/04/b4011abs.htm
Or Google for "symbian +virus", for example.
Thanks go to David Dagon for the links.
------------------------------
Date: Wed, 22 Dec 2004 17:11:50 -0500
From: Monty Solomon <monty@private>
Subject: T-Mobile Cripples the Blackberry
T-Mobile Cripples the Blackberry
Jason D. O'Grady, powerpage.org, 23 Dec 2004
In his article "T-Mobile Tells BlackBerry Users: GetLess!" PowerPage editor
Emory Lundberg reports about how T-Mobile effectively crippled the
Blackberry smartphone on its network by disallowing outbound requests on TCP
port 80. A real sin considering that T-Mo Blackberry users pay US$40 per
month for "BlackBerry Unlimited w/Enterprise E-mail" that includes
"Unlimited Web Browsing." ...
http://www.powerpage.org/cgi-bin/WebObjects/powerpage.woa/wa/story?newsID=13375
------------------------------
From: "Richard M. Smith" <rms@private>
Date: Mon, 27 Dec 2004 17:24:23 -0500
Subject: Did a 16-bit counter shut down Comair?
Date: Mon, 27 Dec 2004 02:53:06 +0000 (UTC)
>From: Dan Foster <use...@evilphb.org>
Newsgroups: comp.os.vms
Subject: Re: OT: anybody know the details on the COMAIR debacle?
Message-ID: <slrncsuucj.gd7.usenet@private>
In article <41CF6AC4.8030...@prodigy.net>, CJT <abujl...@prodigy.netwrote:
>JF Mezei wrote:
>>So I wouldn't blame this on a computer breakdown. Just a scale of a
>>problem that had not been planned for.
>
>They said the computer crashed. That's different from saying the
>software couldn't find a feasible solution in an acceptable time.
Yeah, well. I wouldn't necessarily take a news report as gospel for a
technical event when lacking details and not reported through a technical
source.
This is unverified, and could be a wild rumor, but sounds credible
(especially since it has better details and someone else with firsthand
knowledge of Comair IT operations whom vouched for the report), and was seen
on a Slashdot thread:
Re:Fire away! (Score:5, Informative)
by [Xorian] (112258) on Sunday December 26, @12:56PM (#11185556)
Someone from Comair (who shall remain anonymous) provided me with some
details which people here would be interested in:
The computer system in question runs AIX. The box itself is still up and
running just fine; this is purely an application error. This application was
not written in-house at Comair, but by another large aerospace company --
SBS (http://www.sbsint.com/ [sbsint.com], owned by Boeing.) This bit of
software does not use an external database, it tracks everything itself. It
is a dedicated system responsible only for flight crew assignments. (The
blather in the original submission about passenger reservations is way
off-base. Those functions are handled by a completely different system.)
The great majority of Comair's traffic flows through the midwest, and the
central base of operations is in Cincinnati. The midwest was hit by a major
snowstorm this week, causing many, many crew reassignments. It appears
right now that the application in question has a hard limit of 32,000
changes per month (ouch). Consider that Comair runs 1,100 flights a day and
there are usually 3 crew members on each aircraft. A big storm like this can
cause problems for days after the snow stops falling. That's a whole lot of
crew changes.
In Comair's defense, this has never happened before and is unlikely to
happen again. The crew system was already on the chopping block long before
this incident, with its replacement scheduled to go live in January. If this
freak storm had happened a month later, this likely never would have
occurred.
[The 2**15 exhaustion has been confirmed. For example, see:
http://www.cincypost.com/2004/12/28/comp12-28-2004.html
PGN]
------------------------------
Date: Sun, 26 Dec 2004 18:06:08 -0500
From: Scott Nicol <snicol@private>
Subject: Re: Y2K? Never heard of it... (DES, RISKS-23.63)
This is one of those little problems that never should have been a problem.
It was a bad design, but the subsequent fixes created the problem. It
appears that lexpress.fr tests their site using Internet Explorer, since the
year will display correctly with this browser.
date.getYear() is supposed to return "year - 1900", so if you want to display
"1999", you should add 1900 to date.getYear() before displaying it.
However, many lazy programmers displayed the date using the string "19" and
tacked on the result of date.getYear(). On January 1 2000, many web sites
showed the year as "19100".
Recognizing the problem, Netscape added date.getFullYear() in javascript 1.1
(but their documentation says it was added in 1.3), which returns the full
year. However, nobody wanted to use it because not every browser in use
supported it (even now, but especially in 2000).
Microsoft also recognized the problem, and "fixed" date.getYear() by making
Internet Explorer return 99 in 1999, but 2000 in 2000, breaking compatibility
with almost every other browser. It would be easy to blame Microsoft for
this, except that Netscape itself made this same "fix" in some (but not all)
versions of navigator 3.
So for the first week of 2000, various web sites displayed 2000, 19100,
3900, 20100, 192000, 202000, or nothing, depending on what browser you were
using and how the code was written (and rewritten, again and again, as
different browser users complained).
The correct fix is to call date.getYear() and add 1900 to it if the result
is less than 1999. You won't find that in any reference manual, however.
------------------------------
Date: Sun, 26 Dec 2004 21:49:11 GMT
From: Ray Blaak <rAYblaaK@private>
Subject: Re: Y2K? Never heard of it... (DES, RISKS-23.63)
And how much longer will it take before broken libraries finally stop having
getYear() return such unintuitive results?
It is not a precision problem.
The only "zero" year should be 0 BC/AD, and nothing else.
[Quite correct, even though there WAS NO ZERO YEAR. Whoever decided
on the BC to AD shift was certainly not a mathematician. PGN]
------------------------------
Date: Wed, 22 Dec 2004 09:43:52 -0500
From: "Charles Jackson" <chuck@private>
Subject: Re: Pirates, Automeds (RISKS-23.62)
Re: Satellite TV Broadcast Pirated
There was a similar occurrence in the USA about 10 or 15 years ago. Someone
seized the uplink of a C-band satellite service (Playboy channel, IIRC) and
inserted their own programming. Technical details of the attack were quite
similar to those described in the item in RD.
Upshot, the miscreants were convicted in US Federal District Court for some
violation of the Communications Act.
Re: Automated medication worse than the disease.
I can't tell from the quote if the problem is (1) "automated medication is
worse than perfect" or (2) "automated medication is worse than non-automated
medication." The headline would indicate (2) but the text only supports
(1). Could it be that the real problem with automated medication that it
permits easy collection of data on medication errors?
------------------------------
Date: Mon, 27 Dec 04 19:13:03 -0500
From: "R. Geoffrey Newbury" <newbury@private>
Subject: Re: Why adding more ... may make systems less secure (Norman, R-23.63)
> These issues happen despite training. They often are present in the best,
> most well motivated, most effective people in the organization.
These issues also happen BECAUSE of training and competitiveness. Here's
an example.
Over the holiday, I caught up on my TV arrears by watching a program I had
taped from the History Channel. This program involved a group whose
objective was finding and diving on the wreck of the Queen Mary (or
Indefatigable or Invincible...I don't remember which one). The wreck is that
of a battlecruiser, hit by a German shell during the Battle of Jutland, May
31, 1916. The battlecruiser exploded and sank, with the death of all hands
but a very lucky few. It was known that the German shell had struck through
to some magazine area, but the size and nature of the explosion indicated
that something more had happened. The blast was too large to be explained by
the magazine alone exploding, or one of the turret ready rooms. They were
designed to contain any blast resulting from a shell incursion.
An alternate theory was that the blast-proof fire traps between the magazine
and gun turrets had failed.
The dive revealed that there were blast effects in both the turret ready
rooms, underneath the forward turrets, and in the main magazine for the
forward guns. In addition, there were unexploded cordite bags all along the
corridor between the magazine and the turret ready rooms. And the blast
doors were not closed...
In order to keep the guns firing "efficiently", the gunners (obviously with
officer knowledge and implicit consent) were storing cordite in the corridor
right up to the ready room blast trap, which they were not using anyway.....
Serving the six forward turret guns with three 50 pound plus bags of cordite
per gun per shot, and attempting to fire at the same rate as could be
attained when using the ready room stores alone... meant not just ignoring,
but subverting the very safety measures which were intended to make the ship
safe. As best the divers could tell, the German shell exploded in one of the
ready rooms. The blast should have been contained there, but...
The physical design did not allow for a quick enough replenishment and
serving of the guns, when the 'safe' method was used. So it was not.
The sailors knew that the captain depended upon them to serve the guns and
keep them firing as quickly as possible. Inter-ship competition at gunnery
meant that every possible advantage had been discussed and explored. And
wouldn't a captain be peeved if his crew could fire a broadside once every
say 2 minutes during training, but only every 3 minutes in battle....
There's a picture of the Queen Mary explosion at www.gwpda.org in the naval
photos page.
R. Geoffrey Newbury, Barrister and Solicitor, Mississauga,Ontario, Canada
1-905-271-9600 newbury@private
------------------------------
Date: Sat, 25 Dec 2004 14:41:02 -5
From: "Ray Todd Stevens" <raytodd@private>
Subject: Re: RFIDing babies (cogg, RISKS-23.63)
Interesting. I have another idea to try. I would suspect that the software
is implemented as "test for existence of an RFID tag in the control area"
not "test for the existance of an RFID tag that is programmed as an active
baby" So happens when you take an RFID that is not attached to a baby and
bring it near the door? How about an RFIDed package that is being
delivered? Given the nature of RFID, this would happen sooner rather than
later.
Also that I know of there has been no real attempt in RFID to prevent denial
of service as far as reading the tags. I wonder if a fairly low powered
device of the right frequency could override the primary IF amp in the RFID
receiver and allow one to prevent the tag from being read, therefore prevent
the system from locking the doors. So I wonder if this is such a great
security device.
Ray Todd Stevens Specialists in Network and Security raytodd@private
Suite 21, 3754 Old State Rd 37, N Bedford, IN 47421 (812) 279-9394
------------------------------
Date: 2 Jun 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. 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 the 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.64
************************
This archive was generated by hypermail 2.1.3 : Fri Jan 28 2005 - 10:24:28 PST