Subject: RISKS DIGEST 17.43
RISKS-LIST: Risks-Forum Digest Tuesday 31 October 1995 Volume 17 : Issue 43
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:
New air quality monitoring technology (Steve Bellovin)
Sydney airport control and future computer networks (Wade Bowmer)
Traffic Signaling Problems in Chicago Train/Bus Crash (Dan Hartung)
Safe Languages (Michael Quinlan)
Mr.Bill Gates: MS software essentially bug-free (Klaus Brunnstein)
SMTP chicken and the social contract (Bear Giles)
What the large print giveth, the small print taketh away. (A. Padgett Peterson)
HotJava 1.0 alpha 3 security issues (Drew Dean)
Re: Risks in Java and Beyond Java (Wade Bowmer)
Re: "core" files (Jeffrey Mogul)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 25 Oct 1995 21:52:18 -0400
From: Steve Bellovin <
[email protected]>
Subject: New air quality monitoring technology
*The New York Times* (22 Oct 1995) carried a frightening article on some new
air pollution control technology that's being tried out in California. It
seems that Federal regulations require that all 1996 model cars have sensors
to notify drivers if the pollution control mechanisms aren't working; if
there's a failure, it's supposed to be repaired right away. But what if the
motorist decides not to bother?
The California Air Control Board has decided it would be a good idea to hook
these sensors up to a transponder, very similar to the ones to be used by
toll readers. Every time you drive by a transmitter, it sees if your car's
emission control system is working properly. If not -- well, you'll be
mailed a notice for starters, though the article noted the possibility of
summonses, denial of registration, etc. An experiment is underway.
Naturally enough, civil liberties groups and automotive manufacturers are
not fond of this whole scheme. But the board sees it as a ``perception
problem'' -- and the public will love it once they see how ``convenient'' it
is. Meanwhile, other states are watching, since California has
traditionally led the nation in pollution control laws.
I'm not sure any more needs to be said here. Even if the system works
exactly as designed, it's a frightening concept. I leave it to the readers
of this digest to consider how many new and creative failure modes a system
like this can generate -- and how easily it could be abused...
--Steve Bellovin
------------------------------
Date: Wed, 25 Oct 95 10:26:45 +60000
From:
[email protected]
Subject: Sydney airport control and future computer networks
The reliability of Pittsburgh Airport is a recurring subject in RISKS, and
as other readers have pointed out, it is not alone. Well, I have a new one
for you: Sydney Australia.
We have recently had a third runway built (amid much controversy, but that's
by the by) and so the control tower had to be moved again. A large
international telecommunications company contracted to supply and install
a state-of-the-art computer controlled voice-switching system using a
combination of off-the-shelf hardware - mainly PC's running DOS. What
they didn't tell the airport authority (which has problems of it's own)
is that they hadn't even built a prototype of the system.
In a nutshell, it's bad, really bad. I'm a hazy on the details because I
have it second-hand - a relative of mine is one of a score of people
expected to support this thing, but none of them has the right background
nor the right training and he's leaving in a week, anyway.
The new tower is at least six months overdue and is far from being fully
functional. Apparently someone is running a book on when it will finally
be fixed; general consensus is about April next year: more than a year late.
The RISKS? Oh, that's easy. An untested design; ignorant support staff;
and the politics of the authority. At least the risk to human life will
be on the Ground, not in the Air (small comfort, I know). But at least you
now know why flights will have trouble landing at Sydney!
Wade Bowmer
------------------------------
Date: Thu, 26 Oct 95 23:50:39 -0500
From: Dan Hartung <
[email protected]>
Subject: Traffic Signaling Problems in Chicago Train/Bus Crash
Investigators from the National Transportation Safety Board and other
agencies looking into the tragic crash of a commuter train with a school bus
near Chicago (at this writing, seven students are dead), report very
preliminary findings regarding the traffic light and railroad signaling
integration.
Early news reports indicated that the system may have malfunctioned.
More troubling, however, is the apparent finding that the system
was working properly, but under such severe real-world restraints
that it was arguably incapable of performing its designed task.
Reportedly, a track sensor placed 1/8 miles away (~20 seconds at
70 mph) activates the traditional flashing lights and bells and
after a short delay the gate. It simultaneously notifies the
adjacent traffic light controller that it needs to cycle into
a position where traffic that is possibly backed up (or just too
long for the short stretch of street, as this bus was: 38+ feet
on 32 feet of pavement behind the white line) may proceed on a
green light. Sounds sensible enough. However:
-- the first step is to flash the DON'T WALK light
-- next, steady DON'T WALK and yellow on the cross traffic
-- sufficient stopping time allowed for 40mph+ traffic
-- red on cross traffic
-- delay for red-light-blasters
-- and only then may a green light appear.
Under optimal conditions, the bus may have had a maximum of 2
seconds to proceed.
Clearly, a nexus of several risks, not limited to those of the failure of
computer systems, but encompassing the human factor (and "sensibly" allowing
for mistakes and intentional rule-breaking), the combination of several
mission-critical tasks (get pedestrians out of way, etc.), and the crossing
of several different modes of travel (commuter trains, pedestrians, local
traffic, and commuter i.e. through traffic).
The question here is very nearly not why did the system fail? but
why did it take so long to fail?
Daniel A. Hartung
[email protected] www.mcs.net/~dhartung/
------------------------------
Date: Fri, 27 Oct 1995 02:07:02 GMT
From:
[email protected] (Michael Quinlan)
Subject: Safe Languages (Re: da Silva, RISKS-17.42)
In the 1970s I worked with a "safe" Fortran implementation designed to be
used by students. It prohibited access to anything except a small subset of
operating system services to prevent students from causing problems with
the system.
I found that I could put machine language code in named COMMON sections and
then call them as subroutines, letting me get around the restrictions built
into the language.
The risk is in assuming that all implementations will be bug free and that
all routes to circumventing the restrictions of the language will be
anticipated and correctly designed around.
Michael Quinlan
[email protected] http://www.primenet.com/~mikeq
------------------------------
Date: Fri, 27 Oct 1995 10:31:43 +0100
From: Klaus Brunnstein <
[email protected]>
Subject: Mr.Bill Gates: MS software essentially bug-free
In an interview for German weekly magazine FOCUS (nr.43, October 23,1995,
pages 206-212), Microsoft`s Mr. Bill Gates has made some statements about
software quality of MS products. After lengthy inquiries about how PCs
should and could be used (including some angry comments on some questions
which Mr. Gates evidently did not like), the interviewer comes to storage
requirements of MS products; it ends with the following dispute (translated
by submitter; at some interesting points, I added the German phrase):
Focus: But it is a fact: if you buy a new version of a program to
overcome faults of an old one, you unavoidably get more features
and need more storage.
Gates: We have strong competitors and produce only products which we
believe to be able to sell. New versions are not offered to
cure faults. I have never heard of a less relevant reason to
bring a new version on the market.
Focus: There are always bugs in programs.
Gates: No. There are no essential bugs ("keine bedeutenden Fehler") in
our software which a significant number fo users might wish to
be removed.
Focus: Hey? I get always crazy when my Macintosh Word 5.1 hides
page numbers under my text.
Gates: Maybe you make errors, have you ever thought about that? It
often appears that machine addicts ("Maschinenstuermer") cannot
use software properly. We install new features because we were
asked to. Nobody would buy a new software because of bugs
in an old one.
Focus: If I call a hotline or a dealer and complain about a problem, I have
to hear: `Get the update to version 6`. Everybody has such
experiences. This is how the system works.
Gates: We pay 500 million $ a year for telephone advice. Less than 1% of
calls which we get has to do with software bugs. Most callers wish
advice. You are kindly invited to listen to the millions of calls.
You must wait for weeks until one complains about a bug.
Focus: But where does this feeling of frustration come from which unites
PC users? Everybody is confronted every day that programs do not
work as they should?
Gates: That is talking, following the motto: `yes, I also know about this
bug`. I understand this as sociological phenomenon, not as
technical.
The RISK? While there is NO risk that experienced users believe Mr. Gates,
there are 2 serious ones: first, that politicians (who rarely experience the
lowlands of PCs but develop their "political visions" from their
unexperience) may believe him. Second and worst: that Mr. Gates and his
enterprise believe what he is saying, and act accordingly :-)
Maybe someone can inform Mr. Gates that it was HIS enterprise which recently
distributed the first Macro virus WordMacro.Concept on a CD-ROM to OEM
customers, in July, and to participants of a Windows 95 seminar in Germany,
in September); but indeed, this is NOT a BUG BUT an ATTACK on unaware users :-)
According to a German saying those whose reputation is corrupted may live free
and easy ("Ist der Ruf erst ruiniert, lebt sich's doppelt ungeniert!")
Klaus Brunnstein (October 27,1995)
[... und nicht ingeniert (which is not pronounced engineert!) PGN]
------------------------------
Date: Fri, 27 Oct 1995 11:42:19 -0600
From: Bear Giles <
[email protected]>
Subject: SMTP chicken and the social contract
It's currently fashionable to say that the 'net is a social anarchy,
and at the newsgroup level it is to a large extent. But under this
level is the technical and social contracts which allow the Internet
to function as a quasi-cohesive whole.
Anyone familiar with the role of RFCs and the old ARPAnet gods knows
what I'm referring to.
Recently, I've encountered a situation which suggests that the social
contract of the technical level of the internet is breaking down, and I am
hereby making a dire prediction of a growing problem with a problem I shall
call "SMTP chicken," to be described below.
First, background on the social contract:
In brief, I made a response to several technical articles in a sci
group. The next morning I found a response to such article with what
I consider extremely juvenile rejoinders for a sci newsgroup. Yet all
articles and messages were signed with a company name and the job title
of "Principle Scientist."
Naturally, I wondered if this might be some soon-to-be-ex student
employee or the like giving himself a backdoor promotion, or if this
might possibly be a legitimate expert who was simply speaking outside
of his field of expertise or who misunderstood the original question.
So I exercised my rights under the social contract dating back to the
first mail protocols on ARPAnet and politely asked his postmaster to
verify this individual's job title.
In response I got a scorching letter accusing me of "wasting gov't
resources and time," claiming that a fax complaint had already been
sent to the Inspector General's office, and demanding that this
complaint be filed in my permanent record.
(My offense was apparently that, while I posted all articles from my
academic account on my own time, I sent the one-line query to postmaster
from work as I caught up with my morning mail.)
Subsequent investigation shows that all further mail to "postmaster"
is autoresponded with a "go away, you're bothering me" message and
a suggestion that people who are really desperate to chat contact
him through snail mail.
This autoresponse is a direct violation of one of the most critical roles
of postmaster - to be a human being who can be contacted in case that mail
system starts causing problems to the rest of the world. If his system
starts flooding the net with bogus mail, nobody has any way of contacting
him... and that's critical in eliminating games of SMTP chicken.
(The other role of postmaster is to verify user information at the remote
site, an obvious need in the early days of the net before the implementation
of "finger" and WWW home pages. Even today it is still a useful function to
verify, for instance, that the "legal counsel" who is demanding you remove a
copyright violation really is a lawyer with the authority to make such a
demand on the behalf of the client... or to even understand if a copyright
violation even occurred.)
Further investigation revealed that this "company" is actually a system
running common Windows nettools (Eudora for mail, Forte Agent for news) and
connected via a SLIP connection to a local ISP. As mentioned, the "company"
is not listed in the phone book (at least, not under the name provided), and
the sole name and address provided matches that individual's publicly listed
residential address. For whatever reason, this person had elected to pay
the additional fee to get DNS (or at least MX) service rather than using in
address under the ISP's address space.
The problem, of course, is that since he (and not the ISP) receives
mail sent to postmaster he is bound to the technical and social contracts
for the interoperation of the 'net. The technical contracts are no
problem -- the software and his ISP ensure that these standards are
met.
But apparently this (and all?) ISP didn't bother with the standard
sysadmin/postmaster lecture to the people requesting DNS service.
"After all," they might argue, "it's only a PC so how much harm can
they do?"
This brings us to the game of "SMTP chicken."
Let's assume that we have _two_ people with such autoresponders (and
I've heard of several such autoresponders already being placed on the
'net.) One person could innocently respond to the other person's
posted comments and immediately create a mail loop.
Each time through the system the mail will grow by a few lines, as
each quotes the original material and adds a few lines proclaiming
that it ignores unsolicited mail. Then it's off to the other side
for _it_ to respond to.
Since the autoresponders (probably) won't save such messages, neither
individual would be aware that their mail message has grown to a
monster of 1000, 2000,... 10,000,... a million?! lines. It will be
like the ISP systems are playing a game of chicken, and whoever has
a SMTP daemon with a lower limit on the size of a mail message loses.
(It's also possible that the mail would be forwarded to each PC, but
with POP it might be possible to locate autoresponders on the ISP
node.)
It's an interesting question in probability. If you have N PPP/SLIP
PCs, and p% of them have such autoresponders, and each person with an
autoresponder replies to n messages each day, how long, on average,
will be the MTBF due to games of smtp-chicken?
Bear Giles
[email protected]
------------------------------
Date: Wed, 25 Oct 95 13:18:18 -0400
From:
[email protected] (A. Padgett Peterson)
Subject: What the large print giveth, the small print taketh away.
Amid all the "Windows NT (tm)(c)(r)(sm)(one of them) is C2" hoopla, one very
important fact seems to have been glossed over (Microsoft marketoids are
skilled at this sort of thing).
I was forwarded the following announcement from Compuserve. Have
independently verified the comment but not the posting I have excerpted. The
Windows NT security guide says the same thing on page 44 but the copyright
notice is so draconian that I do not know if I can quote from that.
> MICROSOFT ANNOUNCES AVAILABILITY OF WINDOWS NT WORKS
> PR Newswire 18/9/95 9:04
> First Mainstream Commercial Operating System to Satisfy U.S. Department
> of Defense Criteria For C2 Security
>
> REDMOND, Wash., Sept. 18 /PRNewswire/ -- Microsoft Corp.
> (Nasdaq: MSFT) today announced the availability of Microsoft(R) Windows
> NT(TM) Workstation and Windows NT Server version 3.5, C2 Release,
> becoming the first vendor to satisfy C2 evaluation for mainstream,
> commercial operating systems.
Guess HP MPE V/E, Data General AOS, DEC VMS, and IBM VM/SP or VM/SP HPO
(all previously evaluated C2) do not count.
..(interesting part is about 30 lines further on)
> "We are very pleased that both Windows NT Workstation and Windows NT
> Server version 3.5 have been added to the C2 Evaluated Products List,"
> said John Davis, director of the NCSC. "Now that the base operating
> system has been through a very thorough and rigorous evaluation, we
> expect the networking components to take only a few months for full
> evaluation."
In other words, today the NT workstation & server lose their C2 evaluation
if either is connected to a network. Just a minor point.
Padgett
------------------------------
Date: Mon, 30 Oct 1995 16:14:59 -0500
From: Drew Dean <
[email protected]>
Subject: HotJava 1.0 alpha 3 security issues
We have found several security problems in the 1.0 alpha 3 release of
HotJava from Sun Microsystems. The two most important problems are that
HotJava does not enforce the stated limits on where an applet can connect to
(an applet can talk to any place with which you have IP-level connectivity),
and HotJava is vulnerable to a man-in-the-middle attack, where someone can
watch your web-surfing, both seeing your requests, and the content that you
receive.
While HotJava prevents applets from actively opening connections that
violate the user-selected security policy, it allows an applet to accept
connections from anywhere. At this point, an applet only has to use any one
of a number of channels to communicate where it is, and have the remote end
do the active open.
HotJava also allows an applet to set the proxy servers that the browser
uses. This opens up a huge hole for anyone concerned about the privacy of
their web surfing.
Please note that these bugs are specific to the 1.0 alpha 3 release, and are
_not_ bugs in the Java language itself, nor do they apply to Netscape 2.0
beta 1J, which doesn't permit network connections. We have notified Sun of
these problems, and are presently writing a paper on these and other issues.
We will make more information available on our Web page after we hear back
from Sun.
http://www.cs.princeton.edu/~ddean/java/
Drew Dean Dan Wallach
[email protected] [email protected]
------------------------------
From:
[email protected]
Date: Wed, 25 Oct 95 10:26:45 +60000
Subject: Re: Risks in Java and Beyond Java (Wertz, RISKS-17.42)
Charles Wertz expresses concern over the direction online information is
taking with executable code like Java becoming popular.
I don't have any solutions to offer, but I do have a possible roadmap that
may help. There is a Role-Playing game called Shadowrun, published by FASA,
that is set a number of years in the future. The core sourcebook has a
"history" that is quite fascinating, and helps to explain a number of the
paradigms in this invented future. Significant is the state of
communications they have depicted. Worldwide computer networks and voice
networks have merged into one which is accessed with a Sensory Translation
interface - basically the ultimate in Virtual Reality. In a nutshell, the
computing metaphor moves up into a whole new level and virus technology
shifts into defence where they cause real physical virus problem damage to
the intruder. Quite often, information consists of both inert data and
active code.
Now I know it is fantasy and oriented for role-playing (I've even played it).
However, with things like SmartCards to replace cash, and the blurring
starting to occur between data and code, I wonder how chillingly close to
reality Shadowrun's technology could possibly become.
Wade Bowmer
------------------------------
Date: Tue, 24 Oct 95 18:03:09 MDT
From: Jeffrey Mogul <
[email protected]>
Subject: Re: "core" files (Oliver, Risks Digest 17.41)
Ross Oliver (and before him, Rob Nauta) describe the dire consequences of
naively giving a useful file the name "core", at least on a UNIX system.
Almost a decade ago, I wrote a PhD thesis that asserted, among other things,
that it was foolish to infer file type from file name. I argued that the
file system ought to provide first-class support for an extensible
file-attribute system, so that one could associate arbitrarily complex type
information with any file.
I was a naive young man at the time, and very few people paid any attention
to my suggestion.
But it would not require any new file system features to double-check the
nature of a file named "core" before deleting it (or failing to back it up).
Core dump files have a precise structure, since they are meant to be
interpreted automatically by a debugger. Recent versions of the UNIX "file"
command understand how to classify core files, so one could use the "file"
command in a script to check before deleting. Old versions of "file"
classify core files as "data", but even that rudimentary level of checking
should prevent a script from deleting a file classified as something else,
such as "ascii text".
Curmudgeons may object that if the deletions are being done on a file server
of a different CPU architecture than the one on which the core dump was
generated, the "file" command may misclassify it. This does not seem to be
an insurmountable problem.
-Jeff
------------------------------
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 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.43
************************
