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…
*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 BellovinThe 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 BowmerInvestigators 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:
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 dhartung@mcs.com www.mcs.net/~dhartung/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 mikeq@primenet.com http://www.primenet.com/~mikeqIn 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]
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 bear@cs.colorado.eduAmid 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.
PadgettWe 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 WallachCharles 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 BowmerRoss 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.
-JeffPlease report problems with the web pages to the maintainer