Subject: RISKS DIGEST 14.89

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

RISKS-LIST: RISKS-FORUM Digest Friday 27 August 1993 Volume 14 : Issue 89

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

Contents:
Re: The Mars Observer (Ron Baalke at JPL via Ted Lee and Sandy Murphy)
Re: More Gripen Griping (Mary Shafer)
Be careful with your test cases! (Kenneth Wood)
Re: Quote for the Day (Wes Plouff)
Dial 1 first (Fredrick B. Cohen)
Re: Cisco backdoor? (Paul Traina)
sendmail debug option? RISK or friend? (Eric Allman)
Re: RISKS of elaborating on exploitation of known RISKS (Jim Hudson)
Call Privacy *67 faults (Ed Ravin, Stuart Moore)
Re: Electronic Education (Shyamal Jajodia)
Use of PIN as authenticator to humans (Jim Horning, Joe Konstan)
Call for Papers: IEEE Computer Security Foundations Workshop VII (Li Gong)

The RISKS Forum is a moderated digest discussing risks; comp.risks is its
USENET counterpart. Undigestifiers are available throughout the Internet,
but not from RISKS. Contributions should be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with appropriate, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive
problems, and other information to [email protected] (not automated).
BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

If you are interested in receiving RISKS via fax, please send E-mail to
[email protected], phone +1 (310) 455-9300, or fax +1 (310) 455-2364 for
information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR
GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone
PGN at +1 (415) 859-2375 if you cannot E-mail [email protected] .

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.

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

Date: Fri, 27 Aug 1993 11:32:36 -0600
From: Sandy Murphy <[email protected]> (via [email protected] (Theodore M.P. Lee))
Subject: Re: The Mars Observer

>From sci.space.news Fri Aug 27 11:32:16 1993
>Newsgroups: sci.space.news
>From: [email protected] (Ron Baalke)
>Subject: Mars Observer Update #2 - 08/26/93
>To: [email protected]
>Followup-To: sci.space

>Forwarded from:
>PUBLIC INFORMATION OFFICE
>JET PROPULSION LABORATORY
>CALIFORNIA INSTITUTE OF TECHNOLOGY
>NATIONAL AERONAUTICS AND SPACE ADMINISTRATION
>PASADENA, CALIF. 91109. (818) 354-5011
>
> MARS OBSERVER MISSION STATUS
> August 26, 1993
> 2:30 p.m. Pacific Daylight Time
>
> Communications with the Mars Observer spacecraft have not yet
>been restored, one and a half days past its planned insertion into
>orbit around Mars.
>
> Mission controllers at JPL continued through the night and
>morning with efforts to re-establish the necessary radio link with
>the spacecraft by cycling the various elements of the
>communications system.
>
> At 2:37 p.m. Pacific Daylight Time today, the continued
>execution of the command loss timer subroutine will try to position
>the spacecraft for optimum pointing and will switch antennas to try
>to restore communications.
>
> Project officials still do not believe that the propulsion
>tanks leaked or exploded at the time of their pressurization. The
>pressure in the tanks at launch was 285 pounds per square inch
>absolute (psia). As propellants were used during the three
>trajectory correction maneuvers, the pressure was reduced to about
>167 psia. Pressurizing the tanks would have raised the pressure to
>264 psia. Any greater pressure would require a failure of both of
>the in-series pressure regulators. The burst pressure specification
>of the tanks is 465 psia and actual test data ruptured tanks at 678
>psia. Flow restrictions limit the rate at which the pressure can
>increase. Analysis indicates that the probability that the
>pressure in the tanks would increase to the burst level within the
>9 minutes that the radio transmitter was off is less than 0.1%.
>
> Project officials are systematically evaluating the most
>probable sources of the cause of the spacecraft's failure to
>communicate.
>
> One such source which has been receiving considerable
>attention is the potential failure of the spacecraft's central
>clock, whose official name is the "redundant crystal oscillator,"
>or RXO for short. Proper operation of this device is required for
>operation of the spacecraft's central computers, which sequence the
>events on the spacecraft.
>
> The first hypothesis for the lack of communications pointed
>to the failure of the central computer to turn the transmitter back
>on. Failure of the central clock would prevent the central
>computer from doing its job. After sending commands to turn on the
>transmitter, switching to the backup clock was the next action
>taken by mission controllers.
>
> The central clock has been the focus of investigation because
>it contains transistors which have failed in other spacecraft
>applications using this type of clock.
>
> The launch of the NOAA-I spacecraft was delayed at the end of
>June 1993 when it was discovered that its RXO had failed. A
>subsequent investigation revealed that the RXO failure was caused
>by the failure of a 2N3421 transistor. Two of these transistors
>are used in each of the redundant halves of the RXO. Transistors
>from the same manufacturing lot as those in the NOAA-I RXO are
>installed in the Mars Observer RXO, making the reliability of Mars
>Observer's RXO suspect.
>
> The transistors fail when a weld between a gold-plated post
>and an aluminum wire breaks.
>
> This potential problem was discovered when Mars Observer was
>only 55 days away from Mars after the spacecraft had been in flight
>for over nine months. Because of the way that these transistors
>are used in the RXO, Mars Observer would be susceptible to losing
>its central clock function if one particular transistor in each
>half of the RXO failed.
>
> There is no alternative source of the central clock function
>in Mars Observer, and should the loss of this function occur, it
>would be a non-recoverable situation.
>
> The RXO, on its primary side, was working perfectly
>immediately before the pressurization activity. The last time the
>backup side of the RXO was tested was in a launch GO/NO-GO test on
>launch day, when it was also found to be working perfectly.
>
> Project officials were not, at first, concerned about the
>NOAA-I RXO failure because it would take a failure of two of these
>transistors to cause the loss of the central clock function. The
>spacecraft is not designed to automatically protect itself against
>more than a single failure in any piece of hardware.
>
> The restoring of the spacecraft's transmitter and the
>spacecraft's failure to act on ground commands could be tied to the
>loss of the central clock function. Project officials now surmise
>that one explanation for the loss of communications could result
>from the failure of the crucial transistor in each half of the RXO,
>or its failure to autonomously switch to the backup side. Then
>there would be no central timing function. This failure could have
>been induced by the shock of the pressurant valves operating during
>the propulsion tank pressurization event on Aug. 21, after which
>communications were not restored.

>[Ron Baalke, Jet Propulsion Lab, M/S 525-3684 Telos
>Pasadena, CA 91109 [email protected]]

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

Date: Thu, 26 Aug 93 15:40:49 PDT
From: [email protected] (Mary Shafer)
Subject: Re: More Gripen Griping

As far as I can tell, the real problem was control-surface rate limiting.
Cf. the YF-22 crash and the Space Shuttle ALT-5 multi-axis PIO.

I've flown a rate-limited configuration in a variable-stability Learjet
and it looked a lot the same, just before the safety trips gave the plane
back to the safety pilot.

I've read the articles in AvLeak and Flight International and looked at the
video a couple of times. My branch chief and some USAF handling qualities
guys are going to Sweden the end of next week, too. Not controls engineers,
handling qualities engineers.

Mary Shafer, Dryden Flight Research Facility

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

Date: Fri, 27 Aug 93 16:55:35 BST
From: [email protected]
Subject: Be careful with your test cases!

The Feedback section of the latest New Scientist relates the following
Computer Weekly story about an unfortunate programmer at an unnamed
bank. Apparently, the bank wanted to target its wealthiest customers
with a mailshot promoting various new services and the programmer in
question wrote a program to select the 2000 wealthiest customers from
the bank's records and to generate an appropriate letter for each. In
the process of testing the program, he made use of a fictitious customer
named Rich Bastard.

Unfortunately, as you may already have guessed, something went amiss and
every single one of the bank's 2000 prize customers received a letter
which began "Dear Rich Bastard, ..."

The risks involved? Well, for one thing, the hapless programmer lost
his job over the incident. More generally, I suppose it's just another
example of the way in which the complex interactions amongst program
development, testing, and maintenance can produce unpredicted and
undesirable consequences. The latter analysis is, of course, rather
generous to the programmer.

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

Date: Thu, 26 Aug 93 18:23:39 PDT
From: "Wes Plouff, LKG2-2/Y10, DTN 226-6780" <[email protected]>
Subject: Re: Quote for the Day (Cooper, RISKS 14.87)

Brinton Cooper quotes out of context, incidentally from a book whose
subtitle reads "the Hardware/Software Interface," a line he probably
intends as a subject for meditation. Saying "...minimizing the logic is
both complex and error-prone and, thus, is better left to a program,"
has ironic overtones in this forum. But I'd bet a cup of coffee that,
taken in context, it's sound engineering advice.

The workstations and PCs we use to read RISKS all contain semi-custom
and sometimes programmable logic chips. Reduction of the Boolean logic
equations, that is, minimization of AND-OR logic terms, directly
influences the size of the chips and thus their cost. Reducing large
Boolean equations by hand _is_ complex and error-prone, just like
programming large systems in assembly language would be. Thus it's a
safe bet that the book's authors are advocating the use of design
automation tools for real-world digital logic design.

Chip designers would argue, justifiably, that today's automated tools
decrease both design time and design risk. The RISK Cooper illustrates
is in mistaking a practical viewpoint for complacency.

Wes Plouff Digital Equipment Corp, Littleton, Mass.

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

Date: Fri, 27 Aug 93 04:56:12 PDT
From: Fredrick B. Cohen <[email protected]>
Subject: dial 1 first

Until recently, I had the good fortune of living in a telephone
exchange without this problem, but I had heard about it from others and
just couldn't believe it was so.

Why do I have to dial 1 before some numbers and not before others?
The computer at the phone company politely tells me to dial 1 first, or
to not dial 1 first depending on where the call is made to, but this is
little comfort for my autodialer making a series of several thousand calls
to send out FAXes. If they can tell me to add 1 or not, why can't they just
add it or not for me?

The Cisco router problem is particularly important because so many
people use this router to secure their network into isolated partitions.

[*** Some correspondence from Cisco doubts that this vulnerability
exists, and indicates that there is certainly NO INTENTIONAL TRAPDOOR.
An official response follows. PGN ***]

The risks of not receiving risks and risks not finding out about it
may be more severe than the risks of sending out risks for all to see. My
computer mail address was recently cut off, and apparently, every piece of
mail sent to me was not forwarded, and not reported as undelivered! I must
have missed a lot of risks that I am now vulnerable to and don't know about!
Then there is the question of who got those mailings I missed. Is there a
forger out there claiming to be me? Or am I the forger claiming to be him?
The finger command has a few minor problems worthy of note. One is that it
tells you if my mail has been removed from the mail queue, but not if I really
read it. Another is pointed out if you finger me at this mailing address.
Something about the plan containing false and misleading information.
FC

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

Date: Fri, 27 Aug 1993 11:15:23 -0700
From: Paul Traina <[email protected]>
Subject: Re: Cisco backdoor?

There are no known bugs in any software providing access-control-list
functionality in any current cisco software. There has only been one very
obscure bug that could cause a security problem in the history of our product,
and we immediately fixed this problem, published an immediate workaround, and
informed CERT of this problem. We have never, and will never implement any
sort of trapdoor or backdoor functionality which would allow bypassing of
ordinary security systems.

Paul Traina, cisco Systems

[***** NOTE ADDED ON 2 SEP 1993 TO THE ARCHIVE COPY:
PLEASE SEE RISKS-15.01 FOR FURTHER CLARIFICATION. PGN *****]

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

Date: Fri, 27 Aug 1993 11:17:09 -0700
From: Eric Allman <[email protected]>
Subject: sendmail debug option? RISK or friend?

In RISKS-14.87, PGN repeats the oft cited claim that the sendmail debug option
opens a security hole. Although it is true that earlier versions of sendmail
did allow debugging to enable mail to arbitrary addresses (including
programs), this hole should be well plugged by now.

Conversely, encouraging people to disable all debugging options may itself
cause problems. Many of the debug flags are exteremely useful when installing
and debugging config files. Scaring people into turning off all debugging is
not productive.

By the way, despite many claims to the contrary, the security hole used by RTM
was not an intentional back door -- it was a bug, plain and simple, as I've
published in the past (for example, see the C Advisor column in UNIX Review 7,
1 (January 1989)).

Eric Allman <[email protected]>

[Eric, Thanks for the clarification. BTW, are you convinced that
EVERYONE is using the unbuggy version? I know some systems that
do not get upgraded very often --- if ever! PGN]

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

Date: Fri, 27 Aug 93 11:58:02 EDT
From: [email protected]
Subject: Re: RISKS of elaborating on exploitation of known RISKS

PGN's reply on this subject ended with

> Does anyone care?

I've noticed that most people tend to focus their energies on whatever "fire"
happens to be blazing in front of them. I often go to a sysadmin with a clear
description of some hole in security (or procedures, or ...), only to be told
"I'll get to it when I can" (which means "never"). The only time that the
problem gets their attention is when an actual breach (or failure) occurs, and
peoples' work is lost. I can sometimes feel like taking Robert Morris'
approach and breaking something just so that it will get the attention it
deserves.

The preceding symptom is certainly not limited to computer systems. Here in
Massachusetts, there has been a rash of "child fallen out the upper-story
window" incidents this summer. The cause of the problem is children playing
in an upper-story room with an open window and only the screen for protection.
Now that 3 children have died and 13 more spent time in hospitals, local
organizations are distributing safety bars for windows.

I fear that the answer to Peter's question is "No, no-one cares, until someone
gets hurt."

Jim Hudson <[email protected]>

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

Date: Thu, 26 Aug 1993 21:54:50 -0400
From: Ed Ravin <[email protected]>
Subject: Call Privacy *67 faults

In New York, NY Telephone has managed to really screw up *67 caller ID
blocking -- a phone line defaults to "send caller number" mode, and dialing
*67 prevents the calling number from being displayed on the other side. If
you tell the phone company that you want your line to default to NOT send the
calling number, they give you "all call restrict" and you are supposed to dial
*67 if you WANT your number to be displayed on the other side.

Naturally, there's no way to tell which way a phone line defaults to -- except
for the reminder stickers that NY Tel sends you to stick on your phone. So if
you're using an unfamiliar phone, just what *67 will do is undeterminate. My
suspicion is that NY Tel did this to discourage people from trying to suppress
Caller ID, since they want the service to be as universal as possible. My
suspicions are furthered by the fact that when I installed a new line, they
didn't ask me whether I wanted to default to outgoing caller ID blocking or
not...

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

Date: Fri, 27 Aug 93 10:36:55 EDT
From: [email protected] (Stuart Moore)
Subject: Re: ... Call Privacy *67 problems (Kovanen, RISKS-14.88)

Perhaps the most annoying feature of the *67 call blocking services is that
they do *NOT* block your phone number for companies that purchase commercial
"caller ID" services (Automatic Number Identification) from their common
carrier. For example, when you call a catalog retailer's 800 number using the
*67 number, the retailer is still able to capture your phone number and add it
to their data base. The *67 service only blocks your number for people who
have the residential Caller ID service. The RBOCs that offer *67 call
blocking services do not seem to mention this distinction. As a result, many
callers are tricked into thinking that their privacy is protected through *67
when, in many cases, it is not.

Stuart C. Moore

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

Date: Tue, 24 Aug 93 14:28:10 EDT
From: Shyamal Jajodia <[email protected]>
Subject: Re: Electronic Education (Talbott, RISKS-14.86)

Before we go overboard with this abstraction replacing reality idea, consider
that books which we have been reading for much longer than we have had
computers or television are also abstractions. Audio Visual media may be a
great improvement on text but they cannot become reality. Otherwise we would
not go to ball games, and foreign countries, join demonstrations and meet
people for lunch. As in the case of any successful abstraction people's
appetite for reality is increased not diminished by the taste they get on the
television or computer screen. This actually goes back to the old debate in
artificial intelligence - "Can a computer become sentient?" The true question
there was not whether a computer can or not but "What is sentience?" In the
same way before we ask whether virtual reality can replace reality, we must
first ask what is it that we call reality.

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

Date: Thu, 26 Aug 93 16:34:45 -0700
From: [email protected]
Subject: Use of PIN as authenticator to humans (Swiss, RISKS-14.88)

Citibank gives out an ATM PIN with it's cards. Why in the world they
don't use that as telephone authentication..., I have no idea.

I do.

My bank has an explicit policy that bank employees are not to be told
PINs--PINs are only to be keyed into machines (which presumably encrypt
them before transmission). If a dishonest person who found your wallet
could do damage with your authenticator, imagine the damage that could be
done by a dishonest "inside person."

Jim H.

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

Date: Thu, 26 Aug 1993 18:11:59 -0500
From: Joe Konstan <[email protected]>
Subject: Re: Telephone verification

Tom Swift asks (in RISKS-14.88) about the common practice of asking for and
using a separate password (Mother's maiden name) for bank accounts rather than
using the already secret PIN.

I think Banks have the right idea here, though they often implement it poorly.
There are several good reasons for not using the PIN as a telephone
verification password.

1. Most banks don't give PIN access to phone clerks since the PIN
poses the most direct security risk (they must allow account
numbers to be identified and PIN+acct+card writer == ca$h).

2. Many smaller banks and credit unions can't change the PIN
without reissuing the card or account. While their PIN system
may be crippled, it is certainly wise not to risk compromising
it over the phone.

3. A pin is too easy to overhear over the phone.

4. What happens when you lose (forget) your PIN? You need some
way of calling to have a new one assigned.

Mother's maiden name isn't ideal, but almost every bank is open about the
fact that they'll take any pronounceable password. Accordingly, you can
make up a good mother's maiden name and have extra security.

American Express handles things somewhat differently. Usually they
ask a simple question like "is anyone else on the card with you?" or "how many
additional cardholders are on the account?" but they tend to ask more detailed
questions when you are talking major action (as opposed to simple queries).
Among the more interesting questions are ones that ask you to describe recent
transactions (once I was asked for the last meal I charged on the card) which,
seem like good general authentication questions that would only be troublesome
if the card were already stolen and used successfully.

Joe Konstan

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

Date: Thu, 26 Aug 1993 16:03:16 -0700
From: Li Gong <[email protected]>
Subject: Call for Papers: IEEE Computer Security Foundations Workshop VII

CALL FOR PAPERS
IEEE COMPUTER SECURITY FOUNDATIONS WORKSHOP VII
June 14-16, 1994
Franconia, New Hampshire
Sponsored by the IEEE Computer Society

The purpose of this workshop is to bring together researchers in computer
science to examine foundational issues in computer security. We are
interested both in papers that describe new results in the theories of
computer security and in papers, panels, and working group exercises that
explore open questions and raise fundamental concerns about current theories
of security. Possible topics include, but are not limited to:

access control distributed systems security
authentication formal methods for security
covert channels information flow
data and system integrity secure protocols
database security security models

We are also interested in examining the interactions and trade-offs between
computer security requirements and other system requirements such as
availability, dependability, and real-time, and in exploring foundational
security issues in emerging areas such as ubiquitous computing, multimedia,
and computer supported cooperative work. The proceedings are published by the
IEEE Computer Society and will be available at the workshop. Selected papers
will be invited for publication in the Journal of Computer Security.

Instructions for Participants: Workshop attendance will be by invitation only
and limited to thirty-five participants. Prospective participants should send
five copies of a paper (limit 7500 words), proposal for panel discussion or
working group exercise to Li Gong, Program Chair, at the address below.
Please provide E-mail addresses and telephone numbers (voice and fax) for all
authors and clearly identify the contact author.

IMPORTANT DATES: Author's submission: February 10, 1994
Notification of acceptance: March 11, 1994
Camera-ready final papers: April 11, 1994

Program Committee

Simon Foley, Univ. Col., Cork, Ireland
Virgil Gligor, U of Maryland, USA
Simon Lam, U of Texas, Austin, USA
Stewart Lee, U of Toronto, Canada
John McLean, Naval Research Lab, USA
Catherine Meadows, Naval Research Lab, USA
Michael Merritt, AT&T Bell Labs, USA
Jose Meseguer, SRI International, USA
Jonathan Millen, MITRE, USA
Chris Mitchell, U of London, RHNBC, UK
Robert Morris, DoD, USA
Ravi Sandhu, George Mason U, USA

For further information contact:

General Chair Program Chair Publications Chair
Ravi S. Sandhu Li Gong Joshua Guttman
ISSE Department SRI International The MITRE Corporation
George Mason University Computer Science Lab Burlington Road
Fairfax, VA 22030-4444 333 Ravenswood Avenue Bedford, MA 01730
+1 703-993-1659 Menlo Park, CA 94025 +1 617-271-2654
[email protected] +1 415-859-3232 [email protected]
[email protected]

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

End of RISKS-FORUM Digest 14.89
************************