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 9

Monday, 9 Sep 1985

Contents

McCarthy, Weizenbaum on SDI

Douglas Schuler

Why I'm against even a reliable SDI

Jeffrey Mogul

Risk Assessment and Risk Management

Edward V. Berard

Risks in displaying a file containing control characters

Keith F. Lynch

McCarthy, Weizenbaum on SDI

douglas schuler <bcsaic!douglas@uw-june>

Mon, 9 Sep 85 09:34:15 pdt

Joseph Weizenbaum states that he would be against SDI "even if it worked."
I agree.  The premise that "IF the SDI could work, then we must have it (at
any price)" is naive.  It seems that many people are willing to accept that
premise hoping that it will anchor the discussion in the technical area.

One factor which is rarely addressed is that of intermediate systems which
the SDI will spawn.  There is a tendency to think of the SDI system as being
one big system that one day appears overhead as a whole, integrated system.
I have little doubt that the SDI plan includes many deliverables along the
way.  These intermediate systems will both be arguably non-defensive and
pose a large problem for integration.  I.e., the system must not only be
trustworthy when "fully deployed" but at a multitude of intermediate steps.
Thus risks will exist in advance of the full delivery (if there ever is to
be one).

Another factor is the so-called defensiveness of the system.  If two people
are armed with guns and one suddenly dons a bullet proof vest this act will
be perceived as an offensive act.

Pro-SDI people almost always accuse SDI critics of being politically
motivated.  Given the immense (and possibly impossible) technical task of
getting the system to work, and the guarenteed proliferation of offensive
weapons (designed to penetrate the system), it is very, very difficult for
me to believe that the pro SDI folk are not motivated primarily from
political (and economic!!) grounds.

  - Doug Schuler

Why I'm against even a reliable SDI

Jeffrey Mogul <MOGUL@SU-SCORE.ARPA>

Mon 9 Sep 85 16:40:02-PDT

To: risks@SRI-CSL.ARPA

To quote from RISKS Vol 1 #8:
    2.  I can disagree only with one aspect of Weizenbaum's contribution.
    He says that he would be against SDI even if it would work, but his
    arguments mainly show even more reasons why it won't "make nucelar weapons 
    impotent and obsolete."  It is probably useless to argue about how we
    would feel about the system if it would work, but I feel the decision
    would be much harder to make than it is now. [Dave Parnas]

I think this touches on the crux of the matter: what problem is SDI meant to
solve?  If we could guarantee that SDI would not only "make nuclear weapons
impotent and obsolete", but would in fact reduce the risks associated with
war (not necessarily the same thing) then I would not be against SDI.
However, I argue (and I suspect this is Weizenbaum's point, too) that an SDI
that worked according to the current specification would actually increase
risks, even though the system performed "flawlessly".

This is not the place to discuss the strategic implications of SDI, but I
think it's important to realize that there are those of us who believe both
that SDI is not likely to meet its current specification, nor that it would
be a good idea even if it did.

    [I] would see some truth in the argument that the non-technological
    solutions also have a clear risk of failure.  [Parnas]

I am afraid that there is no failure-proof solution, technological or not,
to the problem of "war".  John McCarthy is right that we must compare
the risks of the technological solution (e.g., SDI) to its non-use.  My
fear is that, in this case, the problem is not that the use of technology
might fail to solve the problem, but that it might actually make things
worse.

Risk Assessment and Risk Management

Edward V. Berard <EBERARD@USC-ECLB.ARPA>

Mon 9 Sep 85 08:16:07-PDT

To: risks@SRI-CSL.ARPA

There has been some discussion of comparing alternative risks on the
RISKS mailing list lately. For example, what is the risk associated
with the introduction of a new technology versus not introducing the
technology? Risk assessment and risk management need not be
"guesstimates" nor "a number picked out of the air."

The insurance industry has had to assess and manage risks for years.
In fact, they have made quite a science out of these two areas. I
would recommend that those who wish to find out more about risk
management and risk assessment read:

   RISK MANAGEMENT AND INSURANCE, Fourth Edition, by C. Arthur
   Williams, Jr. and Richard M. Heins, McGraw-Hill, 1981.

Don't let the title put you off. Virtually the entire book is
dedicated to risk management, with only a few pages on insurance. You
will also find that there are entire professional societies dedicated
to managing and assessing risk, e.g., the American Risk and Insurance
Association and the Risk and Insurance Management Society.  

        -- Ed Berard
                   EBerard at ECLB
                   (301) 251 - 1626

Risks in displaying a file containing control characters

Keith F. Lynch <KFL@MIT-MC.ARPA>

Mon, 9 Sep 85 00:26:04 EDT

To: LIN@MIT-MC.ARPA
cc: Risks@SRI-CSL.ARPA, Security@RED.RUTGERS.EDU

    Date: Sun,  8 Sep 85 16:40:44 EDT
    From: Herb Lin <LIN@MIT-MC.ARPA>

    My naive model is that I have a special program that intercepts the
    raw bit stream that comes in from my communications port.  It then
    translates this into ASCII, and then prints it on my screen.  

    If this is all that my program does, I can't see what harm can be done.

Several kinds of terminals are programmable from the host, in that
certain escape sequences can be sent to them to get them to perform
actions such as defining the terminal's function keys.

If a user inserts the appropriate escape sequences in a mail message
to his system manager, or into a file which will be displayed by the
manager, when the manager reads that mail message it will reprogram
a function key on the manager's terminal, which the manager may have
programmed to do some common harmless function, to instead do some
other command such as give the user unauthorized privileges.

This is a fairly well known bug, and many mail systems are now
protected against it, in that they will not transmit any control
characters or escape sequences to the terminal.

The moral is that there are many subtle ways to break security,
and even things that seem to be quite safe may not really be.
                                ...Keith

Report problems with the web pages to the maintainer