The RISKS Digest
Volume 14 Issue 62

Monday, 17th May 1993

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Cut and Paste risks
Elizabeth Zwicky
CHI & the Color-blind?
Vannevar Yu
Update on risks in semiconductor manufacturing
Rob Horn
Re: Epilepsy and video games
Edwin Culver
Don't Depend on makedepend
Dave Wortman
makedepend problem - a real world example
Michael Turok via Dave Wortman
Business Week: ADP Flubs
Bob Frankston
Mobile Phones and airbags (was: Opel Corsa ...)
Olivier MJ Crepin-Leblond
Re: Denning on NIST/NSA Revelations
Marc Rotenberg
Bill Murray
NIST Answers to Jim Bidzos' Questions
Ed Roback via Jim Bidzos
Info on RISKS (comp.risks)

Cut and Paste risks

Elizabeth Zwicky <zwicky@erg.sri.com>
Mon, 17 May 93 09:51:07 -0700
A few years ago, one of our main servers went down, and failed to reboot.
Investigation showed that it had been halted with the instruction to reboot on
a kernel named "imagen.df", which naturally had not worked well. Further
investigation showed that only our most junior system administrator had been
logged into it at the time. She was adamant, if not frantic, in her denial of
having done any such thing. Fortunately, she had been logged into it from
another machine in an xterm with a scrollbar, and we were able to scroll it
back to the point before the machine went down, where a wide variety of
peculiar error messages became visible. Messages like "dumpdates: permission
denied", and "dump: bad key 'i'" appeared before a final "fastboot" took
effect. In horror, she said "All I did was drop my pencil and when I
straightened up it was gone!" It seems that when she leaned over to pick up
the pencil, her elbow cut and pasted an ls of /etc at the prompt. Fortunately
"clri" is very picky about its syntax, or we might have had a really
interesting mess. As it happened, "fastboot" was the first command which was
willing to take the remainder of its line as valid arguments.

We wrote this off as a once-in-a-lifetime event until Friday, when another
server went down suddenly. This one came back OK, and we didn't have to search
for the culprit, a relatively senior administrator who turned himself in
shamefacedly: "I hit the wrong mouse button. It pasted a fastboot. It's all my
fault."

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


CHI & the Color-blind?

Vannevar Yu <vannevar@Panix.Com>
Sat, 15 May 93 18:17:57 EDT
In the May 1993 issue of Credit Card Management (vol.6, no.2, New York, NY)
a special report on "Collections Technology" utilizing color graphic displays
was described in p.66:

  "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."

Given that the use of computers with fancy color displays will become more
common with time, how do we ensure that color-blind people can use these
displays without any confusion?  Although one of my color-blind friends can
tell that there is a difference between, say red and green, a simple change in
monitor contrast/brightness levels (or being assigned to a different terminal
or a particular day) would probably be enough to throw him off.  With
disabilities-related legislation in the United States in place, such issues
regarding computer-human interaction will definitely get more attention.


Update on risks in semiconductor manufacturing

rob horn <horn%temerity@leia.polaroid.com>
14 May 1993 21:27:51 -0400 (EDT)
The miscarriage risk information on semiconductor manufacturing is based on
multiple epidemiological studies.  The largest of these was by UC Davis and
tracked 15,000 employees at 14 plants.  The studies were examining effects
from microwave exposure, low frequency magnetic fields, solvents, paints, CRT
usage and electrostatic field exposure.  In one portion of the manufacturing
process a solvent related problem was found.  No other statistically
significant effects were found.

The solvent risk is from the family of solvents known as glycol ethers, with
particular risk from the ethylene glycol ethers.  These solvents are used in
the photolithography process.  This is the stage where the semiconductor is
coated with a photoresist layer, this layer exposed through a mask, and then
partially removed.  Most photolithography processes involve solvents of
various sorts.  The study isolated the effect to sites using glycol ethers.
The other solvents may be dangerous, but the safety precautions appear to be
adequate.

The risk magnitude is an increase of between 40 and 100% in the miscarriage
rate for workers in photolithography where ethylene glycol ethers are used.

Industry reaction is mixed.  There is relief that the other safety measures
are effective.  The ethers are not the most dangerous chemical used.  There
are far more toxic chemicals involved elsewhere.  There is disappointment that
the safety measures in place in photolithography are inadequate.  There was
also relief that suspected hazards from CRT usage, EMF, and ESF did not cause
an increase in the miscarriage rate.

The semiconductor industry is already several years into major overhauls and
redesigns to reduce health, safety, and environmental hazards.  All of the
glycol ethers were already targets for gradual elimination as health and
significant environmental hazards.  The disposal for one gallon of such waste
now exceeds $50.  This study will accelerate their elimination.  This will
have a significant economic impact because the alternative processes with low
health and environmental impacts are very different.  Often it is easier to
close the old factory and build a new one.  When making a change this big,
there is often an associated site relocation, job losses, etc.

Health hazards in the electronics manufacturing industry are not new.  The
toxic chemicals hazards from printed circuit board manufacturing and soldering
stations are some earlier significant dangers.

Rob Horn    horn@temerity.polaroid.com


Re: Epilepsy and video games

Edwin Culver <culver@cse.bridgeport.edu>
Fri, 14 May 93 11:07:15 EDT
Larry Hunter and others were asking about seizures induced by video games.  Not
being a neurologist, I wonder if these are similar to those caused by "photic
stimulation", which has been implicated in some aircraft accidents.

Some people, when exposed to flickering or flashing lights will have seizures
which are quite similar to epileptic seizures.  In aircraft, this can be a
problem for general aviation pilots, who look through the propeller disk.
During most of the flight, the frequency is too high to cause problems, but
during a landing, especially into the setting sun, the propeller may cause
flickering sufficient to induce a seizure.  There are, apparently, degrees of
severity: some people will seize from a single flash of the right duration.

Edwin M. Culver   culver@cse.bridgeport.com  (203) 741-8736


Don't Depend on makedepend

Dave Wortman <dw@pdp1.sys.toronto.edu>
Mon, 17 May 1993 14:09:28 -0400
Context: makedepend is a program that processes a set of C program files
and determines interdependencies among those files.  It is frequently used
in large software systems to (attempt to) guarantee that a Makefile correctly
describes the dependencies in a piece of software.  There is often a software
building step called "make depend" that invokes the makedepend program.
Many users of makedepend run it automatically as a part of system building
without much appreciation for what it is doing.

Makedepend has a documented undependability!!

In the man page for makedepend under the heading "Bugs", we find the
remarkable statement:

"If you do not have the source for cpp, the Berkeley Unix C preprocessor then
 makedepend will be compiled in such a way that all #if directives will
 evaluate to "true" regardless of their actual value.  This may cause the
 wrong #include directives to be evaluated." ...

This appears to open a large hole for incorrectly building software.
If the Makefile dependencies generated by makedepend are wrong then there
is a chance that the software built using the Makefile will also be wrong.

I think the authors of makedepend made a bad decision in allowing the program
to become functional in a situation where they knew it could get the
wrong answer.  To their credit, at least they documented the problem.
If the source for Berkeley cpp is unavailable then it shouldn't be possible
to compile makedepend.

Risks:
- wrong answers from makedepend could lead to wrong software.
- the ordinary user of makedepend has no way of knowing whether the
  makedepend they are using will get the right answer or not.
- many users of makedepend are unaware that makedepend can get the
  wrong answer.


makedepend problem - a real world example

Dave Wortman <dw@pdp1.sys.toronto.edu>
Mon, 17 May 1993 20:02:09 -0400
Shortly after posting my message concerning problems with makedepend
I came across an unsolicited example of the problem in a posting by
Michael Turok (mlt@blues.infores.com) to the comp.windows.x newsgroup.

...
makedepend chokes on one of X11 include files (as distributed
by Sun) - namely Xos.h:

#if     !defined(SUNOS41) || defined(__STDC__)
#       include <string.h>
#       define  index   strchr
#       define  rindex  strrchr
#else   /* BSD && !__STDC__ */
#       include <strings.h>
#endif  /* !SUNOS41 || __STDC__ */

Here 'makedepend' evaluates both #if and corresponding #else statements
to 'true' and tries to open the file <strings.h> which doesn't exist
under Solaris2.  ...


Business Week: ADP Flubs

<Bob_Frankston@frankston.com>
Sun 16 May 1993 14:21 -0400
There is an article in the May 24, 1993 issue of Business Week covering
errors in Automatic Data Processing's handling of key tabulations and
statistics including undercounting the shareholder votes for a company (the
72.4 million counted were not enough) and misreporting key government labor
statistics in the late 1980's that resulted in exaggerating job losses until
1991 by 540,000 jobs.

In my mind the issue is not so much the ADP errors, as the dependence we have
on such calculations without effective fallback and reasonableness checks.
Errors, while not forgivable, will occur whether it is a programming error, a
management oversight or a systemic flaw.

As we build these statistics into policy, the best we can hope for is that
there is some effective feedback to reduce volatility. My fear is that bad
statistics can lead to policies that only amplify the problem. Can
hyperinflation be caused by misreporting CPI figures? Perhaps the job figures
influenced the recent election.


Mobile Phones and airbags (was: Opel Corsa Stops...)

Olivier MJ Crepin-Leblond <o.crepin-leblond@ic.ac.uk>
Sat, 15 May 1993 19:22:15 +0100
In Risks-Digest 14.61, O\ystein Gulbrandsen relays a description of the
effect of a mobile phone on the electronics of an Opel (or Vauxhall
here in UK :-) ) Corsa engine.

By coincidence a similar subject came-up in a conversation I had with
a colleague last week. This is second-hand information, but it
appears that the electronics for some AIRBAG impact safety systems
were also affected by mobile telephones, and that in a few cases,
the airbags were inflated spontaneously while the car was being
driven, and of course, without any impact.
It would be interesting if anyone could confirm this. Before hearing
the Opel corsa story, I was most skeptical about it, but now...

Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
 Imperial College of Science, Technology and Medicine, London SW7 2BT, UK


Re: Denning on NIST/NSA Revelations (Sobel, RISKS-14.59)

Marc Rotenberg <Marc_Rotenberg@washofc.cpsr.org>
Sun, 16 May 1993 11:30:25 EST
David Sobel, CPSR Legal Council, wrote in RISKS DIGEST 14.59:
<>    The proposed DSS was widely criticized within the computer
<>      industry for its perceived weak security and inferiority to an
<>    existing authentication technology known as the RSA algorithm.
<>    Many observers have speculated that the RSA technique was
<>    disfavored by NSA because it was, in fact, more secure than the
<>    NSA-proposed algorithm and because the RSA technique could also
<>    be used to encrypt data very securely.

Dorothy Denning responded in RISKS Digest 4.60
> This is terribly misleading. 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.

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.

This is not part of "normal practice."  In fact, NSA's efforts to blindfold
NIST and the secrecy surrounding the process violated the central intent of
the Computer Security Act, the very law that governs the relationship between
NIST and NSA.

Marc Rotenberg, CPSR Washington office


Dr. D. Denning on DSS v. RSA (Sobel, RISKS-14.59)

<WHMurray@DOCKMASTER.NCSC.MIL>
Sat, 15 May 93 22:56 EDT
The point is that NSA dislikes RSA "because (it) could also be used to
encrypt data very securely."  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.  The
DSS is a ruse; it is an attempt to appear to meet the congressional mandate
without meeting the requirement.

I think that the CPSR statement is both accurate and to the point.

William Hugh Murray, Executive Consultant, Information System Security
49 Locust Avenue, Suite 104; New Canaan, CT 06840  1-0-ATT-0-700-WMURRAY


NIST Answers to Jim Bidzos' Questions

Jim Bidzos <jim@RSA.COM>
Mon, 17 May 93 14:05:18 PDT
Date:    Mon, 17 May 1993 16:44:28 -0400 (EDT)
From: ROBACK@ECF.NCSL.NIST.GOV
Subject: Answers to Your Questions
To: jim@RSA.COM

To:  Mr. Jim Bidzos, RSA Data Security, Inc.

From:  Ed Roback, NIST

Mr. Ray Kammer asked me to forward to you our answers to the questions you
raised in your e-mail of 4/27.

We've inserted our answers in your original message.

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

From:       SMTP%"jim@RSA.COM" 27-APR-1993 03:13:12.75
To:   clipper@csrc.ncsl.nist.gov
CC:
Subj:       Clipper questions
...
Date: Tue, 27 Apr 93 00:11:50 PDT
From: jim@RSA.COM (Jim Bidzos)

Here are some questions about the Clipper program I would like to submit.

Much has been said about Clipper and Capstone (the term Clipper will be used
to describe both) recently.  Essentially, Clipper is a government-sponsored
tamper-resistant chip that employs a classified algorithm and a key escrow
facility that allows law enforcement, with the cooperation of two other
parties, to decipher Clipper-encrypted traffic.  The stated purpose of the
program is to offer telecommunications privacy to individuals, businesses, and
government, while protecting the ability of law enforcement to conduct
court-authorized wiretapping.

The announcement said, among other things, that there is currently no plan to
attempt to legislate Clipper as the only legal means to protect
telecommunications.  Many have speculated that Clipper, since it is only
effective in achieving its stated objectives if everyone uses it, will be
followed by legislative attempts to make it the only legal telecommunications
protection allowed. This remains to be seen.

>>>>  NIST:       There are no current plans to legislate the use of Clipper.
                  Clipper will be a government standard, which can be - and
                  likely will be - used voluntarily by the private sector. The
                  option for legislation may be examined during the policy
                  review ordered by the President.

The proposal, taken at face value, still raises a number of serious questions.

What is the smallest number of people who are in a position to compromise the
security of the system? This would include people employed at a number of
places such as Mikotronyx, VSLI, NSA, FBI, and at the trustee facilities.  Is
there an available study on the cost and security risks of the escrow process?

>>>>  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 which is the subject of the court authorized electronic
                  intercept by the outside law enforcement agency, to conspire
                  in order to compromise escrowed keys.  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.  NSA's analysis on the security
                  risks of the escrow system is not available for public
                  dissemination.

How were the vendors participating in the program chosen? Was the process
open?

>>>> NIST:        The services of the current chip vendors were obtained in
                  accordance with U.S. Government rules for sole source
                  procurement, based on unique capabilities they presented.
                  Criteria for selecting additional sources will be
                  forthcoming over the next few months.

                  AT&T worked with the government on a voluntary basis to use
                  the "Clipper Chip" in their Telephone Security Device.  Any
                  vendors of equipment who would like to use the chips in
                  their equipment may do so, provided they meet proper
                  government security requirements.

A significant percentage of US companies are or have been the subject of an
investigation by the FBI, IRS, SEC, EPA, FTC, and other government agencies.
Since records are routinely subpoenaed, shouldn't these companies now assume
that all their communications are likely compromised if they find themselves
the subject of an investigation by a government agency?  If not, why not?

>>>> 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.

What companies or individuals in industry were consulted (as stated in the
announcement) on this program prior to its announcement? (This question seeks
to identify those who may have been involved at the policy level; certainly
ATT, Mikotronyx and VLSI are part of industry, and surely they were involved
in some way.)

>>>> NIST:        To the best of our knowledge: AT&T, Mykotronx, VLSI, and
                  Motorola.  Other firms were briefed on the project, but not
                  "consulted," per se.

Is there a study available that estimates the cost to the US government of the
Clipper program?

>>>> 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.

There are a number of companies that employ non-escrowed cryptography in their
products today.  These products range from secure voice, data, and fax to
secure email, electronic forms, and software distribution, to name but a few.
With over a million such products in use today, what does the Clipper program
envision for the future of these products and the many corporations and
individuals that have invested in and use them?  Will the investment made by
the vendors in encryption-enhanced products be protected? If so, how?  Is it
envisioned that they will add escrow features to their products or be asked to
employ Clipper?

>>>> NIST:        Again, the Clipper Chip is a government standard which can
                  be used voluntarily by those in the private sector.  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."  You will have to
                  consult directly with private firms as to whether they will
                  add escrow features to their products.

Since Clipper, as currently defined, cannot be implemented in software, what
options are available to those who can benefit from cryptography in software?
Was a study of the impact on these vendors or of the potential cost to the
software industry conducted?  (Much of the use of cryptography by software
companies, particularly those in the entertainment industry, is for the
protection of their intellectual property.)


>>>> 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.  We would welcome the participation
                  of the software industry in a cooperative effort to meet
                  this technical challenge.  Existing software encryption use
                  can, of course, continue.

Banking and finance (as well as general commerce) are truly global today. Most
European financial institutions use technology described in standards such as
ISO 9796.  Many innovative new financial products and services will employ the
reversible cryptography described in these standards.  Clipper does not comply
with these standards. Will US financial institutions be able to export
Clipper?  If so, will their overseas customers find Clipper acceptable?  Was a
study of the potential impact of Clipper on US competitiveness conducted? If
so, is it available? If not, why not?

>>>> NIST:        Consistent with current export regulations applied to the
                  export of the DES, we expect U.S. financial institutions
                  will be able to export the Clipper Chip on a case by case
                  basis for their use.  It is probably too early to ascertain
                  how desirable their overseas customers will find the Clipper
                  Chip.  No formal study of the impact of the Clipper Chip has
                  been conducted since it was, until recently, a classified
                  technology; however, we are well aware of the threats from
                  economic espionage from foreign firms and governments and we
                  are making the Clipper Chip available to provide excellent
                  protection against these threats.  As noted below, we would
                  be interested in such input from potential users and others
                  affected by the announcement.  Use of other encryption
                  techniques and standards, including ISO 9796 and the ISO
                  8730 series, by non-U.S. Government entities (such as
                  European financial institutions) is expected to continue.

I realize they are probably still trying to assess the impact of Clipper, but
it would be interesting to hear from some major US financial institutions on
this issue.

>>>> NIST:        We too would be interested in hearing any reaction from
                  these institutions, particularly if such input can be
                  received by the end of May, to be used in the
                  Presidentially-directed review of government cryptographic
                  policy.

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.

Please report problems with the web pages to the maintainer

x
Top