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 1 Issue 29

Thursday, 12 Dec 1985

Contents

oComputer-compared prescriptions
Dave Platt
o SDI: Danny Cohen and Eastport Group comments
Gary Chapman via Jim Horning
o Worms, etc.
Keith F. Lynch
Stavros Macrakis
o Passwords, etc.
King Ables
Dave Curry
Dan Bower

Risks re computer-compared prescriptions

Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Tue, 10 Dec 85 09:50 PST
Random-Quote: The race is not always to the swift, nor the battle to the strong
              -- but that's the way to bet.      (DAMON RUNYON)

Recently, an increasing number of pharmacies have been putting greater
amounts of drug information "on line".  As I understand it, they will keep
track of all of a particular customer's prescriptions, and will alert the
pharmacist if they should be asked to fill a prescription that conflicts
with any other medication that the customer is taking.  The rationale is, I
believe, that if a person is receiving prescriptions from two different
doctors (different specialists, perhaps), then neither of the doctors would
necessarily be aware of the drugs that the other had prescribed, or of any
possible unfortunate interactions between the drugs.  Normally, I assume
that the pharmacist would inform the consumer and contact the prescribing
doctor for further instructions.

Several concerns come to mind:

-  Where is the database of drug conflicts derived from?  Manufacturers'
   data files?  FDA reports?  Articles in recent medical journals?  Just
   how complete is it?

-  Does the database cover only drug-to-drug interactions, or is it more
   complete?  Might it, for example, contain counter-indication information
   for specific drugs (e.g., don't take this if you're pregnant)?  How about
   reports of unusual symptoms or side effects?

-  How "intelligent" (sorry!) is the logic that compares a new prescription
   with a person's medical/drug history?  Is there any AI/expert-system
   capability, or is it simply a look-up-a-list-of-conflicts?  Might the
   code be capable of, for example, warning a person who's receiving
   medication for asthma not to take doses of a specific brand of antibiotic
   because that particular brand is preserved with a sulphite compound that
   has been reported to trigger asthma attacks in sensitive individuals?

-  If a pharmacy advertises their new drug-checking software (and some do
   mention it in their ads), are they assuming any degree of responsibility
   or liability for either (a) false "conflict exists" warnings that cause
   a consumer not to take a necessary drug prescribed for them, or (b)
   any failure to alert a customer to a conflict that does exist?

-  Will doctors, pharmacists, and/or consumers begin to depend on the
   correct functioning systems such as this, at the expense of studying
   the issues involved themselves?

This particular issue is similar to the one discussed several issues back,
concerning AI/KE/expert-system tools such as MYCIN that "diagnose"
illnesses from symptoms or "suggest" treatments.  However, this system
is one step further away from the doctor and closer to the consumer;
there might be a greater tendency for people to "take it at its word"
rather than simply using it as a tool.


SDI: Danny Cohen and Eastport Group comments

Jim Horning <horning@decwrl.DEC.COM >
11 Dec 1985 1340-PST (Wednesday)
              [Forwarded With Permission from Gary Chapman]

Date: Tue, 10 Dec 85 16:14:34 pst
From: Gary Chapman <PARC-CSLI!chapman@SU-Glacier.ARPA>
Subject: Danny Cohen and Eastport group report

COHEN SAYS SDI CRITICS ARE "STAGNANT SUBCULTURE"

Danny Cohen, chairman of the so-called "Eastport group," told the Senate
Armed Services Subcommittee on Strategic and Theater Nuclear Weapons that
the discipline of software engineering is "an institutionalized and stagnant
subculture."  He said that Dave Parnas' criticisms were misrepresenting the
facts by claiming that there are "scientific arguments" and "fundamental
mathematical" obstacles that lead to the conclusion that reliable BM/C3
software cannot be built.

However, Cohen said in his testimony that the so-called "horserace"
architecture studies have only paid "lip service" to potential battle
management problems, and he criticized these studies harshly.

Cohen said that software engineers have a fetish with mathematical
correctness, and that they "try to mimic mathematics at any cost, even if it
means sacrificing functionality and relevance.  This sect grossly overrates
the perfection of Swiss clockwork, and strives to achieve it."  Cohen said
that the SDI should look to the telephone system as a model of a large
system that works well with distributed, autonomous components.  He said,
"The communications approach copes with imperfections and corrects for them,
rather than attempting to achieve an unattainable perfection."

Apparently the example of the telephone system is also featured in the first
chapter of the Eastport group's report to the SDIO.  A December 1 draft of
the report was obtained by the editors of Military Space, and reviewed in
the December 9 issue.  The report's conclusions are summarized in the
observation that computing resources and battle management software "are
within the capabilities of the hardware and software technologies that could
be developed within the next several years...with the tradeoffs necessary to
make the software tractable in the system architecture."

The panel criticized the ten Phase 1 system architecture contractors for
downplaying the problems of battle management software.  The panel
apparently recommends that the SDIO conduct a broader system architecture
study, with an eye toward an "unconventional architecture whose program is
within the anticipated limits of software engineering, without overreliance
on radical software development approaches."

The panel rejects the "tight coordination" implied in the Fletcher
Commission report of 1984.  The panel recommends a loose coordination, with
"robustness, simplicity and the ability to infer the performance of small
parts of the system.  Otherwise, the U.S. could not test a full-scale
deployment short of actual use."

The panel also says in the report that "innovative approaches" are necessary
for managing the software development of the SDI.  The panel report
recommends an independent research and technical support organization to
supervise the program, and a high-speed communications network to support
SDI contractors.

Cohen also told the editors of Military Space that he believes differences
in opinion about the SDI within the computer science community come from
different conceptualizations about the problem.  Cohen said, "Critics like
Parnas take the approach they're traditionally familiar with as software
engineers--a 'waterfall' or 'top-down' approach.  They look at battle
management software as one single, gigantic 'bounded' problem requiring
all-new software--instead of seeing it as a dynamic federation of many
different networks and nodes, much of which may already be out there now.

"The implication of viewing battle management as a federated network--rather
than as a monolithic, rigidly centralized process prone to single-point
software collapse and "Trojan horses'--comes down to this:  the issue is not
software, it's *protocols* between many different networks.  It's
inter-computer or inter-network communications--not single-system software."


Worms, etc.

"Keith F. Lynch" <KFL@MIT-MC.ARPA>
Tue, 10 Dec 85 01:10:21 EST
To: MDAY@MIT-XX.ARPA
cc: RISKS@SRI-CSL.ARPA

    From: Mark S. Day <MDAY@MIT-XX.ARPA>

    The "solitary programmer" mentality is at least partly to blame for
    things like "unauthorized worms" -- if people expect to have their
    code read by others, who may question the reasons for doing certain
    things, it becomes enormously harder to conceal unauthorized features
    (unless the programmer can convince the inspector(s) to join in a
    conspiracy).

  I disagree.  How does one guarantee that the source code shown is in
fact what was compiled?

    I have little or no sympathy for people who illegally copy a program
    and then find one day that it's trashed their data.  Serves 'em right.

  Does the punishment fit the crime?  What if it was some employee who
illegally copied the program, which then destroys irreplacable company
data?  How certain is it that this 'protection' scheme will not go off
by accident?  If it does, who is liable?  Can the company which uses
it simply disclaim all liability?

    From:           Aaron M. Ellison  <BI467000%BROWNVM.BITNET@WISCVM.ARPA>

    Regarding Neal Macklin's "expose" of virus technology, I would only
    add that the idea is not at all new. John Brunner, a well-known
    speculative fiction writer, wrote a novel called "Shockwave Rider"
    over 10 years ago(!) predicting the blackmailing of a then corrupt
    U.S. government by a morally-upright computer hacker. ...

  The idea is older than that.  I don't have any references, but I
recall reading about 'computer viruses' before 1970.
                                ...Keith


`Gary North's Remnant Review' (Worms, etc.)

Stavros Macrakis <macrakis@harvard.HARVARD.EDU >
Tue, 10 Dec 85 18:04:07 EST
This overly-long message appears to say nothing new.  We are treated to some
sort of breathless and misinformed paranoia about `anti-Zionists', Soviets,
and foreigners in general, not to mention hackers.  We get thriller-novel
political scenarios with countless pointless (and hardly verisimilitudinous)
details.  (See below for a textual analysis of North's tract.)

We all know that computer security is hard.  We know that banks and other
important institutions have often failed to apply even the most elementary
security precautions.  We even know about `trapdoors', `worms', and
`viruses' (which were discussed during the design of Multics, if not
earlier).  We also know that both technical people and users of computers
must become more aware of security issues.

What does North contribute?:  a vision of a horrible secret hidden from the
public by frightened bankers whose livelihood depends on hoodwinking the
public into believing that paper money and bank deposits have value -- a
secret which 
-s

Paranoia about the news media:
  I am going public with this story because it is unlikely that any
  conventional news source will touch it, unless pressure is brought
  to bear.  The reason is this: the problems are too horrendous even
  to be discussed by appropriate officials, unless they have specific
  answers.  But they don't.  What I present here cannot be smoothed
  over by a press release abount having set up a blue-ribbon study
  panel.

Stumbling into a terrible secret:
  I literally stumbled into this information.  I had read about one
  tiny aspect of it.  I made a few extrapolations.  Then I got
  worried.  The problem looked as though it would have major
  implications.  Little did I know!

Blatant racism and xenophobia:
  Everyone knows [computer genius types] are either orientals,
  dark-skinned people with accents, or teenagers.  The firms don't
  hire teenagers, but they hire a lot foreigners.

Fortune-telling by `authorities':
  "The great fortunes of the 21st century," [Adam] Osborne predicts,
  "will be the legacies of the great computer thieves of the 20th."

A major source whose qualifications are:
  ... a former businessman, quite young, and a true "space cadet."
  ... a nice fellow, a Christian, and a moral philosopher of sorts.

Phobia of paper money:
  the various banking regulatory agencies would be swamped with crises
  and outside rumors.  Then, all at once, bank computers begin
  breaking down....  The lines appear in front of banks.  The only
  answer at this point is to print up paper money.  It would be
  printed by the hundreds of billions in order to offset the
  deflationary effects of bank runs....

Gold-bug-ism:
  All of a  sudden, market-created alternative  currencies would be
  revived.  It would  the  be  METALLIC  CASH  that  talks  loudest.
  Silver  dimes  are  not electronic.  They can't be infected
  electronically.  They still circulate  when banks are "temporarily
  closed, due to circumstance beyond our control." 

Misunderstanding of the nature of banks: (ALL banks are `fractional
reserve')
  ... the bankers are desperatesly fearful of this sort of vandalism.
  It could topple people's confidence in the fractional reserve
  banking system, and confidence is the only thing which keeps it
  going.

He concludes with an apocalyptic vision:
  Maybe later; not now.  Keep precious metal coins.  Don't
  assume that it an't happen here.  It can.  The only thing holding it
  back is the restraining hand of God, through the temporary
  self-restraint of a technological priesthood.


a few more words on password guessing

King Ables <ables%mcc-pp@mcc.arpa>
Mon, 9 Dec 85 20:53:51 cst
I hate to add to the "slippage" of the Risks forum into one of
security issues, but I feel strongly that a couple of points have
not been made that need to be.  I've had experiences on BOTH sides
of this fence...

You can't keep people from getting user names (as pointed out with
Unix and other systems with mail headers and output thrown in the
trash).  So we have to protect the passwords (that's why we call
them PASSwords).

I've seen people get passwords out of trash cans from Decwriters
and teletypes (although this doesn't happen much anymore due to
smarter
login programs that black out the paper).  As pointed out, it's real
easy to guess if you use your name, initials, or words from a 
dictionary, etc.  However, even if you use nonsensical anacronyms
(nonsensical to anyone else, that is), this doesn't make it
"unguessable."
In fact, I don't accept the statement that unguessable passwords
exist.
It depends on who's doing the guessing.  Passwords that are
unguessable
in a certain amount of time, I'll buy.  The guy trying to steal your
bike
trying different combinations has a finite amount of time he can work
before someone sees him and becomes suspicious.  If he were invisible,
he could sit there indefinitely (at least until you came and moved it)
and try combinations.  His chances of success that way would be MUCH
greater.  Somebody with a home computer on a phone line to your
machine is
fairly invisible to you (unless you have certain other mechanisms in
place to watch out for this sort of thing).  An old favorite computer
system of my early days used to have 3 letter passwords composed of
letters (upper case only) or digits.  36**3 possibilities.  At 5
seconds per try (a conservative estimate since there was no automatic
delay for wrong passwords), it would take a password guessing program
less than 65 hours (about 2.7 days) to try EVERY password in
the system.  OK, I'll admit things are better these days, longer
passwords,
more possible characters, delays during login attempts, etc.  BUT, the
point is that someone who wants to remain invisible and is very
patient
may very well break ANY password.  Passwords alone are insufficient.
You HAVE to have some other mechanisms to slow down what a password
guesser will be doing and hopefully some mechanism for spotting what's
happening and reporting it to someone before things progress very far.

Get one of those 3-digit combination bike locks and lock a $500 bike
in a secluded area for a week and see if it's still there when you
come
back ('course, they'd probably just cut the lock off in that case, but
you see my point).

-King
(ables@mcc.ARPA)

quick comment on passwords

Dave Curry <davy@purdue-ecn.ARPA>
Mon, 9 Dec 85 22:02:48 EST
Re: the thought that no password systems can be broken into...

As part of beefing up the passwd(1) program on our local UNIX systems,
I
wrote a simple program which tries 12 passwords per account (stuff
like
login name, first name, last name, using forwards, backwards, and
variations in case).

Anyway, I ran this program overnight (ran for about 6 hours on a
maxxed-out Gould PN9080) on 15,832 accounts and picked up 169
accounts.
That's 1% of the user population.  Not bad for an evening's work.
This
was the second time we ever ran this, the first time we got about 400
from a list of 10,000 (4%).  Those people were informed they should
change their passwords; most did.  This group of 169 has shown up in
the
last 12 months.  Most of the passwords were either the person's first
name or his login name, all lower case, forwards or backwards.

Now, if I can write something as trivial as this program (it's only
about
250 lines long) in an hour, imagine what some "cracker" (I refuse to
use
the term "hacker" to describe these jerks) could do with a weekend and
some real creativity.  My guess is that by adding some more fairly
simplistic guesses and using a few evenings of processor time I could
probably pick up at least 1500 accounts (that's 10% of our entire user
population, folks).  At the rate of over a hundred accounts per
evening,
it certainly wouldn't take too long.

Care to rephrase the "what, me worry?" statement?

--Dave Curry
Purdue Engineering Computer Network

P.S. - We aren't using the beefed up password program anymore, but
anyone
who wants the code is welcome to it.  It prevents using login, first,
last names in the above permutations as well as disallowing dictionary
words, license plate and phone numbers, and optionally any word having
the
characteristics of an English word.  If you want it, use anonymous ftp
and grab it from ee.purdue.edu in "pub/password.ar".  Look at the
password.c source before installing it though -- ours is probably
different than yours (it uses the 4.3BSD ndbm(3) password file
databases,
as well as a local gecos field format).

Subject: Passwords.

Dan_Bower%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
Thu, 12 Dec 85 03:09:00 EST
Many cases of 'guessed' passwords are when someone looks over your
shoulder
as you type.  Hunt and peck typists are especially prone to this.
Also, one
version (or is it many versions?) of PR1MOS requires passwords to be
keyed
in directly after the account code AS CONTROL CHARACTERS.  (I.e., you
type
in your account, then hold down the control key and type your
password.)
This forces you to hunt and peck.  Anyhow, keep in mind that it is NOT
impolite to ask someone to turn away as you log in on a terminal.

Please report problems with the web pages to the maintainer

Top