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 20 Issue 51

Monday 2 August 1999

Contents

o Critical Infrastructure Protection: Japanese toilets
Carl Landwehr
o "Heat wave"
Steve Summit
o Risks of on-line auctions: eBay scam
PGN
o Conversion service for viewable formats
Lindsay Marshall
o 2nd-class invitation in Outlook
Thomas Gilg
o Re: Computer-based patient monitor problems
William Hutchens
o Re: One year in jail: Fear in the skies
Bob Frankston
o Re: ActiveX security
Peter da Silva
Adam Shostack
o Are you sure your host isn't being mail-blocked?
Thomas Roessler
o More on small problem escalates into major disruption
Doug Moore
o New version of an old scam
Mike Ellims
o Equivalence of logical and physical behavior...
James S Dukelow Jr
o Re: Cancelling errors, serendipity in avoiding risks, and Kepler
Jim Thompson
Felix Tilley
o Go FORTH and Multiply
Patrick E Kane
o Announcing Dependability.org
Chuck Weinstock
o REVIEW: "Internet Security with Windows NT", Mark Joseph Edwards
Rob Slade
o The Software Engineering Symposium '99
Carol Biesecker
o Info on RISKS (comp.risks)

Critical Infrastructure Protection: Japanese toilets

Carl Landwehr <carl.landwehr@mitretek.org>
Fri, 30 Jul 1999 08:48:32 -0400
NPR's Morning Edition had a brief story this morning on high-tech Japanese
toilets that include functions such as auto seat raise, warm rinse, and
hot-air blow dry.  Some of these have recently been implicated as a source
of fires in houses.

Reporter to woman shopping for toilet:
  "Are you concerned about the possibility of fires?"

Woman (as translated):
  "No toilet is 100% safe. I am willing to accept some risk."

Carl Landwehr, Mitretek Systems

  [Does this give new meaning to "going down in flames"?  It also
  links the "Royal Flush" brand name with a red-hot poker player.  PGN]


"Heat wave"

Steve Summit <scs@eskimo.com>
Thu, 29 Jul 1999 07:24:22 -0700 (PDT)
I had a report (which I've been unable to confirm, despite the time I've
spent waiting) that during the heat wave in the northeastern U.S. earlier in
July, a "weather" command on some computer at MIT produced the following
curious output:

    athena% weather bos
    Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT)
       Weather: Partly Cloudy
          Temp: 2147483647 F (2147483647 C)
    Visibility: 10 mi
     Barometer: 29.72 inHg
          Wind: NE 13 mph

Needless to say, the particular temperature value shown is intriguing to the
computer nerds among us!  Steve Summit <scs@eskimo.com>

  [Yup, it is 2**31 - 1.  PGN]


Risks of on-line auctions: eBay scam

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 28 Jul 99 10:28:25 PDT
eBay users have apparently been victimized by a nasty denial-of-service-like
scam: Someone makes an early relatively low bid, then a totally out-of-line
high bid (which discourages all other bidders), and then withdraws the high
bid at the very last minute -- which is allowed by eBay.  This is known as
bid shielding.  See a Website created by Jason Hamilton
http://mars.superlink.net/jason/ebay/ who was one of the victims.


Conversion service for viewable formats

<Lindsay.Marshall@newcastle.ac.uk>
Wed, 28 Jul 1999 09:57:41 +0100 (GMT)
<http://TOM.cs.cmu.edu/intro.html>

This site offers a service for converting different kinds of documents into
"viewable formats". it not only does Web-accessible documents, but also
files that it will import using the form protocol for files.  Imagine the
potential for stealing information that this service opens up!

http://catless.ncl.ac.uk/Lindsay

  [But, security by obscurity does not work too well for strange formats.
  PGN]


2nd-class invitation in Outlook

<Thomas_Gilg@ex.cv.hp.com>
Fri, 23 Jul 1999 15:32:18 -0700
One of our engineers has decided to leave and go back to school to complete
her Ph.D. and enter teaching, a career move we all wish her the best in.
Before a going-away party could be scheduled however, she ended up in an
unusually contentious software design meeting with four other
momentarily-combative engineers, including myself.  It was ugly!

As I pondered whether or not I was out of line during the meeting, and how
we could reconcile our differences so she could leave on a high note, our
administrative assistant used Microsoft's Outlook/Exchange "meeting request"
feature to schedule a lab-wide going away party.  Unlike most engineers in
the lab, I and one of the other combative engineers quickly hit the "accept"
button which converts the e-mail based meeting request into a calendar item
and sends a RSVP back to the meeting organizer.

A day later, an update was issued on the same meeting request, and I scanned
the request for the change.  While the lab-wide mail list alias "Lab.All"
was still on the "Required Attendance" line, I and one other combative
engineer were now explicitly listed, by name, on the "Optional Attendance"
line.  My heart sunk at the thought that some of us were no longer welcome
at her going away party.  Good friends for so long, how could one lousy
meeting drive us apart?

After some tactful asking around though, it became clear that there were no
hard feelings and no one had tagged anyone as optional.  Ah, enter another
Microsoft Outlook/Exchange feature.

If a meeting request is sent to a mail list alias, and then individuals
accept the request *and* use the option to e-mail back a yes/no response to
the meeting organizer, Outlook/Exchange does not recognize that the
individual(s) are part of the original mail list alias.  If an update is
then issued on the same meeting request, Outlook/Exchange treats the
unrecognized names as optional attendees.

Depending on the issue at hand, being explicitly listed as "optional" can
take on a whole lot of extra meaning.  Who needs enemies when you have
Outlook/Exchange ;-)

Thomas Gilg, R&D Software Engineer, Hewlett-Packard  tomg@cv.hp.com


Re: Computer-based patient monitor problems (RISKS-20.49)

William Hutchens <wthutchens@spamlessmindspring.com>
Sat, 24 Jul 1999 01:53:38 GMT
As someone who plans to practice critical care medicine in the future, I
read Dr. Doyle's posting in RISKS-20.49 with interest.  Although my clinical
experience in considerably shorter (currently a senior Internal Medicine
resident), I've noticed a number of incidents similar to that described by
Dr. Doyle.  Along the same lines, but more insidious, is the possibility of
misinterpreting data because the computer processes the data in a manner
different than one would expect.

Case in point: Among the data that ventilators give regarding a patient's
status are two values related to how much air the patient is moving.  One is
the tidal volume (the amount of air moved in a single breath) and the other
is the minute volume (the amount of air moved over the course of one
minute).  It's very easy to assume that the numbers being reported by the
machine are the actual tidal volume (air moved in the last breath) and the
actual minute volume (true amount of air moved over the preceding minute).

I've noticed that, at least on the ventilators used at my hospital, that
this is not the case.  Whenever we have an irregularly breathing patient,
the reported minute volume changes very rapidly.  Although I haven't been
able to get a copy of the ventilator's manual to confirm my suspicions, it
seems that the value reported as the minute volume is a calculated value
based on the respiratory rate and the patient's last tidal volume.

The risk here is that someone might not realize this.  In an irregularly
breathing patient, a doctor, nurse, or respiratory therapist might take a
quick peek at the minute volume, assuming that the value reflects that
patient's status over the entire last minute (i.e. an average of an entire
fast-slow cycle) instead of being a snapshot taken at a brief moment of
time.

Also, in order to interpret the blood gases (a measurement of the pH, oxygen
tension and carbon dioxide tension -- used to decide if any changes need to
be made in the ventilator settings) of a vented patient properly, one should
take into account the minute volume that the patient has at the time the
sample is drawn.  Our laboratory computer allows the resp. therapist to
enter the vent settings and minute volume along with the blood gas result so
that they appear in the lab report.  The person drawing the blood sample has
to report something to the lab regarding the minute volume and this is
usually whatever he sees on the readout at the time he draws the gas.  The
risk here is that someone reviewing the medical record might see the
spurious minute volume value and conclude that the clinician made an
erroneous decision regarding the blood gas values when, in fact, his actions
were correct.

For the record, the ventilator in question is a Siemens Servo 900C.  My
hospital also used the more advanced Servo 300 model, and I've noticed the
same behavior in that model as well.  (Anyone want to comment on the risks
of designating a more advanced model with a lower model number?)(


Re: One year in jail: Fear in the skies (PGN, RISKS-20.50)

"Bob Frankston" <BobRisks@Bobf.Frankston.com>
Thu, 22 Jul 1999 23:32:06 -0400
Re: (http://www.zdnet.com/zdnn/stories/news/0,4586,2298512,00.html)

The article on the jailing of a cell phone user in the UK continued with
"`The scientific evidence showed that there was a real possibility of risk,'
Ensor said". Of course, no references were given in the story. But they
aren't necessary because we know that cell phones are immoral and dangerous
and cause cancer. It reminds me of the moralistic attitude that made it so
difficult to prove that ulcers were caused by bacteria rather than being
punishment for a stressful (immoral) lifestyle.

The real risk of this nonsense is in relieving the airlines for
responsibility for safety. Many people will not turn off their cell phones
because they are too mundane to think about. Why no outrage at the airlines
for such incompetent design? Of course, the real problem will cell phones is
that they confuse the systems on the ground and planes already survive the
lightening and other sources of radio noise.

But what does one expect from a system that provides only punishment for
those who liberalize the rules? And where the issue is the perception of
safety more than the reality.

  [We received lots of e-mail on this topic, most of it suggesting
  that there is still little hard evidence of bad effects.  PGN]


Re: ActiveX security (Smith, RISKS-20.50)

Peter da Silva <peter@abbnm.com>
27 Jul 1999 22:55:29 GMT
I have long argued that the real problem with ActiveX is the inevitable
proliferation of controls with security holes. Once an insecure applet is
distributed, it can never be revoked because the signature is built into the
applet... if you hit a site and it asks you to run an applet provided by
Microsoft, are you going to say "no"?

Richard Smith's article indicates that the problem is much worse than I
expected, and worse than he realises: patches to the applets won't
help... malicious users can simply provide the old insecure versions on
their websites as trojan horses, depending on social engineering to convince
"enough" users to just blithely execute the apps.

No, any code that's automatically downloaded from the net (and that includes
Office documents!) should be run inside a sandbox. For active content,
there's Java. For Word, there's Word Viewer. For vendors who ship
documentation as self-extracting archives and Excel spreadsheets, well, the
best solution is education.

I'm glad that Microsoft has recognised this problem and is providing "HTA"
pages as an alternative to marking applets as trusted. Let them save face,
so long as the problem's fixed, and turn off ActiveX for all other purposes.

Peter da Silva <peter@baileynm.com>


Re: ActiveX security (Smith, RISKS-20.50)

Adam Shostack <adam@netect.com>
Wed, 28 Jul 1999 14:50:21 -0400
Wasn't this the problem with Eudora executing Javascript in e-mail?  It was
(cached) on the hard drive, and thus safe?  The core problem is that
Microsoft is blurring the boundaries between the computer and the web.  The
problems that such blurring creates are subtle, often misunderstood, and
hard to fix.  Richard's proposed solution of HTA applications means that an
attackers needs to get something to cache a file on disk, and something else
to read it.

Or, "Beware of SystemWizards, for they are subtle..."


Are you sure your host isn't being mail-blocked?

Thomas Roessler <roessler@guug.de>
Thu, 22 Jul 1999 20:14:32 +0200
Are you operating a mail server at a university department, with lots of
one-user machines, Unix and whatever, hanging around on your network?  Is
your host being used as a smart host by those end-user machines?  You should
better go to www.imrss.org and check whether your mail relay is listed as an
open relay there.  The probability is high - but I'm sure you haven't been
told that your machine is on the list.

IMRSS is scanning the Internet for open mail relays.  They try to send a
test message through your machine, and look whether it gets back to them.
If that's the case, the IP address from which the message was delivered to
them is considered to be an output funnel of an open relay, and added to
their database of possible spam mail sources.

That database is available via DNS, ready to be used by any modern mail
server software for blocking any mail which gets delivered from the IP
address in question.

The problem: IMRSS is _not_ going to tell _you_.  But they are going to tell
_anyone_ who happens to _ask_ them about _your_ machine.

Obviously, this is bad style (as is the fact that you don't get reasonable
contact information from their web pages, as is the e-mail autoresponse you
get when you try to contact them, and so on).

There are some actual RISKS connected with IMRSS' approach, too.

For instance, you may learn about your outgoing server being listed
with them from your users, whose messages get suddenly bounced from
certain sites.  Not grave, but not the thing you really want.

But worse: IMRSS is actually doing spammers a favor.  Wanna spam through
open mail relays?  Just look out for your favorite university (or internet
provider), and feed the IP addresses used by it to IMRSS.  You'll get a nice
list of open relay candidates, including the workstation in that proferssor
emeritus' office the administrator doesn't really care about. Possibly, you,
the spammer, know about this before the administrator has learned that he
may have a problem.

I checked this for a major German university, and got several dozen relay
output funnels, some of them corresponding to another dozen input funnels.
The administrators have been notified.

Finally, suppose you use IMRSS' database to block e-mail.  Be assured,
they'll have lots of major relays listed there, possibly without these
relays' administrators knowing about this.  Are you really sure that none of
your users or customers is expecting important or critical messages from a
machine IMRSS considers to be a possible spam source?  You better be.
Because _this_ is _your_ RISK.

Web references:

- The initial announcement of IMRSS to the spamtools list:
  http://www.iecc.com/cgi-bin/artget?t19981208011

- IMRSS' home page:
  http://www.imrss.org/


Further follow up - small problem escalates into major disruption

<dougmoore@ibm.net>
Wed, 21 Jul 1999 22:02:45 -0400
In the case of the phone lines that locked up when they could not reach the
emergency 911 number --- when a major 911 system went down near Toronto (see
previous message): That the phones lock up is an intentional feature so that
the 911 operator has a chance to get the information about the calling
number and send help even if the caller is unable to communicate.
Unfortunately, the "lock up" does not time out even if the 911 system
doesn't answer within any reasonable period, and so the phone can't be used
to reach any other number.  At least 24 people's phones are known to have
locked up.  Based on estimates from Peel police, there might have been
another 110 or so calls that did not get through to 911.  About half of
calls to 911 in the area are typically genuine emergencies.

Meanwhile more four days later, Bell has still not restored full service to
the downtown Toronto financial district after a disruption at a switching
centre. (See previous message.)  At least two Toronto Stock Exchange systems
are still down, as are a number banking machines.


New version of an old scam

Mike Ellims <mike.ellims@pitechnology.com>
Mon, 26 Jul 1999 15:08:47 +0100
Mail is doing the rounds in the UK about an Y2K banking scan which goes
something like this:

Someone calls telling you that they represented your bank, and that they
were having difficulty meeting requirements to be computer ready for Year
2000.  They say that all bank customers would need to transfer their
accounts to a bond account, specially designed to protect their money until
the bank can fully comply with the Year 2000 requirements.  To verify they
talking to the proper account holder, you need to confirm some personal
information, i.e. account number, sort code, and verbal authorisation to
transfer funds to into the specially designed account...

You can guess the rest.

Mike Ellims, Pi Technology  mike.ellims@pitechnology.com
www.pitechnology.com   +44 (0)1223 441 434


Equivalence of logical and physical behavior... (Pereira, RISKS-20.48)

"Dukelow, James S Jr" <jim.dukelow@pnl.gov>
Mon, 26 Jul 1999 11:59:23 -0700
> ... is current education in digital circuit design sufficiently attuned to
> the subtleties of the physical world, or do students have an overly
> simplistic view of how bits are represented in hardware? ...

I believe that people who design chips and other circuitry to perform
specific logical computations are generally aware of the need to assess
whether the physical behavior of their circuits actually implements the
logical specifications.  That is one of the basic uses of the public domain
circuit analysis program SPICE and its variants.

That said, the complexity of large chips and the fact that their scale may
be bumping up (down?) against quantum phenomena calls into question whether
the equivalence of their physical behavior and logical specs can truly be
verified.

Pereira is certainly correct about the deterioration of "continuous" math
education.

Jim Dukelow, Pacific Northwest National Laboratory, Richland, WA 99352
jim.dukelow@pnl.gov  [Standard RISKS disclaimers apply.]


Re: Cancelling errors, serendipity in avoiding risks, and Kepler

Jim Thompson <jim.thompson@pobox.com>
Sat, 17 Jul 1999 15:17:15 GMT
In reading Henry Baker's thoughtful article, I am strongly reminded of
something the late Isaac Asimov once said:

    The most exciting phrase to hear in science, the one that heralds
    new discoveries, is not "Eureka!" (I found it!) but "That's funny..."

Asimov's point is similar to Baker's: that discovery is more driven by
the desire to understand mistakes, discrepancies, and other "funnies"
than by pure intellectual will.

Jim Thompson <jim.thompson@pobox.com>


Re: Cancelling errors, serendipity in avoiding risks, and Kepler

Felix Tilley <ftilley@goodnet.com>
Fri, 16 Jul 1999 19:55:49 -0700
A VERY excellent account of Kepler's achievements can be found in Arthur
Koestler's book, the Sleepwalkers.  As I remember, it was published in circa
1959.  It should be in your local library.  I encourage all to read it.  It
is a history of cosmology from the time of the ancient Greeks to Kepler and
Newton.

As a side issue, the Greek who invented the Ptolomeian model of the universe
also wrote a treatise on conic sections!!!!  This is covered in The
Sleepwalkers.  I can't remember his name exactly - it may have been
Apollonarius of somewhere (Perga??).

Felix Tilley in Tucson, Arizona

  [ADDENDUM: Stasinos Konstantopoulos <konstant@let.rug.nl> sent us this:
    Apollonios of Pergamos did indeed write `Conic Sections' in the 3rd
    century. But it is Ptolemeus of Alexandria who should be attributed
    with the atavism of the Ptolemaikon (Ptolemaic? Ptolemeian?) system,
    one century before that.  PGN]


Go FORTH and Multiply

Patrick E Kane <kane@urbana.css.mot.com>
Tue, 27 Jul 1999 20:52:37 -0500 (CDT)
You mean:
    * Forth Go


Announcing Dependability.org

Chuck Weinstock <weinstock@sei.cmu.edu>
Wed, 28 Jul 1999 11:33:19 -0400
Dependability.org has been established by the IEEE CS Technical Committee on
Fault Tolerance and IFIP Working Group 10.4 on Dependable Computing and
Fault Tolerance to be a central source on the Web for information about
dependable systems technology. We hope that you'll visit the site often.

In addition, the IEEE CS Technical Committee has established a mailing list
for distribution of its newsletter. The newsletter is sent out on an
irregular schedule and lists upcoming events and other news of interest to
the dependable systems community. If you would like to subscribe, an easy to
use subscription form is available at http://www.dependability.org/ or you
can send a message to mailto:majordomo@dependability.org with a body that
says: subscribe fttc <your-e-mail-address>

We welcome additional sponsors. If your organization is interested
in sponsorship please contact mailto:weinstock@dependability.org


REVIEW: "Internet Security with Windows NT", Mark Joseph Edwards

Rob Slade <rslade@sprint.ca>
Wed, 28 Jul 1999 09:50:15 -0800
BKINSCNT.RVW   990625

"Internet Security with Windows NT", Mark Joseph Edwards, 1998,
1-882419-62-6, U$49.95
%A   Mark Joseph Edwards mark@ntshop.net mark@ntsecurity.net
%C   221 E. 29th St., Loveland, CO   80538
%D   1998
%G   1-882419-62-6
%I   Duke Communications/29th Street Press
%O   U$49.95 800-621-1544 970-663-4700 fax: 970-667-2321
%O   www.29thstreetpress.com ccarmel@29thstreetpress.com
%P   515 + CD-ROM
%T   "Internet Security with Windows NT"

The introduction states that the book is intended for those with
little or no NT security knowledge, but I suspect that making this the
sole resource for a new system manager would be a dangerous thing,
since it provides the proverbial "little knowledge."

Chapter one gives the user or administrator too much and, at the same time,
not enough background on TCP/IP.  There is a lot of trivia that does not
relate to security, while there is no discussion of, for example, dynamic
re-routing, which would be important in future examinations of IP spoofing.
The grab bag of mostly intrusion related information in chapter two is not
terribly helpful in preparing a defence.  It is not clear to me why this
part is entitled "TCP/IP Essentials."

Part two outlines the basics of the Microsoft Windows security model.  There
is little presentation of a conceptual understanding or framework of the
foundation chapter three, which instead lists a number of terms and
programs.  The "how to" of simple security operations is more comprehensible
in chapter four.

Part three talks about principles of network security.  Chapter five does
not deal with multiprotocol networks, but again lists an assortment of
security concerns.  A number of security threats are described in chapter
six, but not in an organized fashion.  (The virus information, obtained from
the Semantec [sic] Anti-virus Research Center, is basically useless.)  A
number of aspects that should be addressed in a security policy are listed
in chapter seven.  Chapter eight discusses a number of client programs for
NT, but without much security relevance.  A number of attacks are tersely
described in chapter nine.

Part four looks at firewalls.  Chapter ten does a reasonable job of
explaining the different types of firewalls, although it also includes some
unrelated material.  Some considerations for evaluation are given in chapter
eleven.

Part five outlines the Microsoft Proxy Server.  Chapter twelve runs through
dialogue boxes in the Internet Information Server.  The proxy server itself
is described in chapter thirteen.  Design issues are discussed in chapter
fourteen.  Implementation is talked about in chapter fifteen, although there
are a number of areas not completely covered.  Some client considerations
are mentioned in chapter sixteen.  Seventeen looks at troubleshooting and
maintenance.

The book can provide some useful material, although most of the utility
comes from the appendices, listing quick suggestions and resource contacts,
rather than the text itself.  Much of the content is unfocussed and almost
disorganized.  Some topics included are not immediately relevant to security
work, while other areas stop short of actually helping the user or
administrator.

copyright Robert M. Slade, 1999   BKINSCNT.RVW   990625
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


The Software Engineering Symposium '99

Carol Biesecker <cb@SEI.CMU.EDU>
24 Jul 1999 21:20:47 GMT
The Software Engineering Symposium '99
August 30-September 2, 1999
David L. Lawrence Convention Center
Pittsburgh, Pennsylvania
  Theme: Improving the State of Software Engineering:
  Principles, Practices, and Projections

The SEI Software Engineering Symposium provides a forum for discussing
currently applicable practices that software practitioners can use today.
The 1999 Conference on Software Technology and Engineering Practice (STEP
'99) will be held jointly with the SEI Symposium.

The STEP '99 conference is sponsored by the International Workshop on
Computer-Aided Software Engineering, Inc. (IWCASE), an international
association of users, researchers, and developers of software tools, methods,
and technology, and by the IEEE Computer Society.

The Preliminary Program, including Exposition Information, Registration
Information and forms, and Presenter Guidelines, is available on the
SEI Web site at
        http://www.sei.cmu.edu/products/events/symp

Contact:
  Symposium '99 Conference Coordinator
  Software Engineering Institute
  Carnegie Mellon University
  Pittsburgh, PA 15213-3890
  Phone: 412 / 268-3007
  FAX: 412 / 268-5556
  E-mail: symposium@sei.cmu.edu

Please report problems with the web pages to the maintainer

Top