"David L. Oppenheimer" <davido@CS.Princeton.EDU> and email@example.com (Jason Eisner) sent me the identical item, one from the AP and the other from *The New York Times*, 23 Aug 1996, entitled Wrong Computer Command Led to Colombia Crash of American Airlines Boeing 757 American Airlines has noted that the pilots of the December 1995 crash of Flight 965 were lost at the time, and attributed the crash to the captain entering a computer command that steered the plane in the opposite direction. Unfortunately, the one-letter code for Cali on the flight chart they were using was the same as the one-letter for Bogota, and caused the plane to fly into a mountain, killing 159 of the 163 people aboard. Pilots have been alerted as to the discrepancies. (Most airline computers use different codes for the two cities.)
An uncoordinated software change cost $39 million, as reported in "Inside the Air Force", July 5, 1996, page 10: "Lockheed Martin and Boeing completed negotiations last week on how to split the team's share of the $39 million cost of replacing the high-altitude unmanned aerial vehicle [UAV] which crashed in April near Edwards AFB, CA. The partners will split equally what could be a $6 million to $12 million bill from the Pentagon for the destroyed DarkStar, the same proportion by which it divides the workshare of building the UAVs. The first flying DarkStar crashed shortly after take off from Edwards on April 22, resulting in the total loss of the air vehicle, the only flight test asset available at the time. Although finger pointing has been assiduously avoided by both companies, industry and Air Force sources said the crash was the result of Boeing having adjusted software controlling flight on the UAV without commensurate changes being made in the system by Lockheed Martin's Skunk Works division. `The left hand didn't know what the right hand was doing,' a source said. However, the problem has been addressed and the program should be back on track shortly, pending the approval by the companies' lawyers of the terms of splitting the cost for the crash. A May 16 letter to Rep. John Murtha (D-PA), the ranking minority member of the House Appropriations national security subcommittee, from Defense Airbourne Reconnaissance Office chief Maj. Gen. Kenneth Israel tagged the cost of rapidly configuring another DarkStar UAV for flight and making up lost time in the program at $39 million." [reprinted with permission from "Inside Washington Publishers - Defense Group". Permission Point of Contact: Richard Lardner, U.S. (703) 416-8530] Related URLs include "http://www.boeing.com/dsg.darkstar.html" and "http://www.afa.org/magazine/6-6nn96.html". --- David A. Wheeler firstname.lastname@example.org
I run a mail + news server at my home, serving only a few people but to these the ability to receive and send e-mail is quite important. Recently I had to leave home for a couple of weeks. I spent a lot of time before to make the system quite fail safe, especially so it could handle some tasks that I otherwise do manually. While I was away, it worked more reliably than at any time before. Until one day. It was not accessible anymore. I could not even call into a backup PC which was there just to provide at least the ability to reboot the server system. Why ? The wheel in the electric meter (a 35 or more years old electromechanical device) used for counting the power consumed by the system, somehow stopped rotating. I assume due to a problem in the bearing it was not able to restart rotating after a simple power blackout (it restarted after giving it a slap, manually). Well, this meter was designed to limit the current to whatever it could count. Thus, no rotation, no current. I understood that I'm responsible for the reliable operation of the PC hard- and software, and I can rely on the power supplied by my PSC. But I forgot there was one important device between their output and my system. Kolja Waschk (email@example.com, NIC-handle KW84) Tel +49-40-8891-3034 BBS/Fax -3035 http://hp00.rz.tu-harburg.de/users/sekw0206 "Yo.COM news & mail service ..."
A mailing list I subscribe to started sending an endless loop of bounce messages and another subscriber forwarded the following as explanation. I have not verified the authenticity of the message with Netcom, but I have no reason to doubt it. There are two denial of service attacks here: A person was email bombed by someone who subscribed him to many mailing lists, and then that person retaliated by bringing down the mailing lists. Once again we see an old problem that could have been prevented had the system administrators simply configured known security measures before their system was hacked. [begin quoted message] Newsgroups: netcom.announce From: firstname.lastname@example.org (Margaret) Subject: Temporary hiatus of mailing lists Reply-To: email@example.com Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Thu, 22 Aug 1996 03:42:16 GMT Approved: firstname.lastname@example.org Outgoing mail from Netcom mailing lists is temporarily being delayed due to a mail looping problem, starting at 5:30 PM PDT today. The problem was caused by a user at another site; someone subscribed him to many Netcom mailing lists, and he responded by creating an infinite loop of "bounce messages" to all the list subscribers. List mail is being queued until we can filter out these error messages. Netcom is currently in the process of upgrading majordomo, and we hope to implement improved security for all our lists. In the interim, we strongly recommend that listowners set their lists to "closed"; this protects against all mass-subscription attacks. Delivery of list mail should resume later this evening. Thank you for your patience. [end quoted message] — Sidney Markowitz <email@example.com> Apple Research Laboratories, Apple Computer, Inc.
The following describes DNS meltdown at my ISP the other day: all DNS services were unavailable, despite multiple servers being online. Lack of DNS assured that other working services were unavailable to everyone who didn't have IP addresses written down. Here is a technical explanation of the DNS failure, for those of you interested. First, a synopsis of how DNS works... every site on the net serves their own DNS records. Some sites serve other people's DNS records. For example, BEST serves the DNS records for best.com, best.net, and most of our customer's custom domains. No site serves more then a small fraction of the DNS records on the internet from their own database. The way DNS works is that when a domain name needs to be resolved, our DNS server (anyone's DNS server) first goes to the NIC to ask where to go to resolve the domain name. The NIC itself cannot resolve domains, it can only tell our DNS server where to go to resolve a domain. Our DNS server then goes to the specified remote site to resolve the domain name belonging to that site. The remote site replies with the answer which our DNS server (a) caches for future reference, and (b) returns to the original requester. The caching is important, because otherwise a DNS server would have to re-query the remote DNS server every time someone wanted to resolve a domain. DNS records propagate through caches. It is simply not possible to run a DNS system with caching turned off, it would create an impossible load on the internet. Around 4:00 a.m. yesterday, some unknown site's cache got corrupted. The corruption propagated to many (hundreds) of other sites on the internet and eventually propagated to us. This corruption hit a bug in the DNS server program that wound up corrupting the program, causing DNS to loose major records. Restarting the server in this case does not solve the problem because, due to the caching on remote sites, the corrupted record repropagates almost instantly. BEST was hit by this problem very hard due to the large number of custom domains we serve... so many DNS requests come into BEST and are made by BEST that our servers would hit the corruption out on the internet within 10 seconds of starting up. Worse, this particular corruption tended to destroy the root records (stored in memory), called SOA records, for the domains served locally. This destroyed the mail system causing mail messages to bounce rather then to simply be delayed, because the DNS server was saying 'site X does not exist' rather then timing out. It's worst possible corruption that can occur in a DNS system. -- It turns out that the last two BIND releases contain a bug that, when a corrupted record of the type that started propagating at 4:00 a.m. is received, results in the destruction of other **unassociated** records stored in memory. The particular release of BIND that we were using had been running perfectly for several *months* before this incident. It was not something recently installed. There are two fixes to the problem: (1) One can lock out those sites where the corrupted records come from, and (2) One can revert to an older release. (1) is not a good solution because, due to the nature of DNS, corruption can propagate to many sites and it would be impossible to keep up to date and lock all of them out. We wound up taking action #(2) and reverting to an older release of bind which, fortunately, did not have the bug that caused the problem. We had to revert to BIND 4.9.3. Unfortunately, we did not think to do this for many hours because we were all convinced that the problem was external in nature and just didn't think to try a reversion. In hind sight, that is the first thing we should have tried since we had the friggin binary for the older version sitting in our source tree. As far as DNS goes... the DNS we run is not 'bsd' or 'sgi' .. it's the *official* world-wide BIND distribution run by Paul Vixie. It is really not appropriate to run the older versions shipped with most operating systems due to massive, massive security holes. The corruption problem was unavoidable. What *was* avoidable was the long period of time that elapsed before the problem got fixed, which I take full responsibility for. We spent most of that time trying to track down where the corruption was coming from... a near impossible task. Around 6:00 p.m. scuttlebutt started propagating regarding a possible bug in the last two BIND releases at which point we instantly reverted to an earlier version, which fixed the problem, then started banging our heads against the wall for not trying it earlier. Matthew Dillon Engineering, BEST Internet Communications, Inc. <firstname.lastname@example.org>
Early last week, the Nashua, NH *Telegraph* ran a front page story about U.S. Congress Bill Zeliff, who is current running for Governor of NH. The story asserted that the paper had discovered that the Honorable Mr. Zeliff was registered for two SS numbers. The excerpts I have seen from the article indicated that the reporters from the newspaper had contacted two `out of state' database firms that collect information from various sources and make it available to various parties. The data showed two SSN numbers for Mr. Zeliff, one that was clearly his and one that looked to have been created rather more recently. The next day, the headline was something to the effect that the two numbers might in fact be a database error, and included quotes from the database firms saying that errors in these databases were common, and that they are not responsible for errors - the errors are in the submitting systems, not theirs. Their was an interesting quote from one of the spokesman, something to the effect of "The press shouldn't have access to our system". In the meantime the Mr. Zeliff has asked for apologies, etc. By the third day the duplicate entry was definitely declared a mistake. Interestingly, the influential (and decidely Anti-Zeliff) *Union Leader* newspaper of Manchester, NH. decided to stay out of the fray, running only a small sidebar on the issue the second day and one or two short editorials, all of which showed amazing restraint. (The *Union Leader* has an extremely conservative editorial position and has the widest circulation in the state; its statewide influence is considered to be *powerful* by most political observers.) Yesterday's Sunday Edition of the *Union Leader* also included a discussion of the *risks* of such electronic databases; the article mentions EFF and other 'privacy' advocates prominently. As for the damage to Mr. Zeliff's election chances, the results are still unclear, but seem minimal. His main competitor in the Republican primary did not make an issue of the problem, choosing instead to continue harping on a ``fact-finding'' mission Mr. Zeliff made to South America last Winter (at taxpayers expense, of course). [I apologize for the sketchiness of this report: I have the newspapers at home and should be able to substantiate some of the more relevant facts when I get home this evening.] Craig Neth Digital Equipment Corporation 110 Spit Brook Road ZKO3-3/Y25 Nashua, NH 03062 email@example.com [Apparently the *other* SSN belonged to a four-year-old. PGN]
Thomas Reardon of Microsoft points out that Internet Explorer 3.0 now includes a warning of "suspect" software. The Risk here is that this warning is far too broad. That is you seem to get the warning for almost everything. Thus the typical user will almost certainly get into the habit of pressing the Yes button every time - just as he/she already does on all the idiot "are you sure" prompts. The warning by itself is thus useless. Another Risk is that the user can't distinguish between Intranet and Internet usage. If we assume that on the Intranet he is allowed to download ActiveX modules because they are considered safe there, but now (sorry NOT) allowed to download ActiveX bits from the Internet, how is he able to tell them apart. The browser certainly doesn't. Mike Walsh, Pohjola, Finland
We have tested Microsoft's patch and have verified that it fixes the problem we reported. The patch is available from http://www.microsoft.com/msdownload/iepatch.htm
This is just an editorial opinion from a non-editor of risks. We see increasing numbers of security holes formed from what would appear to be minor design or implementation flaws in systems - particularly in the user-level programs running on those systems. Perhaps the real problem comes from not using trusted systems. Some examples: Java allows access to user files: A trusted system could prevent this regardless of any flaws in Java. Just provide it with a private area. Bash error allows character code ff to act as a separator: A proper trusted system would not allow you to exploit this to any advantage. Explorer error lets you overwrite system and other files: Again a trusted system would eliminate the problem. Perhaps the real problem we face has to do with the lack of interest by the community in using technologies that we know about and that are highly effective in preventing a wide range of threats. Instead of building on the work of others, people keep on starting from scratch and making the same mistakes again and again. Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225
For a long time, I've been coming to the conclusion that one of the biggest RISKS in computing (and, since that's starting to touch every aspect of our lives, everything else), is an excessive degree of integration. It increases system complexity (read: bugginess) exponentially for often negligible benefits. A couple of items in RISKS-18.36 bring this home: > before Explorer downloads a dangerous file like a Word document, Sorry ? A Word document is dangerous ? Ah yes - when you run it, an auto-start macro buried in the document itself might get DOS to format your hard disk... Why do the 99% of users who just want to edit a letter have to risk their entire system integrity for what is basically a gee-whiz feature ? (Does Word have some way to load documents without executing any auto-start macros ? Or would that be too complex because users could turn it off and then forget they'd done it when they _needed_ to run an autostart macro ?) > Friends of mine have a remote-controlled gas fireplace in their new home. I tested this statement on several colleagues (all computer people). They all thought it was either (a) "hugely funny" or (b) "absolutely terrifying". Typical reactions in the respective categories were (a) "who's so lazy that they want a real, old-fashioned-style, back-to-nature log[-effect] fire, but can't be bothered do something old-fashioned like getting their b*tt [AOL!] out of their chair" [I suppose it may have been an unrequested feature of the house, put in by the builders following input from their "marketing" types - NB] (b) "every electronic system fails at least once every 5 years or so - to run something as dangerous as burning gas with a 27 MHz [we presume - NB] $4.99 remote circuit is just insane". The other day, I was in an electrical store (buying an overvoltage protector...go figure) and the lady in front of me was trying to find a replacement remote control for her shutters. These had been stuck in the down position for two weeks because the remote's cheap push buttons were sticking. If there was a manual override in the house, she sure didn't know where it was. These days, before buying almost anything, I try to work out what its failure mode is likely to be, how long I can reasonably expect it to (a) work and (b) be reparable. The results of this calculation for personal computers is one of several reasons why I don't own one (but that's another story). Nick Brown, Strasbourg, France
On Sun, 25 Aug 1996, A. Lester Buck III wrote: > >I suspect we would soon be building weapons that would never work when > >the real trigger was actually squeezed. > > The very first nuclear weapon was designed (and tested!) using teams of > women operating hand calculators. Funny thing, it worked the first > time! The very first atomic bomb was tested (and destroyed) in the desert out west. The second and third atomic bombs were tested over Hiroshima and Nagasaki. Even though the first one worked, most of the scientists weren't sure #2 and #3 would work because they were made differently. One of the main reasons that a demonstration wasn't conducted for the Japanese was because our experts weren't sure it would work. Computers are very useful and should be used as much as possible, however, anyone who thinks that a computer can reliably substitute for a "real" test is naive.
<> to use the new computer ... to determine which country wins a war <> without actually fighting the war. Perhaps the best fictional treatment of this idea appears in Philip K. Dick's "The Variable Man". Dick's works (especially his short stories) contain a wealth of RISKS-relevant ideas.
[In response to Frank C. Ferguson's response concerning the ancient Chinese to Jonathan Kamens noting Star Trek's origin of "virtual war"] "We inwented the ancient Chinese." — Pavel Chekov
[Frank sent in a long copyrighted Reuters item, 22 Aug 1996, on the Y2K problem, citing estimated costs to the U.S. Government of $9 to $30 billions, with worldwide fixes costing from $300 to $600 U.S. billion. The article also noted that Nebraska is imposing a two-cent tax per pack of cigarettes, to help smoke out the state's reprogramming problem. Independently, Mark Brader forwarded an item from Malcolm Austin <firstname.lastname@example.org>, who had suggested naming a project aimed at this problem ``Dreadnought'', but he was voted down with those preferring ``Odyssey 2000''. In response, Malcolm noted that the original Odyssey project (Odysseus's voyage) ended up 20 years behind schedule, and killed off everyone involved except the lead manager. I like Malcolm's chosen name, but suppose that a fractured American spelling, DreadNaught, might be slightly more appropriate. PGN]
> The northbound train (with the passengers) was the 17:04 which left on time. > The preceding northbound train (16:54) was delayed by over 6 minutes which > meant the southbound (empty) train would have been delayed by at least that > in crossing over onto the other line. Not necessarily. The signalman would have all three trains visible on his panel. If the other train was that late, the signalman could have crossed the empty train *before* the late train reached the area. This is the sort of thing they do every day. Clive D.W. Feather, <email@example.com> Associate Director, Demon Internet Ltd. <firstname.lastname@example.org> Director, CityScape Internet Services Ltd. +441813711138
In RISKS-18.37, Alastair Scott <email@example.com> wrote: > Who was it who wrote that "any sufficiently advanced technology is > indistinguishable from magic"? They are right, and they are becoming > more than right. Answer: Arthur C. Clarke And Dr. Stanley Schmidt once wrote, "Any sufficiently advanced magic is indistinguishable from technology." Rhetorically, Tom Zmudzinski [Also noted by Stanton McCandlish <firstname.lastname@example.org>. PGN]
This was in my inbox today, concerning an order scheduled for delivery August 15 (fortunately, I was not in a hurry for it): > Subject: > <Firm> order update > Date: > Fri, 23 Aug 1996 09:44:46 -0700 > From: > <
Dependable Computing for Critical Applications, Final Call for PapersCatherine A. Meadows <email@example.com> Mon, 26 Aug 1996 13:36:07 -0400 (EDT)DCCA-6 Call for Papers Sixth IFIP International Working Conference on Dependable Computing for Critical Applications Can We Rely on Computers? March 5-7, 1997 Garmisch-Partenkirchen, Germany Final deadline for original papers is 3 Sep 1996. Prof. William H. Sanders University of Illinois Tel: 217 333 0345 CRHC - Coordinated Science Lab Fax: 217 244 3359 1308 West Main Street E-mail: firstname.lastname@example.org Urbana, Illinois 61801 USA
Please report problems with the web pages to the maintainerTop