The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 23 Issue 22

Monday 1 March 2004


Stolen heart monitor
Nigel Metheringham
Keeping online games honest
4.6-million DSL subscribers' data leaked in Japan?
via Dave Farber
E-mail robbery, the easy way
Ralf Ertzinger
Solving e-mail problems economically
Peter B. Ladkin
Laptop security
Gadi Evron
"Where did it print?" 1990 version
Daniel P. B. Smith
Buffer overflows and Burroughs/Unisys
Keith Gobeski
Michael LeVine
MS Java Virtual machine
Curtis Karnow
Garage-Door openers; Rapid disassembly of PCS phones
Charles Jackson
Re: Garage-door openers
Michael Kent
Re: Garage-door openings by aircraft
Scott Peterson
Further misdirected on-line trip planning
Bob Heuman
Amtrak Website routing
Richard S. Russell
REVIEW: "Developing Secure Distributed Systems with CORBA", Lang/Schreiner
Rob Slade
Info on RISKS (comp.risks)

Stolen heart monitor

<Nigel Metheringham <>>
Fri, 27 Feb 2004 11:57:09 +0000

Seen at

  A mother is urgently appealing for help after her eight-year-old son's
  heart monitor scanner was stolen from her car outside the family home.
  Daniel Hunter from Bridgend in south Wales, is fitted with a pacemaker
  which is monitored by the scanner -- the size of a mobile phone -- without
  which his health is at risk.  It is the only one he can use, and if it is
  not found he will have to undergo potentially dangerous operation to be
  fitted with a new pacemaker -- a device which sends electrical impulses to
  the heart to keep it beating regularly.

The idea of an implantable medical device apparently requiring physical
reconfiguration (at least) to talk to an external monitor implies a level of
trust in the reliability of the external device which is seriously scary.
The RISKS hardly need pointing out here...

Keeping online games honest

<"NewsScan" <>>
Mon, 01 Mar 2004 08:14:17 -0700

IT GlobalSecure sells software that prevents network vandals and dishonest
players from manipulating online gambling. The company's chief executive
says: "If you look online, there are whole Web sites either complaining
about cheating or sharing ways to cheat. We've had people who are even just
playing gin rummy online saying, 'We think we're being cheated, but we don't
know what to do.'" The firm's software is based on encryption technology
that can be applied to any network gaming system to validate the randomness
of events in games of chance, verify player identities and create audits of
each game.  [*The Washington Post*, 1 Mar 2004; NewsScan Daily, 1 Mar 2004]

  [What about keeping the gambling software "honest"?  PGN]

4.6-million DSL subscribers' data leaked in Japan? (From IP)

<[Identity unknown]>
Thu, 26 Feb 2004 18:09:55 -0500

  [From Dave Farber's IP list, where the identity of the contributor
  was withheld.  PGN]

The Tokyo Metropolitan Police arrested three men on suspicion of trying to
extort up to 3 billion yen (U.S. $28 million) from Softbank. The suspects
claimed that they obtained DVD and CD disks filled with 4.6 million Yahoo BB
customer information. The two of the suspects run Yahoo BB agencies which
sells DSL and IP Telephone services.

Last month, Softbank was contacted by the suspects who demanded investment
to their venture in exchange for the disks. Although the company confirmed
that a part of the customer data shown by the blackmailers was that of real
Yahoo BB customers, the company so far has not admitted their whole customer
data was stolen. The police and Softbank will examine the data on the seized
disks. It will take several days before we know the exact scale of the
leak. According to Softbank, the stolen data includes name, address,
telephone number, and e-mail. No billing or credit card information was

Also, it has been reported that the police in Nagoya arrested another man
who attempted to extort 10 million yen (U.S. $ 90,000) from Softbank. The
man sent the company e-mail messages including the one with 104 customer
data and claimed to have over 1 million customer information on floppies. He
worked as a temporary customer support personnel for Yahoo BB in the past
and it was likely that he stole the customer data while he worked for the
DSL provider. The police considers the Nagoya attempt is not related to the
Tokyo case and the sources of the data leak are different.

At this point, there is only speculation on how the customer data was
stolen. The data was not accessible from the public networks and Softbank
denied any intrusions to their computer networks from the outside. It was
likely to be an inside job. There might have been an accomplice(s) in the
company or its subsidiaries/affiliates. An Softbank executive stated that
there were over 100 people who could log-on to the PCs connected to the
customer database. The company is in the process of cheking the log to find
any suspicious access to the data. (Although Softbank is a victim of hideous
crime, I expect that there will be a lot of scrutiny on the company's policy
and practice regarding data security and privacy protection.)

Although the both extortion attempts were foiled, the backgrounds of the
Tokyo suspects are disturbing. One of the Tokyo suspect is the leader of a
right-wing political organization. In Japan, the shady right-wing groups are
often a part of the organized crime(Yakuza gangsters) or have a close tie
with Yakuza. It is unthinkable that the 4.6 million personal data fell into
the hands of the underworld. The bogus Internet bills from the use of dating
and porn sites have become social problem in Japan.(Even they have no idea
of using those services, some people send money when they receive a letter
or e-mail from the collection agencies sounding like Yakuza-related. I am
hoping the suspects are just bluffing.)

The other two are the followers of a powerful religious group affiliated
with a major political party. According to some tabloids, one of them was a
former ranking member and was participated in the wiretapping of the home of
the communist party leader in some 30 years ago (The communist party and the
religious party were strongly criticising each other then.). Although he was
acquitted in criminal courts, a civil trial acknowledged his involvement
(like O.J.?).

The opposition parties are demanding the government to investigate the
unprecedented scope of the personal data theft and a committee in the House
of Representatives is considering to call Masayoshi Son, the Softbank
president to testify.

IP Archives at:

E-mail robbery, the easy way

<Ralf Ertzinger <>>
Mon, 1 Mar 2004 23:23:45 +0100

The German online news magazine Spiegel Online [1] recently reported on an
interesting combination of risks [2]: using T-Online as your Internet
provider, and having a WLAN access point.

T-Online is Germany's largest Internet provider, and while this in itself is
not a risk, T-Online has always used a unique approach towards POP3 mail
delivery. When being connected via T-Online, one does not have to provide a
username or password to connect to the T-Online POP3 server in order to
fetch mail, since the user is identified by his IP address.

Combine this with the growing number of (unsecured) WLAN access points and
DSL routers and you get to read other people's mail just by driving along
the streets.  T-Online is aware of the problem, and provides information to
secure WLAN access points on their web site, but changing the POP3
identification system (which was introduced long before anyone thought of
broadband Internet, connection sharing and wireless LAN) seems to be almost
impossible, having millions of customers.


  [PGN showed this a colleague, who commented thusly:
    "Just how long have we been telling people that it's a bad idea to do
    authentication based on IP address?  The Berkeley r-commands, after all,
    where supposed to be an interim solution, IIRC.  That was 1982.
    Anyways, I'm quite sure that this was known to be a Bad Idea(tm) before
    T-Online went into business."
  And when a very well-known bank first put up its Internet banking on the
  Web, it authenticated on IP addresses.  Bad ideas are often popular.

Solving e-mail problems economically (Re: Kestenbaum, RISKS-23.19)

<"Peter B. Ladkin" <>>
Thu, 19 Feb 2004 10:47:37 +0100

Lawrence Kestenbaum substantiates in his RISKS-23.19 note the considerable
problem generated by inappropriate e-mail server responses to
virus/worm/spam e-mail, which I noted with regard to Sobig (Some
observations on e-mail phenomenology, RISKS-22.88). However, his last
paragraph misplaces blame.

The spammers and worm/virus writers are no more responsible for the amounts
of junk generated by misconfigured e-mail servers than I am responsible for
the damage caused by an automobile whose driver does not observe my bicycle
until the last second and manoeuvres suddenly.

I agree with Kestenbaum that the e-mail system is more or less broken.

*The Economist* has addressed the issue in its edition of 14 Feb 2004
(Business Section. The article is available on its WWW site for a fee to
non-subscribers). In an article entitled "Make 'em pay" (supertitled "The
fight against spam", subtitled "The dismal science takes on spam"), the
journal suggests that techies have had a go at the problem, then
politicians, and now economists are "taking over". Risks readers may recall
that Bill Gates said in an interview at the recent World Economic Forum at
Davos that certain measures Microsoft favors will get rid of spam in two
years.  One of those proposals was a per-mail fee, like postage. The article
says that "Sceptics noted that Microsoft could also help by fixing security
flaws in its products -- the latest confessed to this week -- that can be
exploited by spammers".

The article discusses various schemes, namely those by Goodmail
Systems, IronPort Systems, and Balachander Krishnamurthy at AT&T Labs.

I hope that the techies and politicians are not yet finished.  The payment
proposals distinguish between two classes of user: bulk mailers and
others. (The post office does also: bulk mail there is cheaper than ordinary
mail.) Bulk mailers should, somehow, pay. But not all bulk mailers are
spammers. I suggest that a much more fundamental distinction lies between
fraudulent e-mail (e.g., that with intentionally false header information)
and non-fraudulent e-mail. In my opinion, this issue must be addressed come
what may. Fraud in electronic communication covers much broader issues, even
for business, than spam and its responses: for example, one needs reliable
processes for establishing, validating and enforcing contracts
electronically. E-mail authentication would be a great help.

Since the e-mail server market is dominated by very few pieces of SW, one
imagines a coordinated effort to alter e-mail protocols to introduce some
degree of authentication, say along the lines of Tripoli, lies at least as
well within reach as schemes to introduce payment for e-mail. We may presume
that producers of such SW are well aware of such proposals, and we may
conclude that they are not favored because they do not fit someone's
business model.

I find some confirmation for this conclusion in that schemes to introduce
individual payment for free e-mail service are being touted at the very time
when just the reverse is happening with telephony: schemes for Internet
telephony are apparently arousing interest in major telecommunications
companies over the traditional individual payment model.

I imagine that if one is a commercial SW producer it is easier to make money
by responding incrementally to Internet users' issue du jour rather than by
introducing a procedure that would handle a large class of such problems all
at once.

One argument in favor of the business model could be that the economy which
has sprung up to deal with spam and Internet security issues is now large
enough to lobby successfully against any proposal that would reduce its
potential clientele at a stroke. If this is so, then incremental
modification would seem to be the only socially viable possibility. What a
depressing thought.

Peter B. Ladkin, University of Bielefeld,

Laptop security

<Gadi Evron <>>
Sat, 28 Feb 2004 10:23:24 +0200

I always say, whenever laptops are mentioned: "Forget everything else, I
have nightmares already!".

The loss of information due to laptop thefts is extremely high, here is
an innovation that may possibly be as useless as car theft alarms
(unless you are nearby and didn't leave the laptop in the car), but it's
a good start. This may actually be useful.

What I'd like to see is a GPS device with wireless communication to my
cell phone. It can be a quiet indicator, or perhaps ring when it is
being moved.. or even when I move too far away from it.

You can find the article at:

"Where did it print?" 1990 version (Re: Meadows, RISKS-23.16)

<"Daniel P. B. Smith" <>>
Thu, 5 Feb 2004 18:58:49 -0500

Chris Meadows account of printing sensitive information using a wireless
network at Kinko's, only to discover that it had not printed on any printer
_at_ Kinko's, reminded me of a vaguely similar occurrence circa 1990. I
worked in R&D at a Fortune 500 minicomputer company, which at that time had
one "corporate" fax number which connected to _one_ fax machine whose phone
line was, understandably, usually busy. Someone at another company needed to
send me an urgent fax. He happened to have a copy of my company's phone
book. After listening to his fax machine redial continuously for five hours,
he checked the phone book and noticed that it listed about fifteen fax other
numbers. He selected the "R&D Documentation" number, and called me to let me
know he had just gotten his confirmation that it had been received at "R&D
Documentation." I went to R&D Documentation.

They had no fax machine. They did not know of any "R&D Documentation" fax
machine. Indeed, they did not know of any fax machine in R&D.  The phone
book had no information beyond the machine names and numbers.

I worked my personal connections as best I could, asking every knowledgeable
old-timer I knew to regale me with lore and legends relating the locations
of _any_ fax machines other than corporate. I slowly discovered the location
of several fax machines. The fifth one--located in Purchasing--happened to
be the one that identified itself as "R&D Documentation." They'd inherited
the machine and the phone line, and nobody knew how to change the message,
so they'd left it set that way.

Daniel P. B. Smith, alternate:

Buffer overflows and Burroughs/Unisys

<Keith Gobeski <>>
Thu, 26 Feb 2004 08:27:26 -0500

Burroughs (now Unisys) large (now Clearpath/Libra) systems have had hardware
detection of buffer overflows since at least the late sixties.  Only memory
areas marked as code are executable and only certain processes can mark the
memory as such.  Consequently, data cannot be executed.  Furthermore,
although data can be overwritten by the user, hardware bounds checking in
conjunction with memory bounds markers prevents writing outside the bounds
of data owned by the user.  Usually this is a fatal error terminating the
process.  The fatal error can be suppressed so that the process continues,
but the process still cannot write into data areas not owned by itself or
into code areas.  To a certain extent, these mechanisms also serve to
protect the user from himself.

Of course, the MCP (OS) can overcome these limitations through the use of
special constructs in the language (NEWP) in which the OS is written, as can
other processes written in NEWP and granted privileged abilities.

It is also worth noting that only high-level languages are used for
programming: there is no assembler or machine code programming (not even for
the MCP, although some NEWP constructs are very close to machine code).

Re: Buffer overflows and Multics

<Michael LeVine <>>
Thu, 26 Feb 2004 09:01:59 -0800

IIRC the late VAX/VMS systems also had built in buffer overflow prevention
features, probably a lesson learned from Multics. The hardware had
protections that could be set on memory segments to be: Execute/No execute
and read only/write only/read-write, and the OS system calls requiring
buffers also had to have the length of the buffers specified.

MS Java Virtual machine

<"Karnow, Curtis E A." <>>
Thu, 26 Feb 2004 08:24:14 -0800

Issues associated with the MSJVM have been the subject of legal proceedings
between Sun and Microsoft. Further information on the transition can be
reached at

Garage-Door openers; Rapid disassembly of PCS phones" (R 23 20)

<"Charles Jackson" <>>
Thu, 26 Feb 2004 08:36:00 -0500

* Regarding garage-door openers:

Early garage door openers were quite simple.  IIRC, some of them were no
more than a sequence of Antenna, Bandpass filter, Energy detector.

They operated at low powers in bands shared with other operations.  Thus,
false triggering of the garage door opener would not be uncommon.  Steve
Bellovin's calculations are correct.  No way Sputnik could be exacted to
trigger a garage door opener.  In contrast, a 707 flying 1,000 feet above
such a garage door opener could easily trigger it.

Modern garage door openers use modulated sequences-i.e. a string of 1s and
0s-to carry commands.  False triggering by other systems, such as land
mobile or aircraft transmitters, is thus highly unlikely.

* Regarding exploding batteries in cellular phones:

This is not an urban legend.  It has been widely reported.  I recently
received a letter, dated 9 Feb 2004, from legal counsel for the manufacturer
of the wireless phone that I use.  Some quotes from that letter:

  "an allotment of batteries ... Might contain a risk hazard."
  "the root cause was a quality-control issue at the battery manufacturer"
  "Of the 50,731 units shipped in the United States ... four(4) confirmed
  reports of rapid disassembly.  Of these four (4) reports, one involved
  personal injury in the form of a second-degree burn . . "
  Continued use of the phone ... could result in injury due to ... rapid
  disassembly (which may appear as an explosion) ... "

The risks of this lawyer weasel wording are obvious.  While engineers may
immediately recognize the hazards associated with "rapid disassembly" the
everyday user may not.  Only later in the letter does the more familiar term
"explosion" appear.

Re: Garage-door openers (Ladkin, RISKS-23.20)

<"Michael Kent" <>>
Thu, 26 Feb 2004 20:03:44 -0000

I had a similar experience recently and reading this prompted me to check
something I thought I remembered reading.

In late 2002 the Shell company was under fire for having hidden mobile phone
masts in the forecourt signs of 210 of its 1,100 UK petrol stations.

The criticism was directed at the perceived health risks associated with
these masts -- a much discussed subject in it's own right.  I have been
involved in the approval process for locating a transmitter close to gas
storage tank, and most risks are calculated objectively.  Substance stored,
loading and dispensing methods, transmitter power, distances etc are all
taken in to account.

I am somewhat bemused that the urban myth of the dangers of using mobile
phones in petrol stations is still being spread by the companies who own

Re: Garage-door openings by aircraft (Re: RISKS-23.19)

<Scott Peterson <>>
Thu, 26 Feb 2004 09:12:17 -0800

A true story that can be found in the *LA Times* archives discusses problems
back in the 1980's when Reagan was president.  When he was staying at his
ranch in California, Air Force One would be parked at a local Air Force base
near Riverside California. Whenever that plane was there, everyone for
several miles around would know because their garage door openers would stop

As soon as the plane left, they'd be working again.  The Secret Service
would not comment.

  [This was noted in my ACM SIGSOFT Software Engineering Notes vol 11 no 2,
  April 1985, issue, four months before the first issue of RISKS.  Most of
  the relevant pre-RISKS cases are indexed in my Illustrative Risks doc:
  (with .pdf and .ps for printing rather than browsing).  PGN]

Further misdirected on-line trip planning (RISKS-23.20)

<"R.S. (Bob) Heuman, Toronto, ON, Canada" <>>
Thu, 26 Feb 2004 12:47:54 -0500

Try to plan a trip from Calais, Maine to Sault Ste Marie, Michigan, using
the DeLorme mapping product, or a trip from Niagara Falls, New York to
Detroit, Michigan.  Look at the results and be prepared to spend extra time
or days on the road.  The same thing happens if you are trying to travel to
anywhere where traveling through Canada is substantially shorter than
traveling through the US.

The reason? Delorme leaves Canada out of their product totally! To go from
upper Michigan to upper Maine you go south of the Great Lakes if using their
product but north of the Great Lakes if trying for a rational trip.

If you ask Delorme, who are located in Maine, they shrug their shoulders and
say that those who really care about that minor problem know to use other
sources of information... [I.E. They don't seem to care.]

For what it worth, the risks are not only online...

Amtrak Website routing

<"Richard S. Russell" <>>
Thu, 26 Feb 2004 09:42:27 -0600

In Risks 23.20, Mike Brandt <> was quoted as writing: "In
the early days of Amtrak's online trip planner, I asked it about trains from
Portland (Oregon) to Seattle. There are several trains each day that make
this 3.5 hour trip. The first choice on the route planner's list was
Portland -> Chicago -> LA -> Seattle taking about a week, and passing
through Portland again 3.5 hours before arriving in Seattle."

Has the problem been fixed? You be the judge. I live in Madison, Wisconsin,
about 1/3 of the way across the North American continent. My sister lives in
Denver, Colorado, about 2/3 of the way across. Amtrak's recommended route
for getting from here to there had me going via Minneapolis to Seattle
(apparently a magnet for Amtrak customers), then to San Francisco, then
backtracking to Denver -- about 4 times as long a trip as necessary once you
add the extraneous north-south travel to the extraneous east-west travel. My
solution was to take a bus to Chicago and catch the direct train to Denver
from there. I was bemused to notice, however, that the westbound train to
Denver was scheduled to leave Chicago half an hour BEFORE the eastbound one
arrived from Minneapolis and Madison, so Amtrak was apparently trying to
spare me a 23.5-hour layover in the Windy City. Good theory; bad

Solution: More frequent passenger trains. I continue to be frustrated that
Congress insists that Amtrak must be 100% self-supporting while it lavishes
billions of dollars in subsidies on its competitors -- highway builders;
air-traffic control, National Weather Service, and airline bail-outs; and
even the Army Corps of Engineers to keep the nation's locks, dams, and
coastal waterways open to barge and riverboat traffic.  The game is rigged,
and once again the victims are being blamed for the system's failures.

Richard S. Russell, a Bright (, 2642 Kendall Ave
Madison WI 53705-3736 608+233-5640

REVIEW: "Developing Secure Distributed Systems with CORBA",

<Rob Slade <>>
Thu, 26 Feb 2004 08:32:07 -0800
  Ulrich Lang/Rudolf Schreiner

BKDSDSCO.RVW   20031201

"Developing Secure Distributed Systems with CORBA", Ulrich Lang/Rudolf
Schreiner, 2002, 1-58053-295-0, U$69.00/C$106.95
%A   Ulrich Lang
%A   Rudolf Schreiner
%C   685 Canton St., Norwood, MA   02062
%D   2002
%G   1-58053-295-0
%I   Artech House/Horizon
%O   U$69.00/C$106.95 617-769-9750 800-225-9977 fax: +1-617-769-6334
%P   308 p.
%T   "Developing Secure Distributed Systems with CORBA"

Chapter one is an introduction, but it very quickly gets into CORBA
(Common Object Request Broker Architecture) jargon, and C++ API calls.
The explanations could be written with more clarity for outsiders.
Security is first defined, in chapter two, in terms of restricting
access, but the authors are not clear about whether they are primarily
concerned with integrity or confidentiality.  The material then goes
on to a good overview of security management basics and a very brief
outline of some security concerns in the CORBA environment.  The lead-
in to the CORBA security architecture, in chapter three, is a lengthy
discussion of the benefits of flexibility, abstraction, and
simplicity: the authors then note that the CORBA architecture is not
simple.  MICO, an open source CORBA compliant object request broker,
has a security component (MICOsec), and chapter four is dedicated
mostly to installation instructions.  Chapter five looks at
programming CORBA level one security, using MICOsec and C++, while
chapter six takes a longer look at the more complex level two
requirements.  CORBA security does have support for applications that
do not contain any security provisions (a rather interesting concept),
and these are reviewed in chapter seven.

CORBA security is not widely understood, and this work can assist both those
needing a conceptual idea of the system and those needing to program with

copyright Robert M. Slade, 2003   BKDSDSCO.RVW   20031201    or

Please report problems with the web pages to the maintainer