precedence: bulk Subject: Risks Digest 19.88 RISKS-LIST: Risks-Forum Digest Wednesday 22 July 1998 Volume 19 : Issue 88 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, caveats, etc. ***** This issue is archived at http://catless.ncl.ac.uk/Risks/19.88.html Contents: USS Yorktown dead in water after divide by zero (PGN, Michael D. Crawford) More on Navy software problems (Robin Sheppard) OS Design 101 (Lindsay F. Marshall) Product safety recall (Leonard X. Finegold) If you want medical privacy, get the Feds out of healthcare (Declan McCullagh) Sloppy date handling in Perl scripts (Manu Iyengar) Federal Court holds that source code is a functional device (Peter D. Junger) Commerce Committee approves WIPO (Dan Lin) Japanese snake vs. railroad electrical supply (Danny Burstein) Another cable cut, near Jacksonville (Charles P. Schultz) Auckland power supply failure report released (Tom Worthington) Re: Y2K contingency plans needed (Rob Bailey) Y2K dig-gerel (Brill Michael) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 21 Jul 1998 13:07:45 -0700 From: "Peter G. Neumann" Subject: USS Yorktown dead in water after divide by zero The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA., apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News, 13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/July13/cov2.htm] [Thanks to over a dozen readers who commented on this item. This makes me wonder: if I ran each snippet that was sent in, we could have stayed within the fair-use guidelines by publishing the entire article in twelve pieces, each with its own individual comments on the situation! For example, Lloyd Wood picked out this paragraph on which to comment: "The program administrators are trained to bypass a bad data field and change the value if such a problem occurs again, Atlantic Fleet officials said." ``That's an interesting RISK-prone way of handling the problem,'' said Lloyd. PGN] ------------------------------ Date: Tue, 21 Jul 1998 14:52:55 -0800 From: crawford@scruznet.com (Michael D. Crawford) Subject: USS Yorktown dead in water after divide by zero [...] The article describes how depending on Windows NT to automate many ship functions caused serious trouble because of "system failures". ``Using Windows NT, which is known to have some failure modes, on a warship is similar to hoping that luck will be in our favor,'' said Anthony DiGiorgio, a civilian engineer with the Atlantic Fleet Technical Support Center in Norfolk. A sidebar in the article says that despite the setbacks, the Navy awarded a large contract to Litton to do ship automation. I'm not personally opposed to using computers in critical situations like aboard a warship, but I would think you'd want a fault-tolerant OS and applications, not a consumer product like Windows NT. Mike Crawford crawford@goingware.com http://www.goingware.com/ Michael D. Crawford http://www.scruznet.com/~crawford/ ------------------------------ Date: Fri, 17 Jul 1998 17:08:55 -0700 From: Robin Sheppard Subject: More on Navy software problems (Rosenthal, RISKS-19.87) Ideally, the next few generations of operating systems will end up being so incompatible with legacy systems that no country anywhere will be able to wage war. At least we can hope so. Robin Sheppard, MITS Helpdesk robin@cadence.com 888-543-9993 X7911 ------------------------------ Date: Wed, 22 Jul 1998 15:50:03 +0100 (BST) From: "Lindsay F. Marshall" Subject: OS Design 101 I give you the following excerpts from Microsoft's official developer documentation on Windows CE (The Windows CE Programmer's Guide, in the MS Developer's Library), in a section entitled: "Tips for Efficient Memory Use." I refrain from further comment. "Whenever the system attempts to allocate more than 16 KB of memory, it has the potential to fail without displaying the System Out of Memory dialog box and without sending a low memory warning to the user." "Small memory allocations almost never fail. Before this type of allocation fails, the user has been sent both low-memory and critical-memory warnings, in the form of System Out of Memory dialog boxes, and has had an opportunity to respond." "Include memory management capabilities in your application to supplement those in the system." ------------------------------ Date: Wed, 22 Jul 1998 09:42:08 -0400 From: Dept of Public Safety at Drexel, via Leonard X. Finegold Subject: Product safety recall This message has been approved by Mr. Anthony T. Caneris, Senior Vice President Student Life & Administrative Services, caneriat@post.drexel.edu, 215-895-2800. To: Administration, Department Heads, Faculty, and Staff From: Armour Floyd, Director, Safety and Health Programs Date: July 16, 1998 Re: Product Safety Recall The Safety & Health Programs Department has been made aware of a product safety recall by the Textronix Corporation. Textronix has determined that certain incorrect use of their model TDS210 and TDS220 oscilloscopes may cause the ground connection to fail on these products, potentially exposing the user to risk of serious personal injury or death. This recall applies to TDS210 and TDS220 products with serial numbers below the following: TDS210 - Serial Number below B049400 or C010880 TDS220 - Serial Number below B041060 or C011175 Textronix will modify your product(s) to remove this shock potential and return it to you free of charge. Even if your product appears to be functioning properly, you should not assume that it does not have an open ground connection. Consequently, immediately stop using the product. All returns will be at the expense of Textronix. If this particular product is in your possession, please contact Armour Floyd, Safety and Health Programs Department at 895-2880 for further return information. ------------------------------ Date: Tue, 21 Jul 1998 06:47:12 -0700 (PDT) From: Declan McCullagh Subject: If you want medical privacy, get the Feds out of healthcare http://cgi.pathfinder.com/netly/0,2326,201980721-14116,00.html TIME.com / The Netly News, July 21, 1998 Both Parties Weigh Medical ID Numbers By Declan McCullagh (declan@well.com) Spooked by the government's attempts to ban strong encryption products? If you thought that was troubling, wait'll you hear about the move towards mandatory medical ID numbers. A government panel met in Chicago on Monday to discuss a 1996 law that regulates the health insurance industry -- and in exchange requires that everyone receive a "unique health identifier." Liberal privacy advocates quickly condemned the move as a Big Brotherish intrusion into our personal lives. But conservatives and libertarians charge that liberal groups like the ACLU and the Electronic Privacy Information Center miss the point: if Feds regulate healthcare, invasive government databases are as inevitable as a sweaty Washington summer. [...] POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to majordomo@vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ ------------------------------ Date: Mon, 20 Jul 98 13:16:19 -0700 From: Manu Iyengar Subject: Sloppy date handling in Perl scripts InfoWorld's web site has a page for "Top News Stories" which is programatically generated by a CGI script: http://www.infoworld.com/cgi-bin/displayStory.pl?weekreview/weekinreview.htm Visitors to the page today (July 20, 1998) see the page report the date as Wednesday December 31, 1969! RISKS readers and other sharp folk will immediately recognize this as the date of the epoch minus 1 second. Conjecturing wildly, I suspect the problem is likely a sloppily written line of code (the CGI program seems to be a Perl script) along the lines of: print " ", localtime(time()), "
\n"; Both localtime() & time() are Perl equivalents of the corresponding C functions and use them internally. But what most Perl programmers probably do not know is that time(3c) will return (( time_t )-1) if it fails for any reason, so localtime(-1) will happily return a formatted date string for "Wednesday December 31, 1969". The risks? This particular idiom is extremely common in Perl scripts of all sorts, since it's a convenient way of printing out a date or timestamp in human readable format. RISKS readers are well aware of the dangers of not explicitly checking return values, but many programmers may routinely take shortcuts such as this. After all, who expects time(3c) to ever fail? In this case, the result is harmless - visitors to the page get a good laugh. But what if the same code was recording the timestamp to a database, or using it for something important? ------------------------------ Date: Mon, 20 Jul 1998 18:18:25 -0300 From: "Peter D. Junger" Subject: Federal Court holds that source code is a functional device Back in May 1993 I had an article in RISKS Volume 14, Issue 65 about ``The risks of teaching about computers and the law'', relating how I wrote a simple encryption program for use in my course in Computing and the Law and discovered that I had to have a license from the government before I could publish the program, or even discuss it in a class if any foreign students were present. Quite a bit has happened since then. I filed a suit on 1 Oct 1996 challenging the constitutionality of the International Traffic in Arms Regulations (the ``ITAR'') as they applied to cryptographic software like my little demonstration program, as well as much more functional programs like Phil Zimmermann's Pretty Good Privacy. At that point matters appeared to be moving right along. But then the President transferred the authority to regulate encryption technology to the Secretary of Commerce under the Export Administration Regulations (and thus the ITAR was replaced by the EAR). The new regulations considerably relaxed the restrictions on cryptographic software and it was, much to my relief, no longer necessary for me to get a license from the government before discussing my program or PGP with a foreign student. And the publication of encryption software in a book or a journal or in other ``hard copy'' form was no longer subject to the licensing requirements. But a license is still required under the EAR if one publishes encryption software on the Internet or the World Wide Web or in other ``electronic form''. And by that time I had collected lots of cryptographic software that I wanted to publish on my web and ftp servers, and some of it was embedded in my casebook and in a couple of law review articles that I am writing. So it was back to the drawing board. On 2 Sep 1997, we filed a new complaint naming Secretary of Commerce Daley as the defendant, and both sides moved for summary judgment. The complaint, answer, briefs, and other documents relating to the case are available on my web site at . Our position was quite simple and is summarized in our final brief: ``Making software available on the Internet and the World Wide Web is publication of that software, and publication in that medium is entitled to the unqualified protection of the First Amendment.'' The government's position was not so clear; in fact, I find it rather incoherent. It seems to argue that the publication of software amounts to using that software, and that Congress could restrict its use to prevent fraud and other criminal acts, ignoring the reality that Congress has never passed any law that forbids the use of encryption software. But don't take my word for that. Here is what the government argued in its final brief: The linchpin of plaintiff's First Amendment argument is that ``software is speech'' This notion is not only irrelevant to deciding the case, but has unknown and potentially harmful implications. If it were necessary to decide the matter, the more prudent judicial finding would be that encryption software, whatever its informational value, is properly treated as a functional item. The common sense understanding of software -- as recognized by courts -- is as a set of instructions to a computer microprocessor that enables a computer to function a certain way. . . . The common use of software is to perform tasks on a computer, ranging from word-processing, electronic mail, exploring the Internet, playing games, or encrypting data. Much software, however, is designed to cause substantial harm. Software exists to spread and install ``viruses'' that can destroy computer hard-drives or the files they contain. Software also exists to ``hack'' into secure computer systems, such as banking and telephone systems. Such software can be used to invade privacy, commit fraud, and substantially disrupt or even endanger people's lives -- not because it contains a harmful ``idea'' but because it can do harmful things. Those who transmit such software cannot validly claim they were merely distributing an ``idea'' or ``speech'' when that ``speech'' destroyed a computer hard-drive, shut down a phone system, or hacked into a bank account. In the case of powerful encryption, there are valid uses of hardware and software in securing communications, including to prevent the harms described above. But encryption can also secure the communications of criminals, terrorists, and other hostile entities overseas, which gives rise to the government's concern over its uncontrolled export. When all the consequences are considered, the conclusion that ``software is speech,'' because some people understand the intricacies of how it works, is simplistic and should be avoided, particularly in judicial precedent. Finally, on July 3, 1998, Federal District Court Judge Gwin of the Northern District of Ohio ruled in favor of the government, concluding that software is not constitutionally protected speech because it is ``inherently functional'', saying: ``while a recipe provides instructions to a cook, source code is a device, like embedded circuitry in a telephone, that actually does the function''. Now some of the risks of having a legal system that simply miscomprehends the very nature of software---and that is what the government's argument and Judge Gwin's decision strongly suggest to me---should be all too apparent to the readers of this digest. I suspect, however, that there are many unknown risks lurking here as well. What, for example, is the implication of Judge Gwin's decision that source code is a device for copyrights on software? I have created a new electronic discussion list and web site called SoftSpeech, which I hope will be a forum in which programmers and computer scientists, on the one hand, and lawyers and legal scholars, on the other, can discuss the issues raised by Judge Gwin's decision, including whether software is constitutionally protected speech or a functional device. For further information about the SoftSpeech discussion list and Judge Gwin's decision, see . Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH junger@samsara.law.cwru.edu http://samsara.law.cwru.edu ------------------------------ Date: Mon, 20 Jul 1998 17:37:05 -0500 From: Dan Lin Subject: Commerce Committee approves WIPO Here is a quick update on the House Commerce Committee consideration of the Digital Millennium Copyright Act (WIPO) HOUSE COMMERCE COMMITTEE APPROVES H.R. 2281, DIGITAL MILLENNIUM COPYRIGHT ACT H.R. 2281, known as the Digital Millennium Act, was approved by the House Commerce Committee on July 17 by a 41-0 unanimous vote. A total of eight amendments were considered during the mark-up. Six were adopted and two were withdrawn. There now currently exist two versions of H.R. 2281 - the Commerce version and the Judiciary version. The two versions are quite different and must ultimately by reconciled. The Commerce version is an amended version of the Senate bill, known as the Digital Millennium Act, and the Judiciary version uses language from the original House bill, known as the WIPO Copyright Treaties Implementation Act. USACM had sent a letter to the House Commerce Subcommittee on Telecommunications, Trade and Consumer Protection on June 4, 1998 that expressed concerns about language in the bill which could prohibit legitimate efforts in encryption research and computer security. The amendments adopted by the Committee address several of the concerns raised by USACM. 1. ENCRYPTION RESEARCH - ADOPTED An amendment was adopted which allows a person to circumvent a technology protection measure "in the course of an act of good faith encryption research." Good faith in this case means that the person lawfully obtained the encrypted work, the act of circumvention is necessary to conduct the research, and the person made a good faith effort to obtain authorization before the circumvention. Additionally, the amendment directs the Assistant Secretary of Commerce for Communications and Information to report to Congress on the effects of the legislation on encryption research no later than one year after the enactment of the act. 2. PERSONAL PRIVACY - ADOPTED The adopted privacy amendment permits a person to circumvent a technological protection measure which collects or disseminates personally identifying information provided that the act of circumvention has "no other effect on the ability of any person to gain access to any work." 3. DEFINITION OF "TECHNOLOGICAL PROTECTION MEASURE" - WITHDRAWN An amendment defining a "technological protection measure" was vigorously debated, but ultimately withdrawn. Supporters of the amendment argued that it was necessary to preserve the constitutionality of the bill. Without a clear definition of a technological protection measure, courts would be quick to throw out cases involving the law due to the vague term. While opponents of the amendment conceded that a precise definition was necessary, they argued that the amendment as drafted provided a poor definition. Ultimately, the amendment was withdrawn with the provision that members would work together to perfect the definition in the legislative history. 4. REVERSE ENGINEERING - ADOPTED Unamended, the bill would allow reverse engineering only for the purposes of interoperability. An amendment was adopted that included the consideration of the extent to which claims were brought against persons who used reverse engineering in research in an annual report by the Secretary of Commerce. The report would include an assessment of the level of impediment such claims would have on the development of goods and services. Even with this amendment, however, the bill still prohibits reverse engineering for uses other than interoperability. 5. FAIR USE - ADOPTED For the past month, the Commerce Committee had struggled with the concern of fair use. While libraries feared that the bill would prohibit fair use rights essential to library lending, publishers feared that any legal circumvention techniques would lead to uncontrollable piracy. Early Friday morning, both sides apparently struck a compromise deal. The adopted compromise amendment delayed the prohibition of circumvention for two years, directing the Secretary of Commerce to "conduct a rulemaking on the record to determine whether users of copyrighted works have been... adversely affected by the implementation of technological protection measures..." Every two years thereafter, the Secretary could waive the prohibition for particular "classes" of copyrighted works which were adversely affected by the legislation. The Commerce Committee is currently drafting the legislative history for the bill. Next there will be an informal conference between the House Judiciary Committee and the House Commerce Committee to reconcile the two different versions of the bill. In general, the Commerce Committee version is more in line with the positions of the USACM, though it still contains provisions that may be problematic for computer research. Please let me know if I can provide any more information. Daniel Lin, ACM U.S. Public Policy Office, 666 Pennsylvania Avenue SE, Suite 302B, Washington, D.C. 20003 1-202-544-4859 djlin@acm.org ------------------------------ Date: Mon, 20 Jul 1998 08:38:08 -0400 (EDT) From: danny burstein Subject: Japanese snake vs. railroad electrical supply In the continuing tradition of animals versus electrical power grids, I submit this snippet from a news story of a Japanese snake, genus unknown, who gave its life making commuters late: Electrocuted snake causes train havoc in northern Japan Associated Press, 20 Jul 1998 Officials canceled 34 train runs after a snake crawled up an electricity pole and touched a high-voltage overhead rail wire. Railway workers later removed the charred remains of the electrocuted snake, which was 3 feet, 4 inches long. The snake's type was not immediately known. [The lack of strong typing was not on the scales. PGN] ------------------------------ Date: Wed, 22 Jul 1998 17:08:29 -0500 From: CharlesP Schultz-ECS013 Subject: Another cable cut, near Jacksonville Where have we heard this before? The July 16th edition of the Miami Herald newspaper carried a story with the headline "Severed cable shuts down superhighway." It seems that a telephone work crew north of Jacksonville accidentally cut a cable owned by WorldCom that carries telephone and Internet traffic from Florida to the northeast (recurring theme #1). This cable handles Internet traffic for WorldCom's UUnet, which acts as part of the Internet backbone, carrying traffic between thousands of customers. There was no specific count on the number of people affected, but the paper reported "it was a significant number." One thing that is interesting to me is how differently various South Florida service providers were affected. America Online, which uses WorldCom and other backbone providers said it experienced temporary slowdowns. [ How could anyone tell??? ;-) ] CyberGate, a Broward County-based ISP with 47,000 subscribers, said customers were unaffected since they don't use UUnet and have multiple connections to avoid this kind of problem. The worst hit seems to have been Icanect, a Miami-Dade county provider for 20,000 people, who was almost totally shut down. The reason for this is that their backup provider, Cable & Wireless, experienced technical problems on the very same day. Bob Hurwitz, president of Icanect, was expecting it to take at least 24 hours to clear up his problem, and he was quoted in the paper as saying "To have both your primary and your backup both go down, that's not supposed to happen." (recurring theme #2). Fortunately, this was only a non-fatal reminder that these kinds of things still happen and need to be accounted for. Charles P. Schultz ------------------------------ Date: Tue, 21 Jul 1998 21:54:42 +1000 (EST) From: Tom Worthington Subject: Auckland power supply failure report released "After a series of four power cable failures, on 20 February 1998 Mercury Energy Limited, the major distributor and retailer of electrical power to the city of Auckland, announced that it could no longer supply power to the central business district. Emergency services were notified and mobilised..." Quote from the report of the Ministerial Inquiry into the Auckland power supply failure, issued today. Now available: * Executive summary: http://www.executive.govt.nz/minister/bradford/power/summary.htm * Media Release from the Minister of Energy: http://www.executive.govt.nz/minister/bradford/power/release.htm * Inquiry Home Page: http://www.moc.govt.nz/inquiry/ ps: The lights are on, here in Auckland, now. See: http://www.webcam.co.nz/ Tom Worthington, Immediate Past President, Australian Computer Society http://www.acslink.net.au/~tomw POB 13 Belconnen ACT 2617 tomw@acslink.net.au ------------------------------ Date: Tue, 14 Jul 1998 18:35:05 -0400 From: Rob Bailey Subject: Re: Y2K contingency plans needed (Frankston, RISKS-19.85) That's what I thought, too. The point was raised over on the Emergency Management Net distribution list that lots of talk about identifying and fixing the problem had taken place, but that the emergency management community as a whole had been pretty much ignoring the problem of response and damage mitigation to a problem that is 18 months off (and, unlike all other disasters, can be timed quite accurately on any calendar). In response, wrote that "[t]he Y2K bug seems to mostly lurk in old COBOL code." So I decided to offer a couple of examples that had been brought up here in Risks and some pointers in the Web to embedded systems that might / will fail on Y-day. I was pounded with criticism. The most poignant attack came from , who opined that I was promulgating unfounded "Fear, Uncertainty and Doubt". Steve went on to add that "[a]ll in all, [he's] not really that concerned about Y2K." With that attitude, it's no wonder that little if anything has been planned by the emergency management community in response to the 01-01-01. For example, FEMA has implied that few or no Y2K-*specific* preparations have been made; instead, FEMA will rely on the national response plan to deal with the (alleged) emergency like any other emergency. I hope it works; unlike others, all in all, I *am* really concerned about Y2K. Rob Bailey, wm8s@pobox.com WVIT School of Engineering, Class of 1986 W&L School of Law, Class of 2000 [Assuming their computers let you out. PGN] ------------------------------ Date: Tue, 21 Jul 1998 10:56:19 -0400 From: "MICHAEL BRILL" Subject: Y2K dig-gerel Millennium Panic Michael H. Brill, 5 June 1998 The Bug hangs off in distant skies And stares with double-O for eyes, Between my digits now. But soon, It hides itself behind the moon. Emerging on the other side-- New-grown, and much too large to hide-- It grows again. I see it nears, Igniting all my primal fears. (But no-one else sees this display; They're deep into their business day.) With jaws agape and wings unfurled, This Bug's about to eat the world! Now sages see the ghastly form, And mumble that it's just the norm: "The 'Bug' is just a trick of lights, A cloud of dust, or must--or mites." As evening comes, arachnid pall, It scarcely dims the sun at all. Though jaws envelop all the sky, I see through them the planets fly. Orion studs the frigid night. I feel no heat; I find no light. Our world, the lifeblood that we've prized With digitalis paralyzed. The ichor from the jaws has spread In smaller things beside my bed. Outside, crowds mad with fear and pain, For lack of power their kin have slain. As gun-filled hands my door break through, The sages' echoes all ring true. "They're right," I sigh with my last breath. "A cloud of 'mights' has brought my death." ------------------------------ Date: 31 Mar 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com 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) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.88 ************************