Hundreds of American Airlines flights were delayed Tuesday evening after its Sabre Group computer stopped functioning at 5:18 p.m. CT and was out of service for at least four hours. An American Airlines spokesman said the delays ranged from 8 minutes to a few hours on domestic and international flights, due to a software problem. This was the second Sabre central-system outage in a week. The outages affected about 50 airlines that use Sabre for reservations, seat assignments, baggage info, etc. [Source: Sara Nathan, *USA Today*, 1 Jul 1998, PGN Abstracting]
A coffee spill in a control tower distracted controllers long enough to delay instructions to a passenger jet, causing two planes to pass within 20 feet of each other over New York's LaGuardia Airport, the Daily News reported yesterday. The incident happened on April 3 as a US Airways plane was preparing to land on one runway and an Air Canada plane was taking off on an intersecting runway. [Reuters - from The Baltimore Sun, 6/29/98.
This time it's at Kuala Lumpur's new airport which opened Tuesday 30 Jun 1998. The check-in systems were also fouled up. The problems were still persisting Friday, July 3, the fourth day of operation. Looks as though Denver was a pioneer in more ways than one. Peter Ladkin firstname.lastname@example.org http://www.rvs.uni-bielefeld.de [Things reportedly got better after that, however. PGN]
On Friday 26 Jun 1998, PacBell managed to upload a corrupted database that disabled their digital "PCS" telephone service to all subscribers. The database was the central authentication database that ensures that the user of a particular phone has the rights to use that phone. The service is the new, non-cellular, digital service; you now know as much about the technology as I do. We are subscribers. Our telephone came back on-line at about 3 p.m. Saturday. Details should be available at http://www.sjmercury.com or http://www.sfgate.com. Have a nice Fourth. - Tony
A group of vendors has teamed up with the International Computer Security Association (ICSA) to form a Malicious Mobile Code Consortium, aimed at combating the threat of malicious or corrupt Java applets and ActiveX controls. Malicious applets are capable of freezing a user's screen, slowing PC performance to a crawl, or even scrambling a hard drive. Charter members include Advanced Computer Research, Computer Associates, Cybermedia, Digitivity, Dr Solomon's Software International, eSafe Technologies, Finjan, Internet Security Systems, Quarterdeck, Security-7, Symantec and Trend Micro. The consortium will focus on educating companies and consumers, developing product-certification standards and testing, and providing a venue for information exchange. "The threat by mobile malicious code has been established," says ICSA's malicious mobile code program manager. "We have the benefit of anticipating these attacks and preventing them." (*Information Week*, 1 Jul 1998; Edupage 2 July 1998)
This was posted recently to a mailing list of which I am a member : <URL:http://terraserver.microsoft.com/> "Microsoft TerraServer serves up some fascinating images. But it does a lot more. It demonstrates how off-the-shelf components from Microsoft, Compaq, Legato, and StorageTek can be used to design, to deploy, and manage a massive digital image database that has to be available 24 hours a day, seven days a week." [clickety-click through the tedious map interface to SE England] "We're sorry, the TerraServer Database is temporarily unavailable. Please check back again soon, this should only be a temporary delay."
A secret encoded circuit board containing sensitive technology was missing from the wreckage of an American satellite aboard a Chinese rocket that exploded in 1996, and American officials said Tuesday at a joint hearing of two House committees, National Security and International Relations, that they suspected that Chinese authorities took the board. [Source: *The New York Times*, 24 Jun 1998, try http://www.nytimes.com/library/politics/062498china-missiles.html]
A researcher at Lucent Technologies' Bell Labs has broken the standard encryption code used for electronic commerce, called secure sockets layer, or SSL. Using a physical connection to a server computer operated by an Internet service provider, a hacker could send about a million carefully crafted messages to an e-commerce Web site operator, and analyze the responses to those messages to decode the original message. Following Lucent's announcement, Netscape, Microsoft and Security Dynamics' RSA Data Security unit issued patches to fix the problem. SSL relies on technology developed by RSA. (Reuters 26 Jun 1998; Edupage, June 28 1998)
The 22-member U.S. Government Technical Advisory Committee to Develop a Federal Information Processing Standard for the Federal Key Management Infrastructure (TACDFIPSFKMI) has failed in a two-year effort to design a federal computer security system that includes "back doors," a feature that would enable snooping by law enforcement agencies. Addressing Commerce Secretary William Daley, the panel wrote that it "encountered some significant technical problems that, without resolution, prevent the development of a useful FIPS. ... Because the focus of this work is security, we feel that it is critically important that we produce a document that is complete, coherent, and comprehensive in addressing the many facets of this complex security technology.. The attached document does not satisfy these criteria." The failure casts further doubt on the Clinton administration policy — required for government agencies and strongly encouraged for the private sector — of including such back doors in computer encryption technology used to protect computer data and communications, according to outside experts. But administration officials said the panel, which is set to expire in July, simply needed more time. [Source: U.S. effort on encryption "backdoors" ends in failure, By Aaron Pressman, Reuters, 25 Jun 1998, PGN Stark Abstracting] [Pressman's article also included this quote from Alan Davidson: "The administration keeps spending taxpayer money to pursue a ... strategy that's wrong-headed and won't protect security. Its own advisory committee can't answer basic questions about how to make it work for the government, yet they continue to push for its adoption by everyone, worldwide." PGN] Alan Davidson, Staff Counsel, Center for Democracy and Technology, 1634 Eye St. NW, Suite, 1100 Washington, DC 20006 202.637.9800 <email@example.com>
The National Security Agency has declassified its 80-bit-length Skipjack encryption algorithm and its 1,024-bit-length key exchange algorithm, and made them publicly available. "This declassification is an essential part of the Department of Defense's efforts to work with commercial industry in developing reasonably priced computer-protection products," says the Pentagon. "This declassification decision will enable industry to develop software- and smart card-based security products, which are interoperable with Fortezza." The Skipjack algorithm is used in the Fortezza PC smart card, which controls access to computers in the Defense Message System and other DoD applications. (*EE Times*, 24 Jun 1998; Edupage, 25 June 1998)
A former U.S. Coast Guard employee was sentenced to five months in prison for a July 1997 incident, in which she deleted crucial information from the Coast Guard personnel database and caused the computer system to crash. Shakuntla Devi Singla was also ordered to serve five additional months of home detention and three years supervised release, and to pay $35,000 in restitution to the Coast Guard. It took 115 Coast Guard employees 1,800 hours to restore the data, which included information on personnel promotions, transfers, assignments and disability claim reviews. Singla's attorney says her action was the result of frustration after her attempts to report the illegal behavior of a computer contractor were ignored. (*The Washington Post*, 20 Jun 1998; Edupage, 30 June 1998)
I've recently been faced with a very curious intellectual dilemma: at what point is the web browsing that we do potentially --- and unknowingly --- crossing the line into illegal hacking? RISKS has explored this topic before (such as with alternate uses of robots.txt files, such as for finding interesting stuff like http://www.cnn.com/webmaster_logs/). Here are two recent encounters that have left me rather perplexed: Case #1: A lot of AFS directories (a network file system popularized by CMU in the 1980s) have been starting to appear in recent months as publically viewable HTTP directories, without the knowledge of their owners. (In many cases, the directory owners have since graduated or moved to a staff position, leaving countless long-forgotten files and E-mail archives in their home directory.) On two occasions in the past month (one at MIT, and one at CMU), I've performed ordinary web searches using ordinary search engines, and ended up finding private documents belonging to friends, with personal and confidential information. In each case, I immediately alerted the friend, and they had the permissions changed immediately, and the offending material removed. (Now, removing the summaries from a dozen search engines for hundreds of pages will be another matter. ;) Could perhaps a tenuous argument be constructed that an individual reading these private documents --- after realizing that they were not meant to be publically posted --- was hacking? Case #2: A *lot* of webmasters omit index.html files in critical directories, or perhaps forget to configure their servers to deny access to directory listings to HTTP directories that lack index.html files. This renders any casual web surfer trivially able to surf the actual directory tree of their web site --- including their CGI directory --- and associated private data files. I've encountered this twice tonight --- once while attempting to post a housing vacancy at a local University's housing list (system was down, and I was curious why ;), and a second time while browsing a web site of a music publisher whose works I have enjoyed in the past. In the latter case, I immediately stumbled upon full archives of this company's (unprotected) customer orders, web logs, & associated information, and other information that I believe any company should reasonably consider private. Ouch! Let's say I went ahead and read those files. Say, I was curious about more information about the company's customers buying habits, and had no malicious or criminal intent. Would this be breaking the law? On one hand, the webmaster *probably* didn't intend for the information to be public. Does a difference truly exist between exploiting known configuration errors in web sites, and exploiting known configuration errors in networked UNIX systems to access information not meant to be public? On the other hand, it doesn't matter what they intend. They *have* made it public, and they've just placed it on a server where any bozo with a web browser can get to it just by typing a regular URL; how could one be breaking the law by viewing what they've already placed in a public area for viewing? (Certainly, I never signed an agreement to limit my use of the web site to merely clicking on links, and have every right to type whatever I'd like into the URL field!) Now, let's say a competitor to the company in question happened to stumble upon the same URL and data. What, then?
Central Intelligence Agency director George Tennant is warning that the Year 2000 computer bug (found when programs are unable to correctly interpret dates past 1999) "provides all kinds of opportunities for someone with hostile intent" to gain information or plant viruses. "We are building an information infrastructure, the most complex the world has ever known, on an insecure foundation." (*USA Today*, 25 Jun 1998; Edupage, 25 June 1998)
The following item is from Dennis Elenburg, "The Y2K Weatherman", firstname.lastname@example.org, http://y2kwatch.com/, 1 July 1998, re: the Galaxy IV failure, RISKS-19.75-77] "Well, yesterday in talking to an engineer, I heard that the source of the problem was a 600-day date window. Bottom line, according to this particular engineer, is that Galaxy IV was taken out by a Y2k-like glitch. The recovery from the loss of this (single) satellite was pretty impressive, but what happens when we lose several satellites at the same time? Will we be able to recover communications then?" [The list he refers to is his own Y2K Weatherman Report. I imagine that readers of RISKS would also be very interested in more information on this. Ben Torrey, email@example.com]
The loss of transmission from the Galaxy IV satellite last month made some customers realize how much they depended on Muzak. In Lafayette, Indiana, one upset and elderly Burger King customer told the manager: "Now I just have to sit here and hear myself think." [Source: *The Globe and Mail*, 24 Jun 1998] Phil Edmonds
This is an excerpt from the CSIS Y2K conference. Gary North's Y2K Links and Forums Summary and Comments Category: Shipping_and_Transportation Date: 1998-06-24 19:34:02 Subject: No Manual Switching for Railroads; Result, Famine Link: http://www.csis.org/html/y2ktran.html#simpson At a June 2 conference on y2k sponsored by the Center for Strategic and International Studies, Alan Simpson confirmed what I have been saying for over a year: the trains will go down. He said that the railroads have abandoned manual controls. "Going back to the rail system, they've taken out manual points. I talked to some of the major rail companies a few days back and said, 'Go to manual.' And they said, 'All our manual points are in the warehouse up in New York State waiting to be disposed of. We cannot switch manually anymore. We have taken out manual reversion systems on most of our key communication, power, and switching systems.' " Conclusion: * * * * * * * * * * And a few weeks ago he started looking at this, and it was Bruce Webster here who mentioned about, in one of his presentations, the could-be famine in the United States in 2000. And like most of you here I thought rubbish, rubbish, until we started looking at the infrastructure and started the wildfire scenarios on what if. And looking at New York and California, I walk into a supermarket and I get lettuce, fresh vegetables, any day of the year. Seven days ago they were in a field in California. Now they're in a supermarket just outside New York. We know the switches on the railroads are faulty. We know because of mergers, even today, many of the major corporations in the railroad business don't know where the railway stop is. When you move this way through, come 2000 you could have a scenario — and when you look at this, it's the Soviet Union in the '80s -- where there's plentiful supply of food in the fields, but you can't get it from the fields to the towns to feed the population. This is not a way-out, whacko scenario. This is for real.
I received a copy of a chain letter recently. This chain letter claimed that a dying child's last wish was to have a chain letter sent out across the internet, to raise the public's level of awareness of the dangers of "cerebral carcinoma". A corporate sponsor was going to donate three cents to the American Cancer Society for every copy of the letter that went out. Readers were asked to add the e-mail address of the American Cancer Society, firstname.lastname@example.org, to their carbon copy list when forwarding it to their friends. Most chain-letter frauds seem aimed at the reader's greed. The new wrinkle in this one was that it was aimed at the reader's generosity and altruism. I believe the perpetrator's real intent was to harvest live e-mail addresses. I suspect that they intended to build two lists. I suspect that all those who actually responded to the campaign have marked themselves as both generous and trusting, and will be sent a second, more pushy, campaign for donations.
Mr. Agre's observation raises a disturbing issue regarding the languages of choice in computer science courses. I have grown increasingly concerned that a sizable number of colleges and universities have chosen C or C++ as their language of choice based almost solely on its prevalence in the marketplace. While I agree that both are excellent, capable languages, they must be evaluated in the context of their original application. C (and by extension C++) was designed as a system software programming tool, to be used by experienced programmers to develop operating system and related software; it allows the programmer wide latitude and great flexibility, assuming in almost every case that the programmer knows what he/she is doing. On the other hand, this laissez-faire approach can lead to extraordinary, and sometimes destructive, program behavior under other circumstances, particularly those involving inexperienced programmers. Framed another way, it's a matter of choosing the right tool for the job at hand. C/C++ is probably the right tool if you're developing system software; I maintain that is not always the case for general application software development. Having taught both Pascal and C++ for over 10 years I've seen the situation Mr. Agre's describes almost every semester: student programs inadvertently walking off the end of an array. With Pascal the language's run-time bounds checking caught this every time; the lack of these checks in C++ has been the source for countless hours of debugging baffling program behavior. Time and again, I have cautioned my students to treat C++ as an exquisitely capable power tool with few, if any, safety features: in the right hands it can do wonders, allowing a craftsman to fashion a work of art, knowing all the while that a minor slip-up could cost him a finger, arm, or leg. While languages such as Pascal and Ada have taken a beating over the years from various constituencies within the programming community for a wide variety of alleged sins, in the final analysis the safeguards built into these languages offer significant value-added to project managers in terms of the avoidance of this type of common logical errors within their program designs. Michael A. Nelson, ARINC, Incorporated
BKY2KSWP.RVW 980410 "The Year 2000 Software Problem", Capers Jones, 1998, 0-201-30964-5, U$29.95/C$41.95 %A Capers Jones %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1998 %G 0-201-30964-5 %I Addison-Wesley Publishing Co. %O U$29.95/C$41.95 416-447-5101 fax: 416-443-0948 email@example.com %P 335 p. %T "The Year 2000 Software Problem: Quantifying the Costs and Assessing the Consequences" "When the twentieth century ends, many software applications will either stop working or produce erroneous results since their logic cannot accept the transition from 1999 to 2000, when the dates change from 99 to 00 ... The costs of defending against litigation and lawsuits can approximate half a year's software budget, but damages and penalties from suits that are lost can reach multiples of annual software budgets and lead to bankruptcy ... Unfortunately, current data indicates that at least 15% or software applications will not be repaired in time." - from the Introduction This book is a warning. By its own admission, however, it comes too late. Is this book simply an insightful and focused locking of the barn door after the horse has left the building? Chapter one provides an executive overview of the situation. It shows that year 2000 repairs should have started some time ago. However, it does also demonstrate that it is barely possible to start such repairs now, provided heroic measures are undertaken. It also proves that such repairs then would have been much less costly than the same repairs now, and furnishes rough, but well supported, estimates of costs for the repair of applications, and for the failure to repair. A historical review in chapter two also notes that there is a benefit to the year 2000 problem: it will force companies to pay attention to their software inventory. Chapter three is rather odd, defining a handful of terms associated with applications development. The common metric for year 2000 work is the number of lines of code to be checked. Jones prefers the function point, and chapter four looks at conversion factors plus a glance at the size of the problem as a whole. However, it also starts to deal with direct and indirect costs, particularly in regard to litigation, and loses some focus thereby. Chapter five is a very thorough (perhaps at times overly thorough) assessment of the total impact of the Y2K problem on the United States, looking at the total cost, and cost by state, industry, programming language, and so forth. Advice on the actual fixing of the problem starts with program testing in chapter six. Chapter seven looks very briefly at database repair. Litigation and liability is reviewed in chapter eight. The analysis of business failure risks, in chapter nine, seems to lean heavily on litigation as well. Chapter ten discusses the rise of the year 2000 repair industry. Retrofitting applications by the use of masking or windowing is mentioned in chapter eleven. The heavy United States emphasis of the book is partially rectified in chapter twelve. The analysis of the scope of the project by country is somewhat flawed by assumptions that figures per line of code can be directly converted from US surveys. However, the chapter also looks at the impact of conversion to the Euro (the new European currency) and the diverse impact this may have on the problem as a whole. Chapter thirteen looks at factors that modify costs for various industries. Chapter fourteen examines a number of problems that may arise in various sectors if the problem is not fixed in time. A review of general defensive tactics is contained in chapter fifteen. Appendices B, C, and E contain additional sources of information. In general terms, the book does not give much in the way of advice for dealing with the crisis except for the suggestion to use masking in preference to date field expansion. However, it does provide you with some lovely frightening figures to use next time the CEO asks you if this Y2K thing is really of any importance. copyright Robert M. Slade, 1998 BKY2KSWP.RVW 980410
Please report problems with the web pages to the maintainer