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 20

Weds 25 February 2004

Contents

King/Drew patient monitors shut off following 2 deaths
Sheri Alpert
Bug in Windows-operated toilet system
Wendy M. Grossman
Physical security of electronic voting terminals
Tobin Fricke
Chipmakers race to plug the buffer overflow problem
NewsScan
Buffer overflows and Multics?
Tom Van Vleck
An old filtering problem, but worth repeating
Drew Dean
Anti-captcha technique
Lindsay Marshall
Further misdirected on-line trip planning
Mark Brader
Conspiracy Theory: mortgage scams
NewsScan
Osama Bin Laden is not on the no-fly list?
Peter Wayner
MS Java Virtual Machine issue
Ferdinand John Reinke
Garage-door openings by aircraft
John Slimick
Kevin G. Rhoads
Re: Garage-door openers
Peter B. Ladkin
Re: Garage-door openers by Sputnik
Steve Bellovin
Re: Drunk unlocks police car with own key
Adam Laurie
Info on RISKS (comp.risks)

King/Drew patient monitors shut off following 2 deaths

<Sheri Alpert <salpert@nd.edu>>
Thu, 11 Sep 2003 21:39:00 -0500 (EST)

On 10 Sep 2003, Tracy Weber and Charles Ornstein reported in the *Los
Angeles Times* that the Martin Luther King Jr./Drew Medical Center was
disconnecting a new $411,000 patient-monitoring system, after the deaths of
two patients for whom alarms failed to alert nurses that urgent attention
was needed in the summer of 2003.  [PGN-ed]
  http://www.latimes.com/news/local/la-me-kingdrew10sep10,1,3521718.story


Bug in Windows-operated toilet system

<"Wendy M. Grossman" <wendyg@pelicancrossing.net>>
Sat, 21 Feb 2004 11:01:12 +0000

I was at a press conference on Thursday with PalmSource at One Aldwych,
which is one of those hyper-modern London hotels.  One of its features is a
airplane-style vacuum-operated toilet system.  One of the Palm execs told me
that while they were staying at the hotel this system failed, and any time
they wanted to use the bathroom or take a shower they had to call the
reception desk and get escorted to the corporate headquarters in the
building next door to use the facilities there.  For a couple of *days*.

It transpires that the entire plumbing system is run by a Windows-based
computer system and whatever went wrong with it was so obscure that they had
to get a technician from the company that supplied it on a plane down from
Scotland to fix it and reboot.

The Blue Screen of Sewage?

  [There's a "Sucker" Borne Every Evacuation!  PGN]


Physical security of electronic voting terminals

<Tobin Fricke <tobin@csua.berkeley.edu>>
Wed, 25 Feb 2004 14:32:17 -0800

A cart of Diebold electronic voting machines was delivered today to the
common room of this Berkeley, CA boarding house, which will be a polling
place on Tuesday's primary election.  The machines are on a cart which is
wrapped in plastic wrap (the same as the stuff we use in the kitchen). A few
cable locks (bicycle locks, it seems) provide the appearance of physical
security, but they aren't threaded through each machine. Moreover, someone
fiddling with the cable locks, I am told, announced after less than a minute
of fiddling that he had found the three-digit combination to be the same
small integer repeated three times.

One wonders whether paper ballots would be handled differently, how the
terminals are stored between elections, what checks are done for tampering
before the use of the terminals, and what physical security features are
built into them.


Chipmakers race to plug the buffer overflow problem

<"NewsScan" <newsscan@newsscan.com>>
Mon, 23 Feb 2004 08:56:20 -0700

The next generation of microprocessors will plug the gaps that have resulted
in "buffer overflow" vulnerabilities, causing Microsoft to issue repeated
"critical security alerts." The buffer section of computer memory stores a
finite amount of data. To exploit the flaw, hackers cause more data to be
sent to the buffer than it can hold, forcing it to overflow into the next
chunk of buffer memory, where they then deposit their malicious code. This
leaves the computer open to attack, as demonstrated by the devastating
Slammer and Blaster worm invasions in 2003. "Buffer overflows are the
largest class of software vulnerabilities that lead to security flaws," says
the head of one security company. The new chips will be designed to block
this avenue of attack, although security experts predict that determined
hackers will find other ways to insert computer viruses -- for example, by
making a program jump to a subsection of its own code at the wrong time,
perhaps to open a data port to a hacker.  [*New Scientist*, 22 Feb 2004;
NewsScan Daily, 23 Feb 2004]
  http://www.newscientist.com/news/news.jsp?id=ns99994696

  [Historical reminder: In 1965, the Multics hardware (GE then Honeywell
  645) provided segmented, paged, ring-structured hardware enabled the
  software to achieved measures of security that are not common today.  The
  combination of hardware, the PL/I language subset, the language runtime
  environment, the stack discipline (non-executable, which cut way down on
  overflows; also, the stack grew to higher addresses, making the overflow
  of a buffer unlikely to clobber the return address in the stack frame),
  and good software engineering discipline helped prevent most buffer
  overflows in Multics.  See Tom Van Vleck's subsequent message, as well as
  his Web site, multicians.org.  PGN]


Buffer overflows and Multics?

<Tom Van Vleck <thvv@multicians.org>>
Mon, 23 Feb 2004 16:23:45 -0500

To make a big deal out of providing the 40-year-old feature of marking a
region of memory non executable is kind of sad.  Multicians look at each
other and make the rubbing-sticks-together gesture.

It seems to me that the marketing guys and the popular press writers don't
understand the feature, the need for the feature, or what the feature will
and won't accomplish.

It's not magic.  It fixes some common problems, leaving other problems
untouched.  It's not a substitute for defensive coding and proper management
of storage; all it means is that if there is a mistake, it is more work for
an attacker to exploit it.

As Paul Karger points out, when attackers are frustrated by one measure,
they don't abandon their attacks.  They keep looking for other holes.  A fix
like this, applied by itself, will lead to a new equilibrium between
attackers and defenders, maybe favoring one or the other, but the game will
remain the same.

Closing one open barn door is good, but it needs to be complemented by a
systematic approach to enumeration of openings, and a method of closing the
openings by architectural design that applies to all openings.  So I was
taught by my leaders on the Multics project, including Corby, Bob Morris,
Jerry Saltzer, Ted Glaser, PGN, and many more.


An old filtering problem, but worth repeating

<Drew Dean <ddean@csl.sri.com>>
Tue, 24 Feb 2004 12:13:49 -0800 (PST)

Mike Cassidy has a column in the *San Jose Mercury News* on 24 Feb 2004
entitled "Sending e-mail can be a struggle if your name has a 4-letter
word."  A Scottish gentleman named Craig C*ckburn (generally pronounced
Coburn) had all too difficult a time receiving his e-mail.  It turns out
that Mr. C*ckburn's job title is "senior IT application speci*list", which
also has problems due to the word "speci*list" containing the substring
"ci*lis" (when used as a proper noun, a Vi*gra competitor).

Not new, but increasingly painful for many people.

  http://www.mercurynews.com/mld/mercurynews/business/8026783.htm

Drew Dean, SRI International

PS: How many spam filters will barf on this message?  Or will PGN edit it?

  [Indeed.  I took mercy on Drew's message and have tried to avoid
  the expected filters.  Note other words such as "multiraci*alism",
  "soci*lism", "commerci*lism", and even "commerci*lise" (British),
  also get trashed, not to mention words in other languages.
  (The asterisks above are easily interpreted as the letter "o" or "a".)
  *@#$%*!  <expletive deleted>  PGN]


Anti-captcha technique

<"Lindsay Marshall" <Lindsay.Marshall@newcastle.ac.uk>>
Fri, 20 Feb 2004 13:26:37 -0000

I don't remember seeing a posting about the suggested anti-captcha technique
that was discussed recently on slashdot. A "captcha" is the (horrible) name
used to describe the distorted graphics referred to by Thomas Harrington in
RISKS-23.29. The (completely brilliant) idea is that every time spammers
have to deal with such an image they bring it up on the screen of someone
who is looking for free porn and pretend that they are doing a check. The
user will respond and the answer gets forwarded back up the line. The
/. discussion is at
http://yro.slashdot.org/article.pl?sid=04/01/28/1344207&mode=flat,
the original Boing-Boing posting is at
http://boingboing.net/2004_01_01_archive.html#107525288693964966

Very hard to beat human ingenuity.


Further misdirected on-line trip planning

<msb@vex.net (Mark Brader)>
Mon, 23 Feb 2004 13:49:09 -0500 (EST)

[Adapted from alt.fan.cecil-adams (by PGN, who adds that Mark contributed
two similar items to RISKS-20.62, with a follow-up by Chris Smith in
RISKS-20.63)]

Phil Jern" <pjern1@comcast.net>:
  Somewhere around here I have driving directions that I printed out a few
  years ago that showed 4,900-odd miles for a trip from New Jersey to Atlanta
  that included 2 borders crossings in and out of Canada.

Bill Kinkaid <billkinkaid@telus.net>
  The transit system here has a trip planner feature on their Web site
  (translink.bc.ca). You key in where you want to start, where you want
  to wind up and when, and it tells you which buses to take and when to
  get them. A few times in off-hour periods (say Sunday morning) it's
  given me some very bizarre routings where I can look at the map and
  say "I get on this bus here and get off it there, just tell me when".
  Telling me to go from Marpole to Coquitlam via South Delta and Surrey
  Centre, f'rinstance.

Mike Brandt <MyLastName@syr.edu>
  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.


Conspiracy Theory: mortgage scams

<"NewsScan" <newsscan@newsscan.com>>
Thu, 19 Feb 2004 09:19:51 -0700

Lawsuits filed yesterday by AOL and Earthlink accuse individuals and
companies of running spam networks. The AOL suit alleges a conspiracy
between three Floridians and two Americans living in Thailand to route
mortgage-scam solicitations to AOL customers and to defeat AOL's spam
filters through a company called Connor-Miller Software Inc. Earthlink is
accusing 16 individuals and companies in Florida, California, Tennessee and
Michigan of operating a multi-state spam operation that has sent more than a
quarter of a billion e-mail messages promoting herbal supplements,  Vi*gra
and adult dating services and of using stolen identity documents to open
Earthlink Internet accounts that were used to transmit the spam. The
attorney who represents the Florida defendants in the AOL lawsuit argues
that his clients are innocent of spamming: "They set up a network, just like
AOL is a network."  [*The Washington Post*, 18 Feb 2004; NewsScan Daily, 19
Feb 2004]
http://www.washingtonpost.com/wp-dyn/articles/A52951-2004Feb18.html


Osama Bin Laden is not on the no-fly list?

<Peter Wayner <pcw@flyzone.com>>
Fri, 20 Feb 2004 07:44:05 -0500

"According to airline-security documents obtained by this magazine, the name
Osama bin Laden was punched into the computer by an airline official and,
remarkably, that name was cleared at the security checkpoint all passengers
must pass through before being issued a boarding pass. "
  http://www.wnd.com/news/article.asp?ARTICLE_ID=37167

  Seems like a very general RISK. Some Turing machines just don't halt if
  they don't find the right name.


MS Java Virtual Machine issue

<"Reinke @ A" <Reinke@att.net>>
Mon, 23 Feb 2004 11:21:22 -0500

Are you familiar with the MS Java Virtual Machine (MSJVM) issue?  After
September 30th 2004, Microsoft will no longer be able to support this
technology.  As a result, customers who have the MSJVM installed after this
date will be vulnerable to potential attacks that will attempt to exploit
this technology. This problem is compounded by the fact that Microsoft will
no longer be able to provide software updates or patches to the MSJVM. This
issue is not just a concern for organizations that use Java, but will also
impact anyone who has the MSJVM installed. More alarming, many organizations
aren't even aware that they have MSJVM installed.   [...]

Ferdinand John Reinke, Consultant, 3 Tyne Court, Kendall Park, NJ 08824


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

<John Slimick <slimick@pitt.edu>>
Wed, 18 Feb 2004 22:14:26 -0500 (EST)

Sometime in the late Sixties when my wife and I were living on Arbor Road in
Menlo Park (not far from SRI), I was standing outside close to my landlord's
garage when a lumbering four-engine jet liner passed overhead, possibly a
little lower than usual. As it passed overhead, the garage door began to
open (it had one of the earlier remote openers). After the plane passed, I
went over and closed the door.

When I asked about it to other, more knowledgeable people, I was told that
the aircraft transponder was the culprit, and the phenomenon was not unknown
in the Bay area.


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

<"Kevin G. Rhoads" <Kevin.Rhoads@Dartmouth.EDU>>
Mon, 23 Feb 2004 11:04:18 -0500

We had a house with a 1970-ish vintage garage door opener.  Many of these
used frequencies that were "shared" with certain aviation uses.

Whenever our house was in the approach path to Boston/Logan the door would
get triggered easily two to three times a day.  When the jets were not being
approach-routed over us, it rarely happened -- only once that I remember.  I
simply disabled the remote receiver.

Using a single frequency with no keying as a trigger is like using a one-pin
lock, or a 1 character password.

I don't think that needs any further explanation in the RISKs forum.


Re: Garage-door openers (RISKS-23.19)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Thu, 19 Feb 2004 08:41:01 +0100

Cases of garage doors opening uncommanded through radio-frequency
interference are not urban legends, although I don't know specifically about
Sputnik.

In 1981, I briefly owned a house on Arlington Avenue in Kensington, CA, with
an automatic door. I slept often in the room over the garage. When there was
a storm in the Bay Area, SFO sometimes used Rwy 19 for landings, instead of
the usual 27L/R. The initial approach was radar vectors, and many aircraft
used to fly over the Berkeley Hills. I recall that a number of times when
aircraft flew over in the early morning, I heard the garage door open. (It
piqued both my curiosity and my sense of security, so I remember going to
some effort to figure out possible correlations. The aircraft were the only
one that I recall. Police radios could have been another - the police
station was just up the road and cars used Arlington Avenue all the
time. But I recall ruling that out.)  That was the only time of which I am
aware at which the door opened uncommanded. I don't know when the garage
door was installed. The house was some 20-30 years old then, as I recall.

I didn't know much about avionics at the time, so I didn't confirm it
through technical details.

I seem to recall mentioning something about this in Risks at some point.

An urban legend with which I am directly familiar concerns mobile phones on
gas station forecourts igniting fuel fires. I wrote about it in "An Example
of Everyday Technical Risk Analysis". I analysed the principles on which at
least one authority seemed to base its regulatory stance, and pointed out
that they were very different from a technical risk analysis.  For example,
the UK regulators based their official position on the fact that mobile
phones are RF devices, and there were regulations governing use of RF
devices in the presence of flammable substance, although a correspondent at
HSE suggested that the possibility of external short circuits, caused say
when someone drops a phone while using it, would be a natural concern (I
pointed out that this was precluded by the physical design of phones that I
had looked at).

There is a postscript. My sister reported to me in 2002 that local gas
stations put up notices saying that due to then-recent incidents of phone
use setting off fires, mobile phone use was "not permitted". She asked the
station attendant, and got no precise information. I inquired at the UK
Health and Safety Executive, and Simon Brown told me that the more recent
reports had been investigated and HSE had concluded that there was no
substance to them.

Then, end of 2003, there were reports of "exploding" mobile phones. The New
Scientist was interested (although I do not know what if anything they
published). Nokia had issued a statement about it, in which they said that
some third-party replacement batteries had been shown to be defective. I saw
a German public television program about it. It interviewed a man to whom it
had happened (as his car was passing under the mail Amsterdam-Köln train
line at Dinslaken), showed pictures of his phone, showed his hospital
admittance record (his arm/hand was mildly burnt), interviewed labs who had
investigated such incidents, and showed lab technicians provoking such an
explosion. Pretty substantial stuff, no legend. It can happen.

Apparently, some third-party replacement battery providers do not have
adequate quality control and the short circuit protection mechanisms
on the batteries they sell may be as ineffective as the batteries are
defective. A battery which internally short-circuits can explode in
exactly this way. The program explicitly recommended not using
inexpensive batteries from manufacturers/suppliers that were not well-known
(I recall it stopped short of advising people only to use original
equipment, although some interviewees recommended that.)

Of course, this may happen irrespective of whether the phone is in use, or
even of whether it is switched on, although I imagine both situations raise
the chances that a defective battery will internally short-circuit.  So it
may well be that there are now good grounds for the adage "don't use your
phone on gas station forecourts", but based on the possibility of internal
shorts, rather than on their status as RF devices, or on the possibility of
external shorts. And better to keep it away from the fumes altogether; not
in your pocket or handbag, but in the car with the windows shut. If you have
a non-original battery, that is.

A colleague pointed out that car batteries are in principle susceptible to
the same process, and there are plenty of inexpensive car batteries around,
but no one is recommending or requiring that drivers remove or disconnect
their car batteries before driving on to a forecourt. Of course, if they
did, they couldn't......

Peter B. Ladkin, Professor of Computer Networks and Distributed Systems,
Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany


Re: Garage-door openers by Sputnik (RISKS-23.19)

<Steve Bellovin <smb@research.att.com>>
Thu, 19 Feb 2004 10:06:24 -0500

I flat-out don't believe the sputnik connection -- the signal strength from
orbit would have been extremely low.

I haven't been able to find hard numbers, but here are some back of the
(SMTP?) envelope calculations.

Sputnik's perigee was 215 km (sources given below).  Assume that a garage
door opener's range is 21.5 m; if the satellite has comparable transmission
efficiency and power and an (assumed) inverse square signal drop-off, we're
dealing with a 10^-8 difference in power.

Of course, Sputnik's transmitter was more powerful.  I haven't been able to
find any data on that, but we can bound it.  Sputnik massed 83 kg.  Assume
that its entire mass was batteries -- clearly, that's an overestimate -- and
assume that a vintage 1957 garage door transmitter had 83 grams of battery
(probably too low).  That gives a 10^3 improvement in maximum transmitter
power.  We can be very generous and assume a 10^2 factor for better
batteries, better transmitters, etc., but we're still left with a signal
strength deficit of 10^3.  Sure, Sputnik had better antennas than the garage
door opener, but the receiving antennas are constant.  I don't see how this
adds up.

I should add that battery weight and power capacity was a major concern for
the designers; furthermore, the antennas were omnidirectional.

I may be off-base here, and I'll let people with more knowledge of radio
calculate further -- but to me, this just doesn't add up.

Sources:

http://www.hq.nasa.gov/office/pao/History/sputnik/14.html
http://www.hq.nasa.gov/office/pao/History/sputnik/russ3.html
http://nssdc.gsfc.nasa.gov/database/MasterCatalog?sc=1957-001B
http://nssdc.gsfc.nasa.gov/nmc/tmp/1957-001B-traj.html

Steve Bellovin, http://www.research.att.com/~smb


Re: Drunk unlocks police car with own key

<Adam Laurie <adam@algroup.co.uk>>
Fri, 06 Feb 2004 14:41:23 +0000

I have had a couple of experiences with radio car remotes and have also
recently been doing some research with older style IR remotes...

Firstly, the radio remotes... on a recent business trip i got a call from my
wife in which she described a situation when she got locked out of her car
as the radio remote had stopped working. she could unlock the door with the
physical key, but the remote had also disabled the ignition system so she
could not start the car. she was at a shopping centre, it was early evening,
getting dark, and she had 4 children (not all mine, i should point out! :)
she had just picked up from school and was desperate to get home... when she
called the garage they said it would take two hours to get out to
her. clearly this was unacceptable in the circumstances, so they came up
with another solution... the solution was to tell her the procedure for
resetting the key. having reset the key, she then followed another procedure
to resychronise the car. she did this and it all worked fine. when she
described the procedure to me, it was clear that the process was completely
insecure as it did not require physical access to the car (i.e. no ignition
key or door key sequence was required). as it happened, a few days later, a
friend was giving me a lift to the railway station and on the way he had to
drop off a rental car. as we left it on the forecourt (it was late and the
place was closed), i noticed he was using an identical remote to the one for
my wife's car. i had mine with me so we decided to experiment... and yes,
you are probably way ahead of me here... after performing the sequence, a
dozen or so cars on the forecourt happily chunked their locks open and
flashed their indicators to show that they had been reset! it would appear
that sending a 'base' code from a freshly reset key caused the receivers on
the cars to also reset and synchronise to my key. i didn't try starting any
of them, as ThatWouldBeBad(tm), but being able to open the doors is risky
enough.

This caused me to wonder just how simple those codes were, and how hard they
would be to brute force. not being an electronics/radio whizz, i was
slightly stumped on how to intercept and analyse the signals, so i decided
to first have a go at something simpler, for which such tools already
existed, and which i suspect uses similar underlying protocols - i.e. infra
red. the tool i used was LIRC (http://www.lirc.org/), which includes a nice
graphical utility to show you the 'shape' of the signal.  zapping it with my
garage door opener showed that they were using an 8 bit code (plus stop bits
etc.), and the particular code for my garage door was 0xE3. lirc also has a
learn facility, which produces config files in human readable form. the
config for my learned remote looked like this:

   begin codes

        E3	0x00000000000000e3

it was then a simple task to write a script which spat out the other 255
possible codes:

        00       0x0000000000000000
        01       0x0000000000000001
        02       0x0000000000000002
        etc.

and another simple script to send every possible code. running the script
successfully popped the garage door not only when it hit the expected 'e3'
code, but also on another one (apparently the garage operators had installed
a second parallel system as they could no longer get spare remotes for the
old one). total time to try every code was under a minute.

i have since used the same technique to discover 'hidden' menus on TVs
(particularly useful in hotels with pay per view :), and suspect that there
are lots of other similar applications out there waiting to be discovered...

the risk here is that because the code is 'invisible' there is a tendency to
make it simple. i have seen the same mistake in network connected security
devices such as proximity card readers for door controls - the card itself
is secure, but the command that ultimately gets sent over the wire to the
locking mechanism is a simple ascii string, such as "O" for open.

btw, if anyone has any ideas how i could convert the radio remote
signals to something i could analyse/replicate, please get in touch... i
have scanners/transceivers etc., but am completely clueless when it
comes to non digital stuff... :P

Adam Laurie, A.L. Digital Ltd., The Stores, 2 Bath Road, London W4 1LT  UK
+44 (20) 8742 0755  http://www.thebunker.net  http://www.aldigital.co.uk

Please report problems with the web pages to the maintainer

Top