The RISKS Digest
Volume 21 Issue 23

Tuesday, 30th January 2001

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Satellite strike blows away DirectTV pirates
PGN
Senators critical of videogame violence
NewsScan
Could someone die from spam/relay rape?
Sanner
Hackers hit U.S., U.K., Australian government sites
Keith A Rhodes
Risks of pharmacy computer systems
Isaac Hollander
Receipts for Voting Machines
Douglas W. Jones
Flight data recorder in your car's airbag
David Collier-Brown
Re: Aircraft had near-miss in Finland
Michael Walsh
Re: The Chinook Crash
Simon Pickin
Re: Organiser Bugs
Tyler
Mike Cepek
Re: Risks of owning a cute domain name
Terry Carroll
Seeing Y2K bugs everywhere
Andrew Klossner
Re: 54 weeks in a year?
Lawrence K. Chen
Nick Brown)
Re: UK Trials of GPS controlled car speeds
Derek Ziglar
Brian Clapper
Andres Zellweger
Harlan Rosenthal
Peter Houppermans
Symposium on Requirements Engineering for Information Security
Gene Spafford
Info on RISKS (comp.risks)

Satellite strike blows away DirectTV pirates

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sat, 27 Jan 2001 20:53:16 -0800 (PST)

On 21 Jan 2001, DirecTV remotely disabled about 100,000 smart-card enabled
set-top boxes that controlled illegal reception of their satellite TV.
(Buried in the programming code was a message that read "GAME OVER" — for
those who perused the code.)  About 9.5 million legitimate subscribers pay
something like $50/month for the hardware and $22/month for the programming.
DirectTV estimates this will save them over $100 million/year.  The pirated
operations involved the iterative installation of bogus software that
enabled access despite each successive vendor change to the programming
code.  DirectTV believes that the counteraction disabled all of those bogus
smartcards containing illegal software.  DirectTV is part of Hughes
Electronics.  [Source: P.J. Huffstutter and Jon Healey, *LA Times*;
PGN-ed (How long will it be until the next-iteration hack occurs?)]


Senators critical of videogame violence

<"NewsScan" <newsscan@newsscan.com>>
Fri, 26 Jan 2001 08:21:59 -0700

U.S. Senators Joseph Lieberman, Herb Kohl, and Sam Brownback plan to
introduce legislation that will punish companies that market excessively
violent video games to children. Kohl, a Wisconsin Democrat, said:
"Practically everybody in the industry still markets inappropriate games to
kids, practically every retailer regularly sells these games to kids, and
practically all parents need to know more about the rating system." But Doug
Lowenstein, president of the Interactive Digital Software Association, which
represents video game makers, argues that such legislation could violate the
First Amendment guarantees of freedom of speech and might simply make it
more complicated for the video game industry to police itself. (AP/USA Today
25 Jan 2001; NewsScan Daily, 26 Jan 2001)
  http://www.usatoday.com/life/cyber/tech/review/games/2001-01-25-violence.htm


Could someone die from spam/relay rape?

<Sanner@flashmail.com>
Sun, 28 Jan 2001 10:25:59 -0500

Consider the following two spam emails, one sent apparently from a
Birmingham (bhm), Alabama BellSouth.net dial-up via a mail server at a
hospital in Easton, PA and the other (picked off
news.admin.net-abuse.email) sent from a Jacksonville dial-up of
Coastalnet.com via the same mail server to British Columbia.

You'll notice that the first one spent 84 hours in the hospital mail
server, from 4:30 P.M. Wednesday until 4:30 A.M. Sunday.

Now it is possible that someone was sending important medical data through
that mail server. Some lab instruments these days even use email--I once
received porno spam via what I was told was a microscope at a Belgian
university. (the university hadn't known that the microscope was running
sendmail and therefore hadn't bothered to take its usual precautions against
spammers)

An 84-hour delay in important hospital email could, in theory, kill a
patient.

By the way, I have noticed that these spams apparently for a pyramid scheme
(International Global Prosperity?) come from all over the country and use
the same open mail server for mail sent in a certain week or so. Assuming
that third party relaying of bulk email without explicit permission of the
server owner is a crime, there appears to be an interstate criminal
conspiracy.


Hackers hit U.S., U.K., Australian government sites

<"Keith A Rhodes" <RhodesK@GAO.GOV>>
Tue, 30 Jan 2001 07:43:16 -0500

Attrition.org reports that hackers attacked government sites in the U.S.,
U.K., and Australia last weekend, one of the "largest, most systematic"
defacements of .gov/.mil sites worldwide.  Check out
  http://www.attrition.org/
for details.  [Source: David Legard, IDG News Service, 22 Jan 2001; PGN-ed]


Risks of pharmacy computer systems

<Isaac Hollander <ysh@mindspring.com>>
Fri, 26 Jan 2001 13:12:35 -0500

I have patronized the same pharmacy for several years now.  Today I went to
fill a prescription (bad flu season this year)...  A new pharmacist was
behind the counter, so she meticulously checked my insurance information,
address, date-of-birth, and other pertinent data.

Initially, she refused to fill my prescription because my date-of-birth in
her computer was in 1946.  I was only able to convince her that my
date-of-birth was in 1970 by reciting a list of all the prescriptions I've
filled at this particular pharmacy, and by giving her my insurance card to
prove that my policy information was correct.

The troubling thing is that I filled a prescription in the same pharmacy
less than 1 month before.  Something happened in the interim to corrupt
my information — an automated cleanup job, perhaps.  The risk is that
next time it won't be my antibiotic but it'll be someone's heart
medication, and the pharmacist won't be as willing to listen to reason.

Isaac


Receipts for Voting Machines

<"Douglas W. Jones" <jones@cs.uiowa.edu>>
Mon, 29 Jan 2001 16:43:08 -0600 (CST)

An article in *The New York Times*, 28 Jan 2001, entitled "Nation Awash in
Ideas for Changing Voting", included the following paragraph:

> Ideas include changing Election Day to a weekend or making it a
> federal holiday, closing polls at the same time across the country,
> allowing voter registration on Election Day and requiring that
> machines give voters receipts.

Since the confusion surrounding the November election, I have heard several
proposals that voting machines should give receipts.  This is an extremely
dangerous proposal!

If a voting machine gives a voter a receipt indicating the votes he or she
has cast by, someone intent on buying a vote could demand to see that
receipt as a condition of payment.  Today, for example, unions can urge
their membership to vote the union line, and employers can urge their
employees to vote the company line, but they have no way of knowing if a
particular member or employee followed their advice.  Receipts would change
this, opening the door to a class of election fraud that has not been
widespread in the United States since the 19th century.

There are two ways to make voting machine receipts safe against this kind of
fraud.  One is to eliminate ballot content from the receipt, reducing it to
mere proof that the voter has voted.  This eliminates the value of the
receipt as proof against the kinds of problems voters had in Florida last
November.

The other approach is to issue the voter a receipt, but to deny the voter
the right to take the receipt from the polling place, for example, by
requiring that the voter deposit the receipt in a special box.  If we do
this, we may as well consider this box to be a ballot box, with the receipt
being elevated to the official status of a ballot, and the voting machine,
no matter how computerized, reduced in status to a ballot marking device.
The official hand-recountable record of the vote then becomes the paper
ballot issued by the machine.

Since the only votes that should be counted are those actually deposited in
the ballot box, this second approach eliminates the need for the
computerized voting machine to record any votes in its internal memory.
Optical mark reading of machine-printed ballots should be extremely easy,
but for auditability, no information should be included on the
machine-printed ballot other than human-readable content, and in fact,
audits of the voting machine and ballot reading software would have to
include checks to make sure that there is no use of steganography to include
additional information on the paper ballot that might be used to connect it
to a particular voter.

Douglas W. Jones, Assoc. Prof. of Computer Science, University of Iowa
Chair, Iowa Board of Examiners for Voting Machines & Electronic Voting Systems

  [Note that Rebecca Mercuri's PhD thesis (noted here previously) provides
  voter confirmation of a paper record, but that record is never handled by
  the voter:
    http://www.notablesoftware.com/evote.html
  PGN]


Flight data recorder in your car's airbag

<David Collier-Brown <davecb@canada.sun.com>>
Tue, 30 Jan 2001 08:22:24 -0500

*The Toronto Star* (thestar.com, article by Paul Legall) reported on 25 Jan
2001 that the Ontario Provincial Police can now read the "event data
recorder" units that are part of auto air-bags. The information includes
speed (as you'd expect), but also braking, whether the driver's seat belt
was fastened, if the ignition was turned on after the air bag went off and
if there were other impacts before the one that set the airbag off.  The
speed information was disclosed to a coroner's jury recently.

David Collier-Brown, Performance & Engineering Team, Americas Customer
Engineering    1-905-415-2849   davecb@canada.sun.com


Re: Aircraft had near-miss in Finland (RISKS-21.22)

<Walsh Michael <michael.walsh@wmdata.fi>>
Mon, 29 Jan 2001 12:49:39 +0200

After I sent off my piece to RISKS, I noticed nothing more in the papers.
However, on showing my wife the issue, she remarked that after that, they
discovered that other planes not just Russian ones were disappearing from
radar screens at Helsinki airport, and then traced the fault to probably
being caused by building work at the airport.

It seems that once the Russians were out of the picture (pun, not intended,
but noticed), the story became of less interest to the papers here and so
fell below my horizon (oops).

(As we're talking about building works here, maybe the Mickey Finn comment
wasn't so far off !)

Mike Walsh, FIN-00300 Helsinki, Finland  <michael.walsh@wmdata.fi>


Re: The Chinook Crash (RISKS-21.14,18-20,22)

<Simon Pickin <Simon.Pickin@irisa.fr>>
Mon, 29 Jan 2001 18:47:29 +0100

It certainly seems to be the case that important persons have more risk of
being involved in serious air crashes than the rest of us mortals,
particularly crashes coinciding with important political events in which
they are involved, such as, just to pick one example, the start of serious
peace negotiations between warring factions. In such cases, more
"unconventional" explanations should not be completely ruled out and should
perhaps even be voiced explicitly (at the risk of being called various sorts
of names).  An example of such a crash, in the press again recently on the
occasion of its 20th anniversary, is the one killing the Portuguese prime
minister Francisco Sa Carneiro and his defense minister Adelino Amaro da
Costa on 4 Dec 1980. Time will (perhaps) tell. Just an observation.

Simon Pickin <simon.pickin@irisa.fr>


Re: Organiser Bugs (Ladkin, RISKS-21.21)

<<tyler@mango.net.nz>>
Sat, 27 Jan 2001 10:19:47 +1300

Three Words: Disaster Recovery Trial

The simplest way of making sure your backups are working, is to try
restoring them. We sit down and do this and document how to with all our
clients servers yearly and whenever a big change is made on their servers. I
find about 90% of the time on new clients servers, we couldn't restore the
server/data on the first attempt due to various problems. Better to find out
in a test run, than in a panic situation at 2AM on a Monday morning. (Or the
middle of a trial.)

To extend a catchphrase, If your information is important enough to backup
up, it's important enough to test restoring it.

Tyler Rosolowski


Re: Organiser Bugs (Ladkin, RISKS-21.21)

<Mike Cepek <mike.cepek@usa.net>>
26 Jan 2001 08:35:59 CST

I also had to replace my well-worn and relied upon Palm III after a
catastrophic failure.  There are two key differences in our experiences,
however.

Firstly, I used the (also free) Palm Desktop product which came with the
device from the manufacturer.  The software works with Windows and Macintosh.
(No flames please, I *do* support freeware, shareware, Linux, etc).

Secondly,  my restoration was quick, easy, and complete.  At least I have yet
to find any missing data (I do take your point: how can I really know it's
*all* there?).  I trust that any such problems would be fixed by now in such a
popular product, since lots of people besides me have needed to perform
restores.

The risk I see here is assuming recompiled freeware would have the same
quality that similar software from the manufacturer would have.


Re: Risks of owning a cute domain name (Griffith, RISKS-21.21)

<Terry Carroll <carroll@tjc.com>>
Fri, 26 Jan 2001 11:49:25 -0800 (PST)

> As owner of the domain "dweeb.org" [...]

It doesn't have to even be "cute."  I have tjc.com.  Several times a week, I
receive email intended for: the True Jesus Church (whose domain is tjc.org);
a company in India named Tata Johnson Controls Automotive Ltd.  (whose
domain is something like tjc.co.in, but who apparently took out an
employment advertisement listing an email address of careers@tjc.com as the
contact point); Piper Jaffrey Company, and investment company (pjc.com;
about half of these email messages contain what should be highly
confidential information; I enjoy copying all parties on my email message
pointing out that they've sent this information out to a random recipient
(and yes, I do then destroy the confidential email)); and, most maddeningly,
students at Tyler Junior College in Texas (tjc.tyler.cc.tx.us).

The Tyler kids are most maddening, because they freely give out an erroneous
tjc.com address to Web sites that harvest for spammers.  The Piper Jaffrey
case is the biggest Risk, though.

Interestingly, I haven't detected significant email that should be for
the TJC Network (tjc.net); and the Piper Jaffrey case seems to be the only
consistent off-by-one-letter error.

Terry Carroll, Santa Clara, CA  <carroll@tjc.com>

  [Various similar comments from others.  PGN]


Seeing Y2K bugs everywhere

<Andrew Klossner <andrew@user2.teleport.com>>
Mon, 29 Jan 2001 08:23:14 -0800

Ethan McKinney wrote that he received a $0.00 bill in January for a canceled
credit card and opined that it was probably a Y2K bug at work.

I always receive a $0.00 bill the January after I cancel a credit card.  The
January bill doubles as an end-of-year tax statement, showing the total
amount of interest paid during the previous year.

Y2K gets far too much credit for perceived computer malfunctions.

Andrew Klossner (andrew@teleport.com)


Re: 54 weeks in a year? (Dubery, RISKS-21.19 and 20)

<"Lawrence K. Chen" <lkc@cyberdude.com>>
Mon, 29 Jan 2001 22:15:52 -0500

Just because a date is in a 'standard' format, doesn't mean it is meaningful
to all.

Last year a VP of Product Development for a software company was traveling
to Europe for a meeting.  For entry to the particular country a valid VISA
was required.  Checking his old VISA he saw a date like '10/08/2000', and
noted that October 8th, 2000 means his old VISA is still valid.
Unfortunately arriving in the European country, he was refused
entry...because his VISA had expired on August 10th, 2000.

Fortunately, after some deliberation he was able to fly to a country that
didn't have a VISA requirement, and conduct his meeting over video....
Though he could probably have done it by video without leaving the US.

On the flip side, I stood behind a gentleman trying to deposit a foreign
check that suffered from a similar confusion in date format.  The US bank
wouldn't cash the check because it had been excessively post dated, rather
than seeing that it had been issued during the early part of this year.

Since I grew up in Canada, date confusion was so annoying...that I was in
the habit of using ISO date format.  Which has the advantage of making
sorting by date much easier (at least it did until Y2K, because to save
space on the mainframe the first two digits were dropped for date keys).
Unfortunately, the US post office wouldn't accept a form where I had used
ISO date format.

  [Old story in RISKS, but manifestations keep recurring, and after all
  RISKS seems to be laden with recurrences of old stories about which no
  one was paying adequate attention.  PGN]


Re: 54 weeks in a year? (Dubery, RISKS-21.21)

<BROWN Nick <Nick.BROWN@coe.int>>
Fri, 26 Jan 2001 10:17:06 +0100

This is just one example of a huge major problem, caused in no small measure
by the lack of any mandatory formal training for programmers.  That in turn
results from the huge demand for IT systems, the shortage of people who can
program (even badly), and the evolution of technology which means that any
training programme "appears" to be obsolete after three years (especially if
emphasis is put on learning APIs rather than learning about the real world,
which is what happens when you go on software manufacturers' training
courses).

As Lauren Ruth Weiner pointed out in her indispensable book "Digital Woes",
you wouldn't hire a 24-year-old architect to design a stadium.  But the
experienced team of architects you did hire might well be using software
built by a couple of 24-year-old programmers who had never experienced the
consequences of any sort of structural failure.

This week we received a consultant's resume from a software house.  It is 12
pages long and has a pretty colour background picture of a forest scene
(itself a RISK; the e-mail was so big that initially it couldn't be
delivered to a default-configuration mailbox).  This consultant is 25 years
old and has been out of college for three years; every two-week-long
assignment has been written up as if she had been the lead developer of
Multics.  We won't be using her services (at $US 800 per day) to maintain
our PeopleSoft database.  But somebody will.

Nick Brown, Strasbourg, France.


Re: UK Trials of GPS controlled car speeds (RISKS-21.22)

<"Derek Ziglar" <dziglar@yahoo.com>>
Sat, 27 Jan 2001 11:43:10 -0500

> The tests, which prevented the car from topping 30mph, 40mph and other...

This will also surely resurrect problems that dates back to a much older and
simpler technology--fixed speed governors on cars.

Back in the early 1970's, my father worked in the administrative offices of
a large local utility company. At that time, the US imposed stricter speed
limits to conserve fuel. Thinking the company could set a shining public
example, they decided to install speed governors in the company's fleet of
sedans.

That lasted only a short while as the number of automobile accidents
*increased* within the fleet because of several significant unanticipated
factors. One was that these speed-restricted cars were still having to
interact on the road with non-restricted vehicles--leading to situations
where the restricted vehicle was at a disadvantage on emergency maneuvers
such as accelerating out of danger. The other was that the drivers were used
to driving unrestricted cars, so occasionally made risky driving decisions
momentarily forgetting the restrained capabilities of their company vehicle.

These risks exist in the basic premise of imposing blanket restrictions on
vehicles with no provisions for exceptions based on the actual circumstances
the driver is facing at any moment. Many such technologies cannot be
guaranteed to be sufficiently safe until *everybody* has it and is operating
on equal terms. This new system adds a lot of complexity to merely apply
different governor speeds based on the specific road rather than the fixed
maximum vehicle speed imposed by the old automotive speed governors.

Imagine being on a long downhill expressway with several large heavy
tractor-trailers bearing down on you at substantially above the speed limit
your vehicle is restricted to? Imagine having a car following you at 50 mph
when you cross into a 40 mph zone and your vehicle is *forced* to reduce
speed. I hope the driver behind you is equally alert and attentive to the
speed limit change!

What I fear from the people so vigorously pushing these technologies is that
such safety risks that were long ago learned will be overlooked or glossed
over. Somehow the new high-tech approach leads people away from realizing
the basic concept is not new and the new solution fails to address or
resolve concept flaws proven in prior low-tech implementations. Not to
mention any new safety risks introduced by the newer implementation.

Sadly, these may not come to light until the first driving fatality or, as
in the case of my father's employer, the statistics of the system in large
scale use show an alarming trend.

Derek Ziglar, Atlanta, GA


Re: UK Trials of GPS controlled car speeds (Loughran, RISKS-21.22)

<Brian Clapper <bmc@WillsCreek.com>>
Sat, 27 Jan 2001 13:10:36 -0500

Aside from the obvious "will it work reliably?" questions, I wonder exactly
what affect this will have on automobile accidents. Certainly there's a
correlation between excessive speed and auto accidents, so one would
naturally expect the number of auto accidents to decrease in response to
technologically enforced maximum speeds. But there are also times when
exceeding the maximum speed can prevent an accident. How many of us have
found ourselves in a situation where it was necessary to step on the
accelerator, not the brake, to avoid a hazardous situation? I know I have.

This approach to limiting excessive speeding seems as though it might throw
the baby out with the bathwater.

Brian Clapper, bmc@WillsCreek.com


Re: UK Trials of GPS controlled car speeds (RISKS-21.22)

<ZellwegA@cts.db.erau.edu (Andres Zellweger)>
Mon, 29 Jan 2001 07:50:19 -0500

We can only hope that the designers of the system for GPS control of
automobile speeds being tested in the U.K.(RISKS 21.22) learn about
inherent risks of such devices from the aviation industry's experience
with envelope protection systems for aircraft control.

(I can just see myself trying to accelerate to avoid an accident ...)

Dres Zellweger, Embry-Riddle Aeronautical University


Re: UK Trials of GPS controlled car speeds (RISKS-21.22)

<<H.Rosenthal@Dialogic.com>>
Fri, 19 Jan 2001 20:33:33 -0800

  The tests, which prevented the car from topping 30mph, 40mph and other
  limits, were "highly reliable" ...

How about: I have just enough time on a small road to pass this stopped
delivery truck . . . oops, have to gas it a little to get clear of the
oncoming traffic - but I can't! The speed limiter cuts in!  To avoid
speeding, let's have a head-on collision.  How about something in the
roadway, or flashing lights just as you cross rail tracks, or emergency
vehicles nearby, or any other environmental factor that might make a moment
of excess speed the appropriate and safer response?

And how quickly does it respond?  How much of a delay is there between
speeding up and the system deciding that you shouldn't be allowed to go that
fast?  And do you - and the person behind you! - get warning that you're
about to be slowed down?

Harlan Rosenthal


Re: UK Trials of GPS controlled car speeds (RISKS-21.22)

<Peter Houppermans <Peter.Houppermans@paconsulting.com>>
Mon, 29 Jan 2001 17:09:24 -0000

Just imagine how much fun you'll be having overtaking someone who's doing 29
miles in a 30 mile zone - overtaking being occasionally necessary but
universally recognised as one of the most dangerous manoeuvres.  Interesting
idea - it actually removes a safety margin as you cannot speed up to make
that manoeuvre as short as possible.

I also note how this cunningly avoids taking care of the root problem:
driver education.  It's easier to fix the car than the driver - so I'm
eagerly awaiting the next experiment: cars with breathalysers...


Symposium on Requirements Engineering for Information Security

<Gene Spafford <spaf@cerias.purdue.edu>>
Sun, 28 Jan 2001 10:33:24 -0500

  Advance Program and Call for Participation
  First Symposium on Requirements Engineering for Information Security
  5-6 March 2001. Indianapolis
  Sponsored by Purdue University CERIAS, in cooperation with
  NCSU eCommerce Program, NIST, NIAP, ACM SIGSOFT, ACM SIGSAC
    http://www.cerias.purdue.edu/SREIS.html

Security requirements for new electronic commerce and Internet applications
exceed the traditional requirements for network security and traditional
software systems. Security requirements are more complex and increasingly
critical. Informally stated and de facto requirements are often of critical
importance in the design and operation of these systems, but they are
frequently not taken into account.

The symposium is intended to provide researchers and practitioners from
various disciplines with a highly interactive forum to discuss security and
privacy-related requirements. Specifically, we encourage those in the fields
of requirements engineering, software engineering, information systems,
information and network security, as well as trusted systems to present
their approaches to analyzing, specifying, and testing requirements to
increase the level of security provided to users interacting with pervasive
commerce, research, and government systems.

The symposium will begin with short tutorials, include an invited keynote
address by John Rushby of SRI, and include talks, breakouts, and a panel
session.  The symposium will be followed by a National Summit sponsored by
NIAP to bring together parties from government, industry, and academia to
talk about how to design better software.

A preliminary program, tutorial information and registration
information are all available online at the symposium WWW site:
<http://www.cerias.purdue.edu/SREIS.html>.

Please report problems with the web pages to the maintainer

x
Top