Subject: RISKS DIGEST 17.40
RISKS-LIST: Risks-Forum Digest Thurs 19 October 1995 Volume 17 : Issue 40
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, etc. *****
Contents:
San Francisco 911 system *still* not working (PGN)
FAA Dallas-FortWorth ATC system outage (PGN)
Re: Fly NorthWest Airlines to unknown destinations (Peter Ladkin)
A new twist (or shimmy) on video E-mail (Espen Andersen)
Re: Risks in Java (Caveh Jalali, Geoff Mulligan)
Re: The Johnson Bug (Tracy Pettit)
Re: Microsoft Excel 1.40737488355328 (Ralph D. Clifford, Kenneth Albanowski)
Re: Risk of visiting wrong place on the Web (Ted Wong)
Re: Pinging the vacuum tubes (Sean Reifschneider, Mike Wilson, Paul Ferguson)
UH-60 and EMI (Howard Etkind)
Re: Presidential Black Hawk Crash (Mark Stalzer, George C. Kaplan,
Bruce Taylor)
Relevance of recent RISKS postings (helicopters, trains) (Rick Simpson)
Re: Another example of poor use of databases (Mark Brader and Bernard Lyons)
Risk of not knowing what something goes wrong (Martin Cohen)
Several topics from RISKS-17.39 (Frederick B. Cohen)
Re: Basic Flaws in Internet Security (Jonathan Kamens)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 18 Oct 1995 11:59:38 -0700
From: "Peter G. Neumann" <
[email protected]>
Subject: San Francisco 911 system *still* not working
San Francisco has been trying for the past three years to upgrade its 911
system, but computer outages and unanswered calls remain rampant. For
example, on 12 Oct 1995 the dispatch system crashed for over 30 minutes in
the midst of a search for an armed suspect (who escaped). The dispatch
system was installed two months ago as a temporary fix to the recurrent
problems, and it too has suffered unexplained breakdowns. Screens freeze;
vital information vanishes; and roughly twice a week the system crashes.
Dispatchers are not able to answer between 100 and 200 calls a day. Many
nonemergency calls are also being lost. [Source: article by Phillip Matier
and Andrew Ross, *San Francisco Chronicle*, 18 Oct 1995, p.A1.] The
reported extremely stressful working conditions seem similar to some of
the air-traffic controller woes.
------------------------------
Date: Wed, 18 Oct 1995 11:57:04 -0700
From: "Peter G. Neumann" <
[email protected]>
Subject: FAA Dallas-FortWorth ATC system outage
A power failure at 12:08pm on 17 Oct 1995 caused a 12-minute outage in the
air-route traffic-control computer system, affecting traffic in parts of
Texas, Oklahoma, New Mexico, Louisiana, and Arkansas. [News services. No
further details.]
------------------------------
Date: Wed, 18 Oct 1995 08:20:00 -0700
From:
[email protected]
Subject: Re: Fly NorthWest Airlines to unknown destinations (RISKS-17.38)
An article in Flight International, 11-17 October 1995, p8, entitled
`DC-10 misses Frankfurt runway--by 300km', considers the aftermath.
Brussels ATC attributed the original error to the Shannon ATC controller
entering an incorrect code to the ATC flight-plan data. The Irish Aviation
Authority denies this, saying the correct code was passed to London ATCC,
the last such ATCC before Brussels. Brussels maintains that when the
aircraft got to them, the destination data had been changed. `A senior
Brussels ATC official' confirms that NW52 was cleared by London ATCC as it
left the London control region to descend to 24,000 ft (I think they mean
Flight Level 240 but I'm not sure -- I'll use FL's anyway). The aircraft's
planned track for Frankfurt would have taken it over Belgium at FL370 under
control of Maastricht ATCC in the Netherlands, which handles traffic over
FL245 across Belgium.
NW52 also addressed Brussels as `Frankfurt' on contact, and numerous times
thereafter. Brussels ATC didn't question the `addressing error', apparently.
They were also cleared to a VOR, Bruno, that they didn't recognise, and
asked for the frequency. They were cleared for an ILS RWY 25L approach,
which is the same runway orientation as at Frankfurt, but with a different
ILS frequency. NW says that the crew must share responsibility, no matter
what happened with ATC (this is in any case what aviation law requires).
It looks like there is a lot for them to discuss.
Peter Ladkin
------------------------------
Date: Thu, 19 Oct 1995 06:36:14 -0700
From: "
[email protected]" <
[email protected]>
Subject: A new twist (or shimmy) on video E-mail
An article by Brian McGrory entitled "E-mail as evidence" in *The Boston
Globe*, 19 Oct 1995, p.1, (the article discusses this and also the issues
about companies' right to read employee E-mail) had the following anecdote,
which seems made for RISKS:
...A high-level executive with a Manhattan health company had a new
technology that allows users to tape themselves with a tiny camera
built into their monitor, send it through the system, and have it
appear on the recipient's screen as a talking, moving image [sounds
like a Connectix camera on a Macintosh to me].
One night, arriving at her hotel, she flipped open her portable
computer and began recording such a message. Sitting before her
laptop in the privacy of her room, she teasingly disrobed, performed
what a corporate lawyer later would describe as a "shimmy," and
purred to the intended recipient, a fellow married colleague, "Hurry
to the hotel and here's what you get tonight."
Problem is, she struck the wrong button on her computer, and the
video flashed on the screens of more than 400 employees throughout
her health company -- subordinates, bosses and people who had never
met her before."
The article goes on to describe how bootlegged copies of the message was
distributed around the company, and appeared on floppy disks sold at
computer fairs. [Health fairs, too, perhaps? PGN]
And I thought Oliver North had set the record for embarrassing E-mail
screw-ups.
Espen Andersen <
[email protected]>
------------------------------
Date: Mon, 16 Oct 1995 21:22:40 -0700
From:
[email protected] (Caveh Jalali)
Subject: Re: Risks in Java
If we are going to "analyze" java security, let's keep in mind that there is
an important distinction between the language (java) and the machinery which
runs the java program.
Java is a general-purpose programming language along the lines of C/C++.
So, there is no doubt that its expressive power overwhelms our
theoretician's abilities to predict java-programs behavior -- this is where
we start getting into the halting problem, computability and other black
magic. Basically, i don't think we can "trust" programs written in any
*useful* programming language.
The area where we can (must) build trust is the computing base.
Traditionally, this has been the OS, but in the case of java, it is the java
interpreter (such as netscape 2.0 and hotjava). The browser is now the TCB
(trusted computer base) for all practical purposes...
And, to address the specific concern about applets spamming the net -- from
what I've seen, applets are only allowed to connect to the server that
supplied the applet in the first place (by default). The worst thing one
could probably pull off is to spam oneself.
------------------------------
Date: Mon, 16 Oct 1995 21:56:09 -0600
From:
[email protected]
Subject: Re: Risks in Java
I think that before you go citing risks you out to read the Java
security documents and Java mail archives first. They go into a lot of
detail discussing for the the "risks" that you mention and show that
they are not risks associated with running Java code. [...]
The Java enabled browser can be configured so that applets loaded from
have access to the local machine or local network, applets loaded from
the local net can be allowed access to the local machine or local net,
applets loaded from non-local networks can denied access to the local
machine or network, so no this isn't a risk.
> META-RISKS: I have posted these concerns to a variety of forums ...
Again, before you go blindly posting these messages, why don't you read
the mail archives first and save everyone from having to repeat the
discussion every month. [...]
Please consider reading the Java papers and mail archives before suggesting
yet the same Java risk.
geoff
------------------------------
Date: Tue, 17 Oct 1995 10:32:22 -0700
From: Tracy Pettit <
[email protected]>
Subject: Re: The Johnson Bug (RISKS-17.39)
I think you had it correct when you called this folklore. I have no
previous knowledge of this, but it sounds a lot like the stories about
poisonous snakes wrapped in imported carpets or burglary victims finding
their pet Doberman choking on severed fingers. I believe there have been a
book or books published on these types of stories, that everybody has heard
of (second hand) but can never be traced to an origin.
Has anybody checked the records of CSU to see if their ever was an
instructor by the name of Gerry Johnson?
Think about it. Being good computer people, can we think of any piece of
code capable of this? What would it be doing in an IBM 370 MVS operating
system written (in the early to mid 1970s?) long before personal computers,
and networking as we know it today was not much more than a few isolated
experiments? What is "IBM's entire global network"? (Did they invent the
Internet long before the U.S. military thought of experimenting?) Just how
would one go about "boarding up" a display booth? Most of them can hardly
stand up on their own, much less support a load of lumber.
The real risks are bad enough. It doesn't take more than a little
thinking to avoid chasing stories about a guy with a big blue ox.
------------------------------
Date: Tue, 17 Oct 1995 05:43:02 -0700
From: "Ralph D. Clifford" <
[email protected]>
Subject: Re: Microsoft Excel 1.40737488355328
>[I have heard some reports that this flaw is actually an intentional
>feature intended to detect copyright ripoffs.... PGN]
Usually, these inserted flaws are (should be?) in the non-executable
portion of a program. Often, a section of code that will never be executed
is inserted. To be most effective, this code should, in fact, be
unexecutable--containing a zero divide, for example.
The practice stems from a court case, Frank Shepard Co. v. Zachary P.
Taylor Pub., Co., 193 F. 991 (2d Cir., 1912). In the case, the publisher of
a legal research book (Shepard's citator) inserted lists of citations for
cases that did not exist. When 138 of these showed up in a competitor's
publication, the court presumed that the second work had copied the first.
Thus, I have no doubt that Excel has "bugs" inserted in it to allow
Microsoft to more easily prove code copying. I would be surprised,
however, if these bugs were inserted into effective code.
Ralph Clifford, Associate Professor, S. New England School of Law
------------------------------
Date: Wed, 18 Oct 1995 08:49:28 -0700
From: Kenneth Albanowski <
[email protected]>
Subject: Re: Microsoft Excel 1.40737488355328
I have no idea whether the "mysterious figure" is really a copyright trap,
but you can't rule it out this easily. Have we all forgotten the days of
reverse engineering, and "borrowing" code from other programs? Admittedly,
doing this for the calculation engine of Excel seems a rather odd
pursuit, though.
Another variation comes to mind, though. Has Microsoft ever licensed out
source or executable code to other companies. If anyone used the code in a
"black box" form, this would be a very simple way to track the licensed
code, and verify it hadn't been distributed improperly.
Kenneth Albanowski (
[email protected], CIS: 70705,126)
------------------------------
Date: Tue, 17 Oct 1995 07:59:02 -0700
From:
[email protected] (Ted Wong)
Subject: Re: Risk of visiting wrong place on the Web (RISKS-17.39)
If Marketry doesn't already have my E-mail address, surely sending them
E-mail will ensure that they get it. Given the unrepentant nature of many
cybermarketers, I fear that my address would go into their list and my
(valid) complaint would go into the bit bucket.
Perhaps we're better off sending their name to the owner of the Blacklist
of Internet Advertisers (*)...
(*)
http://www.cco.caltech.edu/~cbrown/BL/
Ted Wong <
[email protected]> Isis Distributed Systems, Inc., Ithaca, New York
http://www.cs.cornell.edu/Info/People/thwong
------------------------------
Date: Tue, 17 Oct 1995 08:40:41 -0700
From: Sean Reifschneider <
[email protected]>
Subject: Re: Pinging the vacuum tubes (Wernick, RISKS-17.39)
Sometime this summer (of '95) I read some IBM literature on their new series
of disc drives. The new drives had some very interesting features including
"ping"s to check drive health and prevent corruption of data.
The "TravelStar" (I believe that's the name) was their series of notebook
computer drives. They had a shock sensor which would alert the drive's
onboard controller to delay writes when you drop your notebook. I don't
remember the number but recall it being able to sustain a fairly large shock
without corrupting data.
The "UltraStar" was described as having audio, vibration, and current
sensors installed which were used to detect impending failure of drive
components. This feature (in theory) could have come in handy when (at 3am)
one of our drives started squealing.
This sounds good in theory, but how does it report the problems? The method
of reporting was never mentioned in the literature. One common method is to
flash the drive light in some pattern to alert you. Probably not used as
most drives don't have LEDs these days (just small footprint connectors
specially designed NOT to work with any of the LEDs you have on hand).
Besides, most computers have the drives installed internally and the LED on
the front of the box shows CONTROLLER activity. If the box is in a data
center, it may never be looked at anyway.
The better solution would be to have some SCSI command or inquiry that would
return information about the drives health. Now we run into the problem of
how do we read it. Most OSs would not have the code to check that
information. One could probably write a program which would inquire that
information from the drive, if one had a familiarity with SCSI programming.
I've also heard that 4mm DDS tape drives store statistics on read and write
errors. Apparently they also have several error correcting modes ranging
from none amazing. Yet again, it seems most backup software doesn't worry
about this. I'd presume these features would be configurable and/or played
up in the literature, but I've not run across any mention of these features
in the backup software I've used (no doubt there is some out there though).
But it's the thought that counts... I'm sure I'm not the only one who is
running an UPS (at home) without the monitoring connection to the computer
hooked up.
The RISK is that the thought isn't enough. A coordinated effort is required
for the scheme to work. If you don't get the "lower-order acolytes" to ping
your tubes, the pong means nothing.
Sean
------------------------------
Date: Tue, 17 Oct 1995 01:17:11 -0700
From: "Mike Wilson, ICL Medical Portfolio" <
[email protected]>
Subject: Re: Pinging vacuum tubes (Wernick, RISKS-17.39)
This reminds me of a story I heard on BBC Radio a few years ago: at an
atomic power station, a safety inspector needed to regularly check certain
bolts were done up tight. What better way than to put a spanner on the bolt
and give it a tug ? After a few months of weekly inspections like this,
bolts started shearing off. It took quite an investigation to find the cause
of all those broken bolts.
Mike Wilson, ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1
3PX, UK
[email protected] At home
[email protected]
------------------------------
Date: Tue, 17 Oct 1995 04:19:56 -0700
From: Paul Ferguson <
[email protected]>
Subject: re: Pinging the vacuum tubes (Wernick, RISKS-17.39)
During our session (The Internet and Beyond) at the National Information
Systems Security Conference (formerly known as the NCSC Security Conference)
in Baltimore last week, Marcus Ranum made a reference in his presentation to
`waving a dead chicken over it' as an analogy to, what I like to call,
Voodoo Technology.
While humorous in context, the content issue is one of risks which are not
always readily apparent. Without proper testing and verification, network
security products intentioned to provide some level of access control,
application proxy service, or other types of security may not be the panacea
that it was envisioned.
The comparison is that while product marketing may claim that it is
bulletproof, the engineering verification folks may have simply `waved a
dead chicken over it' and muttered a few incantations. Take the time to test
and verify.
Caveat Emptor.
Paul Ferguson, cisco Systems, Consulting Engineering, Reston, Virginia USA
[email protected]
------------------------------
Date: Tue, 17 Oct 1995 05:03:54 -0700
From: Howard.Etkind%
[email protected]
Subject: UH-60 and EMI
Concerning the VH-60 (the presidential version of the common UH-60 Black
Hawk) that has suspected EMI issues.
In the late 80's, I was involved as a system safety engineer on the UH-60
program and the development of the VH-60 and EMI hardening was a major
design requirement. I am familiar with the EMI cases and they have usually
involved a nose low attitude at impact with the stabilator in the full down
position. What used to happen is that the crews would use certain very high
power radio towers (such as Voice of America towers) a way points for
navigational reasons and we would see some uncommanded inputs a particular
times associated with certain power levels and frequencies. A trained
aircraft accident investigator can tell with reasonable certainty, the
attitude and stabilator position at impact.
Any radio beam that could cook or burn human flesh is well above the design
hardening of ANY aircraft out there flying around, executive use transport
or not! This case sounds to be more like an urban legend than a real event!
Howard Etkind
------------------------------
Date: Tue, 17 Oct 1995 10:31:26 -0700
From:
[email protected] (Mark Stalzer)
Subject: Re: Presidential Black Hawk Crash (RISKS-17.39) [alt.conspiracy?]
It seems like Mr. Coley's note in RISKS-17.39 on the Marine Corps'
helicopter crash is more appropriate for alt.conspiracy. Is it really
believable that the US has a giant Star Wars death ray that can microwave
troops from 4 miles away and that it accidentally cooked a Presidential
helicopter?
I did check carefully to see if the post was made on April 1, but
sadly, it was not.
Mark Stalzer,
[email protected]
------------------------------
Date: Mon, 16 Oct 1995 21:39:27 -0700
From:
[email protected] (George C. Kaplan)
Subject: Re: Presidential Black Hawk Crash (RISKS-17.39)
Was this story supposed to illustrate the RISKS of EMI? RISKS of
believing unlikely stories from the net is more like it.
Coley tells us about a mysterious helicopter crash and subsequent cover-up
without offering *any* citations that can be checked. Only one source
is quoted by name: the man who "uncovered" the conspiracy.
One passage in particular sent my hoax detector past redline:
> "Those men were burned and there was almost no bleeding
> from their wounds." [...]
Let's see. People were burned, but clothing was unharmed. Sounds like
spontaneous human combustion to me.
------------------------------
Date: Tue, 17 Oct 1995 09:21:05 -0700
From: Bruce Taylor <
[email protected]>
Subject: Re: Presidential Black Hawk Crash (RISKS-17.39)
Craig,
What's your relationship to this story? The reasons why I ask are these:
First: The President does not travel from the White House in Black Hawk
helicopters -- he uses a rather old Sikorsky version which has been in
service since the Vietnam War.
Second: What qualifications does your apparent source, Mr. Owens, have for
deciding that a report on the crash is false, since he is not aware of which
helicopter model is used by the President?
Third: There appears to be no relation to comp.risks .
So, what's your reasoning?
- Bruce Taylor
------------------------------
Date: Tue, 17 Oct 95 10:04:29 -0500
From: "Rick Simpson" <
[email protected]>
Subject: Relevance of recent RISKS postings (helicopters, trains)
I have difficulty in seeing how two postings in RISKS-17.39 are relevant to
COMP.risks (my emphasis). They are
Presidential Black Hawk Crash (Craig J. Coley)
How to derail a train (Bob Frankston)
Both were moderately interesting, but seem to have nothing to do with risks
of using computer-based systems. I suppose that one could infer that
computers were used to control or direct the supposed microwave transmitter
in the first story. The jumper wire in the Amtrak derailment may have been
intended to mislead a computer-based signal system, but the poster seemed
more concerned with the publication of "how to" information than with
computer-related errors.
While both articles are worthy topics of discussion, if comp.risks is going
to stray off-topic into the general risks of living in the industrialized
world, it runs a risk itself of becoming unfocused and, eventually, unread.
Rick Simpson, IBM T. J. Watson Research Center, P.O. Box 704, Yorktown Hts,
New York 10598
[email protected] +1 914 784 6712 fax +1 914 784 6306
[Besides, it was an OLD story. But the relevance issue has come up
repeatedly. This is a forum on risks to the public in computers and
RELATED SYSTEMS. Risks of interference are rampant (see my book,
Computer-Related Risks, for example), and need to be protected against --
even though they are not specifically computer relevant. The death of
a pacemaker patient due to interference is clear evidence of that. PGN]
------------------------------
Date: Mon, 16 Oct 1995 21:11:29 -0700
From:
[email protected] (Mark Brader)
Subject: Re: Another example of poor use of databases (RISKS-17.39)
> From the Electronic Telegraph <
http://www.telegraph.co.uk/>, 1995-10-10:
> Victim of gas blast sent 3230 pound bill (=A3230), by David Graves
Let me guess. "=A3" is a MIME escape for a pound sign [...],
and the bill was really for 230 pounds. Right?
Mind those character sets, folks! This reminds me of the item in
comp.dcom.telecom / Telecom Digest a few months back where a statement
intending to say that you should "dial `0'" in a certain situation came out
as "dial 302".
The latest wrinkle in this is the appearance of mail transport software
that detects characters with the high bit set and automatically converts
the whole message to MIME format in the hope that this is the safest
thing to so -- which leads to things like "=A3" turning up in mail
between people who have no idea what it means. Until now, a character
set mismatch might cause some characters to come out wrong, but at least
the number of characters didn't change.
Mark Brader,
[email protected] SoftQuad Inc., Toronto
[Bernard Lyons <
[email protected]> mused on the ambiguity of
pounds weight vs Pounds Sterling, and suggested using the 3-letter SWIFT
codes instead, where Pounds Sterling are GBP, US Dollars are USD,
Japanese Yen are JPY, etc.
RISKS has POUNDed on this one before. I left the =A3 in because I try to
avoid microediting; besides, I might have miscorrected it, which would have
resulted in further flames. PGN]
------------------------------
Date: Tue, 17 Oct 1995 12:43:05 -0700
From: Martin Cohen <
[email protected]>
Subject: Risk of not knowing what something goes wrong (Wernick, RISKS-17.39)
Even worse is a system that does not know that something has gone wrong even
when it has.
An example - some of the latest Intel motherboards do ***NOT*** support
parity memory at all!
I always felt that parity checking was not enough - I want ECC memory.
Now, if memory goes bad, who knows what will happen?
------------------------------
Date: Mon, 16 Oct 1995 18:04:15 -0700
From:
[email protected] (Dr. Frederick B. Cohen)
Subject: Several topics from RISKS-17.39
The recent issue of RISKS had so many items that I wanted to comment on
that I just had to write in:
> Subject: Basic Flaws in Internet Security
On average, there are about 5 bugs of similar severity found in the
Internet every month. This one was nothing special - in fact, just a
special case of known IP spoofing problems throughout the Internet.
> Subject: Pinging the vacuum tubes (Re: Univac episode, Williams, RISKS-17.38)
There is a field called Built-In Self-Test that concentrates on testing
components at startup, during operation, and at other times. Every PC I
know of does a set of start-up tests.
> Subject: Risks in Java
Risks in Java are being widely discussed on the Internet, and the vast
majority of people I interact with find a great deal of risk in it.
> Subject: Effective use of the Internet
So-called spamming is getting more frequent on the Internet. At this
point, several mailing list owners are working on anti-spamming software
to detect the most simplistic threats. They look at headers in multiple
mailing lists and if they match, the messages are blocked until the list
manager checks them.
There have also been a recent series of attacks where people use the
newsgroup "cancel" command to remove other users' messages from mailing
list distributions.
More similar attacks seem certain in the near future.
> Subject: Risk of visiting wrong place on the Web
Junk mail is a legitimate marketing technique. Like it or not, it is
going to happen. I have been accused of it myself. The cure is to add
integrity to the Internet, something that few of the Internet designers
seem to understand these days.
> Subject: Analysis of Human Factors and Outages
There have been several similar studies in the past and several books
have been written on how to reduce these things.
> Subject: Re: Microsoft Excel 1.40737488355328
I was creating a simple spreadsheet in Excel for my father-in-law a few
months ago and noticed that it failed to copy a cell properly. The cell
didn't have 1.40737488355328 in it. Eventually, I abandoned Excel and saved
the file in 123 format. When I ran it under 123, it gave the right answers.
I haven't used Excel since, and don't plan to ever use it again. If you
can't copy or add correctly, you're a pretty poor spreadsheet. [The 17 Oct
1995 Edupage has an item on the new flaw in the Windows 95 version of Excel
7.0, discovered by a Houston financial consultant, where "a cell linked to a
cell in another spreadsheet was not updating its information properly."
(*Houston Chronicle*, 14 Oct 1995, C1) PGN]
-> See: Info-Sec Heaven at URL
http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
------------------------------
Date: Tue, 17 Oct 1995 09:42:47 -0700
From: Jonathan Kamens <
[email protected]>
Subject: Re: Basic Flaws in Internet Security (RISKS-17.39)
I saw their attack in one of the security newsgroups, and I was
unimpressed by it. It doesn't report anything new.
People have known for years that NFS was vulnerable to spoofing attacks.
This is not news. People have known for years that even the commonly-used
authenticated file-service protocols (e.g., Kerberized NFS, AFS)
authenticate only the connection without authenticating the file data being
sent over it. This is not news.
The solutions to this problem are known and have been for a long time. The
easy solution is to install security-related binaries on the local disk
instead of on a fileserver. Of course, this blows the diskless workstation
model, but I think that was on its way out anyway :-). The hard solution is
to fix the file-service protocols to integrity-protect and/or encrypt their
data (and to get people to use secure file-service protocols like Kerberized
NFS or AFS, instead of relying on tried-and-true insecure NFS). Perhaps
some work in that direction will arise from the attack published by Brewer
et al, and that would be a good thing to come out of what they published,
but otherwise, I don't see much point to it.
(An aside: I suspect that one of the reasons why integrity-protection
and/or encryption weren't put into Kerberized NFS and AFS originally
was that such protection significantly increases the CPU load on the
servers and clients using it; however, CPU speeds have increased so
much in the past few years that perhaps now we can spare the cycles to
make our files secure.)
Jonathan Kamens | OpenVision Technologies, Inc. |
[email protected]
------------------------------
Date: 6 September 1995 (LAST-MODIFIED)
From:
[email protected]
Subject: ABRIDGED info on RISKS (comp.risks)
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <
[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address only if different from FROM:]
INFO [for further information]
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. [...]
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.
RISKS can also be read on the web at URL
http://catless.ncl.ac.uk/Risks
RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]
------------------------------
End of RISKS-FORUM Digest 17.40
************************
