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 14 Issue 63

Tuesday 18 May 1993

Contents

o Read any good magazines lately?
Robert M. Slade [copyrighted article]
o Re: Cut and Paste risks
Pete Mellor
Byron Rakitzis
Tim Cook
Christopher Lishka
Joseph Hall
o Re: CHI & the Color-blind?
Eric Haines
Tom Ohlendorf
David Tarabar
o Re: Denning on NIST/NSA Revelations
Dorothy Denning
o Re: NIST's reply to Bidzos
Jim Horning
Frederick Roeber
Jim Sims
Chris Phoenix
Carl Ellison
o Compromising the escrow agencies
Mickey McInnis
o Info on RISKS (comp.risks)

Read any good magazines lately? [with permission, for RISKS]

<rslade@sfu.ca>
Tue, 18 May 93 12:42:47 PDT
    Memoirs of a (media star) virus researcher  [MEMOIR7.CVP   930515]

I have been known, from time to time, to make rather unkind statements about
the accuracy of virus reports in the mainstream media.  Some of my antipathy
arises simply from the fact that there is an awful lot of "mythology"
surrounding viral programs, and most of the pieces that appear in the media
simply perpetuate this.  Some of my experience, however, is first hand.

I like live radio best, and TV news the worst.  "Live" anything gives you a
bit of control, whereas TV is, in my view, arrogant, sensational and overpaid.
However, the electronic media still doesn't have an "all-computer" channel, so
most of the media reports about viral programs happen in print media.  I've
had a few forays there as well, but would like to outline one recent
experience.

A reasonably prominent periodical devoted to security topics has been
advertising for writers in, among other areas, the virus field, so I sent some
sample materials off.  I did not hear anything for about eight months, and
then got a call asking me to do an article.  On groupware.  Well, OK,
regardless of the topic I can use the money.  Only there isn't very much money
slated for this, slightly under $400 for roughly three pages of material.
(Please have it ready in 20 days.)  It doesn't take long, at that price, for
the "rate per hour" to drop into the basement.

However, it is not enough to write the article.  No, one has to contact the
vendors, and hear what they have to say on the topic.  This, actually,
consumes the most time.  Some research, and roughing out an outline, took up
two hours.  A rough draft took three.  Polishing the final draft took about an
hour.  Lots of room for profit there.  (Of course, when you consider the years
it takes to build the background to be able to do that, it tends to reduce the
margin a bit ...  :-) But contacting three consultants, two user group
representatives, and eleven representatives from seven major vendors took more
than fourteen hours spread over a ten day period.  In the end it got me one
very helpful vendor contact (Carol Smykowski from Fischer International, very
nice lady), one returned message, one faxed spec sheet from a loosely related
product and a heavy parcel that arrived postage due after the deadline.
Needless to say, this was less than helpful to the project.

In the end, the article was rejected.  Not enough "vendor quotes".

However, is my whining and complaining of any importance to you?  Well, yes,
it is.  What is really important here is the fact that most of the articles
being generated in the "trade press" are, by and large, "infomercials" on the
printed page.  Articles are being written, by people who, if they have a
technical background at all, are writing out of their field, and are being
judged on the acceptability of the content to vendors and advertisers.  The
vendors, quite happy with the situation, are in no hurry to be helpfully
involved in the process (or, indeed, even to return phone calls).

(As two examples, I cite the recent (as this is written) releases of PKZip
2.04 and MS-DOS 6.0.  For the first month after the release of the new PKZip,
while the nets were stretched by the reports of the various bugs, and the
latest release by PKWare to try to correct them, PC Week blithely rhapsodized
over "version 2" and advertised that it had version 2.04c (the real buggy one)
on its own board.  Meanwhile, in spite of the protests of the virus research
community *before* MS-DOS 6 was released, and the almost immediate storm of
reports of bugs and problems with various of the new features, the trade press
is only now, after six weeks of ecstatically positives reviews of MS-DOS 6,
starting to report some of the potential problems.)

The primary distribution of this article will, of course, be the Internet, as
it is also my primary source of information.  Unfortunately, the population of
"the net" is likely around two to five million.  A large number, perhaps, but
very small in comparison to the estimated hundred million PC users alone.  And
in that "larger" world, the inaccurate "non-net" media tends to hold much more
importance.

copyright Robert M. Slade, 1993   MEMOIR7.CVP   930515

Vancouver Institute for Research into User Security       Canada V7K 2G6
ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca   p1@CyberStore.ca


Re: Cut and Paste risks (Zwicky, RISKS-14.62)

Pete Mellor <pm@cs.city.ac.uk>
Tue, 18 May 93 10:12:06 BST
Elizabeth Zwicky's report (RISKS-14.62) about cut and paste with the elbow
reminded me of the "Case of the Overhanging Data Entry Operator", an anecdote
which caused some amusement many years ago in the customer support department
of one of the British manufacturers of mainframe computers, for whom I then
worked.

In those days, keying data directly onto disk, instead of punching onto cards
first, was relatively new, and "Direct Data Entry" was a selling point. The
DDE station was an intelligent terminal with disk, screen and keyboard. The
operator used to log in giving a password.

There was a fault in the password handling whereby a leading space would be
accepted as part of the password when this was set, but leading spaces were
ignored when the password was keyed at login. The temporary work-around was,
obviously, not to use spaces in passwords.

On one site, the support engineers were puzzled to find that, despite this
advice, the fault was being repeatedly triggered on one DDE station, although
the operator concerned emphatically denied having pressed the space bar when
entering a new password.

The proximal cause turned out to be that the operator was a well-built woman
...

Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk


Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

Byron Rakitzis <netapp!byron@netcom.com>
Mon, 17 May 93 21:54:46 PDT
While the X method for cut and paste may be poorly designed, I think there is
another RISK associated with system admin using window systems: namely, the
tendency to leave a window open with the root account logged in. I don't mean
to sound holier-than-thou, but it was always my practice to limit my actions
as root to as few as possible, by always explicitly su-ing to root, performing
a task, and logging out again. While this does not eliminate the
aforementioned risk, it does tend to minimize it.

Byron Rakitzis. <byron@netapp.com>


Re: Cut and Paste risks (Zwicky, RISKS-14.62)

Tim Cook <tim@deakin.edu.au>
18 May 1993 15:49:59 +1000
I think the advantages of cut-and-paste with X clients far outweigh
such a potential problem.

We should identify the main source of the risk, which in my opinion is general
access to super-user privileged shells.  This can be greatly reduced by
employing one of those utilities that provide individual super-user privileged
commands to specific users from their own accounts.  It would be much harder
to paste something that did damage in this scenario.

Tim Cook, Systems Engineer, Deakin University.


Re: Cut and Paste risks (Zwicky, RISKS-14.61)

Christopher Lishka <lishka@dxcern.cern.ch>
Tue, 18 May 1993 11:22:57 GMT
    >I've never liked the X method of cutting and pasting much,
    >but I'm beginning to feel actively hostile towards it.
    >    Elizabeth D. Zwicky zwicky@erg.sri.com

Not to mention mixed platform, mixed GUI cut-and-paste problems.  I am a
system manager for both VMS and Ultrix systems.  I use an Ultrix machine
running Motif for my GUI, while most of the VMS users have DECwindows.

The main problem is the differing cut-and-paste buttons: Motif uses the middle
button, while DECwindows uses the right button (assuming a right-handed mouse
set-up).  This becomes a problem when I run a standard DECwindows applications
with the display on Motif.  Only the left mouse button (select text) remains
constant.

Plus, some DECwindows applications (notably DECwindows Mail) like to reset the
cut-and-paste buffer if you switch input focus to a certain window.  (E.g.,
DECwindows Mail seems to put the text of the current message in the
cut-and-paste buffer automatically.)  My autofocus mouse (ala Sun) wreaks
havoc with this.  Many times I have selected text in one window, moved the
mouse to a terminal window, pasted, and had the entire contents of a mail
message run as Unix commands because I had accidentally had my mouse cross
over the DECwindows Mail window (focusing input briefly on it).

My solution?  Live with it.  It has not gotten to a point yet where I feel the
need to hunt down the various settings files (*if* this is possible) to fix
the problems by creating "Lishka's own standard GUI set-up".  Being a system
manager, I use a good variety of computers and their various GUIs frequently.
Furthermore, I have to help users a lot, and I have found that if I customize
my own GUI and shell settings too much, then I can't function with the
standard GUI and shell commands.  (It is very embarrassing to type all of
these arcane short-cut aliases in front of a user at her/his terminal, and
have them not work!  You look incompetent....)

How to practice safe cut-and-paste practices?  *NEVER* paste into a terminal
window with a superuser session (be it "SYSTEM" or "root").  This means one
has to type it all, possibly leading to transcription errors, but one should
always double-check important commands anyway.

Of course, as Ms. Zwicky's message shows, a lot of times pasting into a
superuser session window is unintentional.  More than once I have gone to
scroll my xterm window (using the middle button in the scroll-bar area), only
to hit the middle button a microsecond too early.  BLAM!  I've just pasted a
mail message into my VMS SYSTEM session, and all of its contents are being
interpreted as commands.  Luckily nothing major has happened because of this!

Sometimes I think going back to a good old VT100 terminal would be safer all
around....

Christopher Lishka   PPE Division, CERN   lishka@dxcern.cern.ch


Re: Cut and Paste risks (Zwicky, RISKS-14.62)

Joseph Hall <Joseph_Hall@motsat.sat.mot.com>
Tue, 18 May 1993 14:37:36 -0700
The Macintosh Programmer's Workshop (MPW) shell provides an interesting
solution to this problem ... you execute a line of text as a command by
pressing the ENTER key (on the numeric keypad).  RETURN simply inserts
a carriage return in the text.  Similarly, pasted text isn't interpreted
as commands to be executed.

I wouldn't mind it at all if xterms, cmdtools etc.  worked this way.  I've
yet to experience disaster as a result of X pasting, but I've come close.

Joseph Nathan Hall, Software Systems Engr, GORCA Systems Inc.
jnhall@sat.mot.com joseph@joebloe.maple-shade.nj.us  (609) 732-3194


re: CHI & the Color-blind? (Yu, RISKS-14.62)

Eric Haines <erich@eye.com>
Tue, 18 May 93 10:22:58 -0400
An article which color interface designers would benefit from reading:

Gary W. Meyer and Donald P. Greenberg, "Color-defective vision and computer
graphics displays", IEEE Computer Graphics and Applications, v. 8, n. 5,
Sept 1988, p. 28-40.

It discusses how to select colors which are appropriate for the various types
of color blindness, along with reasonable general solutions.

Eric Haines


Re: CHI & the Color-blind?

"Tom Ohlendorf - TSU Admin. DP, (410) 830-3642" <D7AP002@TOA.TOWSON.EDU>
Tue, 18 May 1993 08:08 EDT
>   "A black icon facing left to right means a call was placed, but no
>   contact was made.  A red icon facing left to right means a call was
>   placed and contact was made, but a promise to pay was not received.
>   A green icon facing left to right means a promise to pay was arranged.
>   An icon facing right to left means the debtor called the collector."

Not only are the color blind affected by the new monitors, so are the dyslexic.
I can very easily see a dyslexic person interpreting a right to left icon as
left to right. Suppose the person is color blind and dyslexic....

Tom Ohlendorf, Programmer/Analyst, Towson State University,
Towson, MD 21204  OHLENDORF-T@TOA.TOWSON.EDU  (410) 830-3642


RE: CHI & the Color-blind?

David Tarabar <dtarabar@hstbme.mit.edu>
Tue, 18 May 93 15:26:14 -0400
The CHI community is aware of the potential problems that Vannevar Yu
has pointed out. For example, the Macintosh User Interface Guidelines
has 8 pages devoted to the use of color in applications. They urge
developers to "Always develop for black and white first and then
colorize that design". They point out that to accommodate "people with
color-deficient vision", "you shouldn't use color as the only means of
communicating important information. Color should be used redundantly."

I'm sure that other user interface guidelines and texts make similar points.
Perhaps the risks here are that applications developers are not aware of (or
ignore) the literature about human interface design.

Dave Tarabar  dtarabar@hstbme.mit.edu


Re: Denning on NIST/NSA Revelations (Sobel, Denning, Rotenberg)

Dorothy Denning <denning@cs.cosc.georgetown.edu>
Tue, 18 May 93 16:54:22 EDT
In response to David Sobel's statement about NIST and the DSS, I wrote
in RISKS-14.60:

  ... NIST issued the DSS proposal along with a public call for comments
  as part of their normal practice with proposed standards.  The
  community responded, and NIST promptly addressed the security
  concerns.  Among other things, the DSS now accommodates longer keys
  (up to 1024 bits).  As a result of the revisions, the DSS is now
  considered to be just as strong as RSA.

In RISKS 4.62, Marc Rotenberg responded:

  Denning has to be kidding.  The comments on the proposed DSS were
  uniformly critical.  Both Marty Hellman and Ron Rivest questioned the
  desirability of the proposed standard.

  One of the reasons for the concern was the secrecy surrounding the
  development of the standard.  The documents disclosed by NIST and NSA
  to CPSR make clear that NSA used its classification authority to
  frustrate the attempt of even NIST's scientists to assess the
  candidate algorithm.

The DSS is similar to a scheme by El Gamal, which was presented at
CRYPTO 84 and subsequently published in the IEEE Trans. of Information
Theory (July 85).  It is even closer to a scheme by Schnorr, which was
presented at CRYPTO 89.  The DSS is not classified and the basic
approach has been under scrutiny by the crypto community since 84.  All of
the cryptographers that I have spoken with at NIST have made the assessment
that the DSS (as revised in response to the comments by Hellman, Rivest,
and others) is at least as strong as RSA for comparable key lengths.
I am unaware of any evidence to the contrary.

Also in RISKS-14.62, Bill Murray wrote

  While it may be true that DSS with a 1024 bit modulus is as secure
  for digital signatures as RSA, it does not meet either the
  congressional mandate or the requirement.  The congressional mandate
  was for a public-key standard, not for a digital signature standard.
  The requirement is for a mechanism for key exchange.

According to NIST, there was no Congressional mandate for a public-key
standard.  Congress did give NIST the charge to develop standards for
sensitive, unclassified information, but it left open to NIST exactly what
those standards should be.  On its own initiative, NIST issued a solicitation
for a public-key standard in the Federal Register, June 30, 1982.  My
understanding is that the solicitation was very broad and did not identify
exactly what functions such a standard would need to provide.  Several years
later NIST, at their discretion, proposed the DSS.

In retrospect, we can now look back and see how the DSS fits in with Clipper
and Capstone.  The result will be a complete package that has encryption,
signatures, and key management/exchange. Thus, the advantage of RSA over the
DSS in its ability to do key exchange disappears.

It is very easy to be critical of a process when you are looking at it from
the "stands" instead of the "court" and from hindsight rather than from
current action and concerns.

Dorothy Denning


Re: NIST's reply to Bidzos (RISKS-14.62)

<horning@src.dec.com>
Tue, 18 May 93 11:22:55 -0700
Ed Roback's last sentence is the zinger, in terms of revealing
the state of mind of those involved in this effort:

    ...and of the law enforcement community for continued legal
    access to the communications of criminals.

What ever happened to "innocent until proved guilty"?

Also, Clipper is only mandated for government use (he says).
I'm all in favor of exposing criminals in government, but is
this really the most cost-effective way?

Jim H.


Re: NIST's reply to Bidzos (RISKS-14.62)

Frederick Roeber <roeber@vxcrna.cern.ch>
Tue, 18 May 1993 10:56:42 GMT
They mean "suspects", not "criminals", don't they?


Re: NIST's reply to Bidzos (RISKS-14.62)

Jim Sims <sims@pdesds1.atg.trc.scra.org>
Tue, 18 May 93 08:49:06 EDT
<>          NSA's analysis on the security
<>          risks of the escrow system is not available for public
<>          dissemination.
<>
>>> >>>>  NIST:    It will not be possible for anyone from Mykotronx, VLSI,
<>          NIST, NSA, FBI (or any other non-escrow holder) to
<>          compromise the system.

    Really? Then why is the NSA/NIST/etc *so* reluctant to release
    details of the system? Details that are certainly known
    (piecemeal) to the *anyone*s mentioned above.

<>          To prevent this, it
<>          is envisioned that every time a law enforcement agency is
<>          provided access to the escrowed keys there will be a record
<>          of same referencing the specific lawful intercept
<>          authorization (court order).  Audits will be performed to
<>          assure strict compliance.  This duplicates the protection
<>          afforded nuclear release codes.  If additional escrow
<>          agents are added, one additional person from each would be
<>          required to compromise the system.
<>
>>> >>>> NIST:     No.  First of all, there is strict and limited use of
<>          subpoenaed material under the Federal Rules of Criminal
<>          Procedure and sanctions for violation.  There has been no
<>          evidence to date of Governmental abuse of subpoenaed
<>          material, be it encrypted or not.  Beyond this, other
<>          Federal criminal and civil statutes protect and restrict the
<>          disclosure of proprietary business information, trade
<>          secrets, etc.  Finally, of all the Federal agencies cited,
<>          only the FBI has statutory authority to conduct authorized
<>          electronic surveillance.  Electronic surveillance is
<>          conducted by the FBI only after a Federal judge agrees that
<>          there is probable cause indicating that a specific
<>          individual or individuals are using communications in
<>          furtherance of serious criminal activity and issues a court
<>          order to the FBI authorizing the interception of the
<>          communications.

 You just *don't* get it, do you? You can make all the laws you want.
 You *CANNOT* force anyone to comply with them.

 And all the assurances you can give about due process and Federal
 judges agreeing, etc doesn't hold water. What Federal judge agreed to
 the ATF/FBI sponsored stupidity in Waco Texas recently?

 As we have already seen severe erosion of the 'unwarranted search
 and seizure' protection for the sake of the phony War on Drugs, how
 can you expect anyone to believe the same thing wont happen on a much
 larger scale. It's *so* much easier to search electronic
 communications than someone's car.... Just ask the NSA.

 And speaking of "only after a Federal judge agrees" it seems like you
 just introduced a SINGLE failure point into the marvelous triple-lock
 system so cleverly crafted....

 skeptical,  jim


Re: NIST's reply to Bidzos (RISKS-14.62)

Chris Phoenix <efi!chrisp@uunet.UU.NET>
Tue, 18 May 1993 22:28:16 GMT
I have put together a few sentences from NIST.  Together they paint a rather
scary picture.  I don't think I've changed any meanings by taking anything out
of context.

>>>>>  NIST:       There are no current plans to legislate the use of Clipper.
>            .... The
>                  option for legislation may be examined during the policy
>                  review ordered by the President.
>>>>> NIST:             ....  We also
>                  point out that the President's directive on "Public
>                  Encryption Management" stated: "In making this decision, I
>                  do not intend to prevent the private sector from developing,
>                  or the government from approving, other microcircuits or
                                     ^^
>                  algorithms that are equally effective in assuring both
           ^^^^^^^^^^          ^^^^^^^^^^^^^^^^^
>                  privacy and a secure key-escrow system."
                 ^^^^^^^^^^^^^^^^^^^^^^^^
>
>>>>> NIST:        You are correct that, currently, Clipper Chip functionality
>                  can only be implemented in hardware.  We are not aware of a
>                  solution to allow lawfully authorized government access when
>                  the key escrow features and encryption algorithm are
>                  implemented in software.  .....  Existing software
>           encryption use can, of course, continue.

>>>>> NIST:        No studies have been conducted on a government-wide basis to
>                  estimate the costs of telecommunications security
>                  technologies.  The needs for such protection are changing
>                  all the time.

To me it looks like the line quoted from the President's directive only
protects private encryption if done in hardware.  As they themselves say,
there is no known way to enforce the escrow of software encryption keys.
Can anyone speculate on the likely results of this "option for legislation"
that the President is going to "examine"?

So my feeling from reading all this is that the government may try to
legislate the use of encryption that can be implemented only in hardware.
I can see it now.  "Responding to privacy concerns about the Clipper chip,
AT&T has privately developed a new encryption chip using a proprietary
algorithm. .... 'In order to ensure that this chip will assure privacy
as well as complying with new escrow laws, the algorithm has been submitted
to NIST's approval process, and we have made a few changes,' says AT&T
spokeswoman ...."

It would not surprise me at all if Clipper ended up in all Newtons,
cordless phones, and faxes by the year 2000.  This will cause someone
to make incredible amounts of money.  Has anyone wondered where all
this money will go?  I am not trying to form a conspiracy theory
here--it is possible that the Clipper really was motivated by wiretaps
and no one realized how many Clippers could end up being sold.  But
given the upcoming proliferation of wireless computers, I think this
question needs to be asked now.  Whatever the origins of Clipper,
there is now a serious risk of corruption associated with it just from
the money involved.  Does anyone have hard estimates on how much
additional money flow would be generated by using Clipper in all
wireless computers and communication products for the next 10 years?

Chris Phoenix, chrisp@efi.com, 415-286-8581


Re: NIST's reply to Bidzos (RISKS-14.62)

Carl Ellison <cme@ellisun.sw.stratus.com>
18 May 1993 22:40:00 GMT
>What is the smallest number of people who are in a position to compromise the
>security of the system?

>>>>>  NIST:       It will not be possible for anyone from Mykotronx, VLSI,
>                  NIST, NSA, FBI (or any other non-escrow holder) to
>                  compromise the system.  Under current plans, it would be
>                  necessary for three persons, one from each of the escrow
>                  trustees and one who knows the serial number of the Clipper
>                  Chip [...]

Clearly, NIST doesn't consider release of a chip's key to outside criminals
by one FBI agent to be a compromise of security, if that agent got the key
from the escrow agencies in a normal way.  Does this mean that once a
person has been subjected to a wiretap, he doesn't deserve any security --
no matter what the reason for the tap?

What of the ability of a single gov't employee illegally to declare a
national security tap and by weight of authority get escrow holders to
release keys?  This, too, sounds like a single-source of failure.

What of the possibility of buying two people, one in each agency, to get
copies of the whole database?  That sounds like 2 rather than 3 to me.


>Did the administration ask these questions (and get acceptable answers) before
>supporting this program? If so, can they share the answers with us? If not,
>can we seek answers before the program is launched?
>
>>>>> NIST:        These and many, many others were discussed during the
>                  development of the Clipper Chip key escrow technology and
>                  the decisions-making process.  The decisions reflect those
>                  discussions and offer a balance among the various needs of
>                  corporations and citizens for improved security and privacy
>                  and of the law enforcement community for continued legal
>                  access to the communications of criminals.


Clearly, NIST believes that a set of meetings behind closed doors is an
adequate discussion and that we the public should thank them for their
effort and applaud their claimed "balance among the various needs of
corporations and citizens for improved security and privacy and of the law
enforcement community for continued legal access to the communications of
criminals".

Whatever happened to scientists at NIST?  Why does it sound like we're
hearing from PR men?

Carl Ellison, Stratus Computer Inc., 55 Fairbanks Boulevard ; Marlborough MA
01752-1298                  cme@sw.stratus.com            TEL: (508)460-2783


Compromising the escrow agencies

"McInnis, M.R. (Mickey)" <mcinnis@vnet.IBM.COM>
Mon, 17 May 93 23:44:48 CDT
I'm surprised that no one has commented on what I see as an obvious way
to compromise the escrow agencies for Clipper.

Suppose for instance that clipper phones were already available for several
years.  Suppose that during the recent Waco standoff, the BATF went to some
gullible federal judge and said:

  "We have found that these people have got a large number of Clipper
  equipped phones.  They keep using different phones, and it takes us
  hours or days to process the paperwork, contact the escrow agencies,
  etc. for each new phone they use.

  These delays are making a dangerous situation worse and give the
  cultists enough time to plan actions and execute them
  before we can decipher the recorded conversations.  It endangers
  the children in the compound and the law enforcement people around
  the compound.

  We need you to sign this order that requires the two escrow agencies
  to release the entire set of keys to us.  (Since we don't know the
  serial numbers of all the phones he might have.)   Of course, we
  don't want the media and the cultists to find out about it, so there
  is a gag order included.

  Of course, we will destroy our records once the standoff is over."

The frightening thing about this is that they only have to convince one
federal judge.

Mickey McInnis                 mcinnis@vnet.ibm.com

Please report problems with the web pages to the maintainer

Top