RISKS-LIST: Risks-Forum Digest Wednesday 23 May 2001 Volume 21 : Issue 41 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 <URL:http://catless.ncl.ac.uk/Risks/21.41.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: A Hard Left-Cruise Ship's Autopilot blamed for sharp turns (Kelly Bert Manning) Another backhoe reminder (Bernd Felsche) New Bell Canada service: free calls (Dave Isaacs) The Faith-Based Missile Defense (What's New via David Farber) Time to bury proposed software law (Dan Gillmor via Monty Solomon) NZ Electoral Web Site (Richard A. O'Keefe) Osprey, cont'd (Peter B. Ladkin) Our software is *never* wrong (Erann Gat) Risks in scuba equipment (Carl Page) More on that college network/spam (Danny Burstein) Apple Powerbook 'bomb' shuts Burbank airport (Monty Solomon) Re: Space Station software problems predicted four years ago (Bob Frankston) The new Taiwan $1000 bill got the globe backwards (Dan Jacobson) Police frequencies and fake calls (William Colburn) Power safety (Marcus L. Rowland) Ship to Internet (Donn Parker) 2002 ACM Symposium on Applied Computing: SAC '2002 (Cliff Jones) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 21 May 2001 13:06:10 -0400 (EDT) From: bo774at_private (Kelly Bert Manning) Subject: A Hard Left-Cruise Ship's Autopilot blamed for sharp turns Over 70 people were injured, 13 requiring treatment, when the ship docked in Victoria, British Columbia. Some refused to get back on board but did so after the US Coast Guard investigated and cleared it to continue without using the autopilot. Two injured passengers remained in Victoria for care. http://www2.mybc.com/news/fs.cfm?source_id=CP&id=851308 "It was like the Titanic. People were flying around in chairs. The gift shop was destroyed." USA Coast Guard Lt. j.g. Scott Casad is reported to have said that the autopilot malfunction appeared to have been caused by a computer error. The investigation will also look into whether the autopilot should have been used in the Strait of Juan de Fuca. It will be interesting to see exactly what sort of "computer error" this was. A crew member disengaged the autopilot after the second turn. ------------------------------ Date: Fri, 18 May 2001 10:48:03 +0800 (WST) From: Bernd Felsche <bernieat_private> Subject: Another backhoe reminder [from http://www.abc.net.au/news/newslink/nat/newsnat-18may2001-35.htm] Telstra [Australia] estimates 50 to 80 per cent of customers affected by yesterday's phone outage in New South Wales have had their phone services restored and says the remainder should be fixed very soon. Technicians have worked through the night to fix a cable which was severed by a backhoe on the central coast yesterday, cutting phone services from North Sydney to the Queensland border. Initially, Telstra hoped to have the cable repaired early yesterday afternoon but the company says the damage was worse than first thought. Spokesman Paul Levins says the delays are due to the complex nature of the cable repairs. "Inside the encasement are thousands of tiny hairlike fibre optics," he said. "It's like knitting each one of those back together, it is like microsurgery and it is highly technical. But they've got to get the sequencing right so you don't end up attempting to ring your mother down the street and wind up at the pizza shop." Bernd Felsche - Innovative Reckoning, Perth, Western Australia ------------------------------ Date: Mon, 21 May 2001 13:56:06 -0400 From: "Dave Isaacs" <daveiat_private> Subject: New Bell Canada service: free calls According to an articles in *The Toronto Star* and *Wired* (http://www.wired.com/news/business/0,1367,43967,00.html), Bell Millennium payphones users were given a rare treat last week: free access to Telehop's Dialaround low-charge long distance service. A glitch in the access software allowed anyone who entered 10-10-620 into a Bell Millennium pay phone to make unlimited free calls to anywhere in the world. Word spread quickly on Internet newsgroups, until people were literally camping out by the phones to wait their turn. It is interesting that the hole was known by the public for 6 days before it was fixed. Why the delay? Did it take 6 days to discover the problem? According to the article, Bell didn't start monitoring the network closely until [a] store containing the pay phones called to complain that the crowds were disrupting their business. I also wonder if Bell and Telehop knew about the problem for some time, but did not count on the exploit being described on the Internet. Dave Isaacs [Also noted by Aaron PooF Matthews. PGN] ------------------------------ Date: Sat, 12 May 2001 21:27:17 -0700 From: David Farber <daveat_private> Subject: The Faith-Based Missile Defense (What's New for May 11, 2001) 1. WEEKLY DISASTER REPORT: THE FAITH-BASED MISSILE DEFENSE Last week, you will recall, President Bush called for a global missile shield, including space-based elements, but he was pretty short on specifics (WN 4 May 01). This week, Defense Secretary Donald Rumsfeld called a press conference to talk about military uses of space. Many of us expected he would fill in some of the missing details from the President's speech. He didn't. Rumsfeld devoutly believes that an effective missile defense is out there somewhere, but neither he nor the President seems to have any idea of what the shield would involve or any evidence that such a thing is even feasible, much less what it would cost, when it might be deployed or whether it even has to work. Rumsfeld wanted to talk about the management and organization of a new national-security space initiative; it would be given the task of filling in the missing details. Not a bad strategy -- opponents of a missile shield are left with nothing specific to attack. [For IP archives see: http://www.interesting-people.org/ ] ------------------------------ Date: Sun, 13 May 2001 18:14:02 -0400 From: Monty Solomon <montyat_private> Subject: Time to bury proposed software law (Dan Gillmor) UCITA, the ``Uniform Computer Information Transactions Act,'' is the technology industry's version of Dracula. It's designed to suck money from overmatched consumers, and it keeps emerging from the coffin. Just about every serious pro-consumer official and organization has denounced UCITA, a proposed uniform state law that would tilt the balance in software transactions strongly toward the seller. But UCITA's backers, mostly in the computer industry, are not giving up -- and they may be on the verge of getting help from key public officials who, acting in good faith, would harm the people they're sworn to protect. [Dan Gillmor, Time to bury proposed software law, *San Jose Mercury*, 13 May 2001 http://www.siliconvalley.com/docs/opinion/dgillmor/dg051301.htm] ------------------------------ Date: Wed, 23 May 2001 14:25:42 +1200 From: "Dr Richard A. O'Keefe" <okat_private> Subject: NZ Electoral Web Site There's a saying in Australia and New Zealand: "when the Americans have a 'cute' idea, we wait a couple of years until they've proven that it's really really dumb, and THEN we copy it." *Otago Daily Times*, 22 May 2001, front page. Voters will be able to enrol on the electoral roll and update their details online using services on an elections web site. Associate Justice Minister Margaret Wilson said the service would be particularly useful for people living in remote areas or overseas, as well as the disabled. She also hoped it would encourage young people to enrol to vote. The site is www.elections.org.nz. I just hope the "disabled" people she has in mind are not the ones with poor visual acuity, because in Netscape 4.7x or Amaya on a SPARCstation, the page is unreadable; in Netscape on a Mac it is unreadable, and while it is marginally readable in iCab, it somehow managed to kill iCab. The site is slow and confusing. I have made repeated attempts today to view my own record, and always arrived at a page saying who was eligible to enrol. What would anyone reading comp.risks confidently predict would be used to identity a potential voter, so that no-one else can scribble on your record? SSN (which we call Tax File Number, TFN, and do NOT use except for tax purposes). Nope. It's better than that. Full name and date of birth. Maybe the fact that I can't get to my record even _with_ that information is the security feature I was hoping for.... ------------------------------ Date: Thu, 17 May 2001 07:36:52 +0200 From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de> Subject: Osprey, cont'd [Ladkin, Risks 21.33, 21.38} I advised RISKS readers in Risks 21.33 and 21.38 of three documents concerning the troubled V-22 Osprey tilt-rotor development and deployment program - the briefing material from the US GAO review of the program, the briefing transcript concerning the results of the investigation into the December 2000 crash, and the report of the Blue Ribbon Panel appointed by then-Secretary of Defence Cohen to evaluate the program. The briefers on the accident investigation (the JAG report) into the December crash pointed unambiguously to a software problem, what they called a "software anomaly". They said that the Primary Flight Control System (PFCS) did not behave as it should have (namely, that in a particular situation, it commanded significant control system changes when it should have done "nothing") and that this was due to the software. [Ladkin, RISKS-21.33] The Blue Ribbon Panel report devoted less than a page to software reliability. Their recommendations focused on methods effective for determining the characteristics of complex control systems in their operational environment, and did not include certain standard methods for assessing and repairing safety-critical software known to contain errors. [Ladkin, RISKS-21.38] Define a software error to be a failure of the software implementation to meet the design specification, or a failure of the software design to meet PFCS requirements. The JAG briefing indicated that a software error had been discovered; the Blue Ribbon Panel report led me to suspect whether this had indeed been the case. I spoke with Professor Eugene Covert, one of the four members of the Blue Ribbon Panel, on Tuesday, 15 May 2001, and I put to him the argument of my RISKS-21.38 note. Although a significant amount of his information is privileged, he was able to confirm that no software error as above had been implicated in the December accident and that the range of scenarios I suggested in RISKS-21.38 broadly represented likely scenarios for the genesis of the control behavior exhibited. Peter Ladkin, University of Bielefeld. http://www.rvs.uni-bielefeld.de ------------------------------ Date: 17 May 2001 09:52:48 -0700 From: Erann Gat <gatat_private> Subject: Our software is *never* wrong The other day I got an e-mail from my on-line credit-card company telling me that my e-mail preferences had been updated. Trouble is, I hadn't logged in to my account for weeks, and I could not remember ever setting any e-mail preferences. So my risk radar said, "Hack!" and I called the company. The rep assured me that my account had not been broken into. How did they know, I asked. "I've got your account right here and I can tell that no one has tried to break in." Yes, but *how* can you tell that? Well, because if someone had tried to break in it would have said so, and it didn't, so no one has. I explained to the rep about the e-mail that I got which could only be explained by either someone breaking in or a bug in their software. And if there was a bug in their e-mail software there might also be a bug in their hack-detection software. It should come as no surprise that this made little impression on the rep. ------------------------------ Date: Fri, 11 May 2001 20:34:00 -0700 From: "Carl Page" <carlpat_private> Subject: Risks in scuba equipment Scuba divers make a fetish out of safety, for good reason. I found the list of problems identified by testing by this outfit to be instructive, and perhaps generalizable. Thought you might enjoy it for RISKS digest. http://www.scubadiving.com/gear/scubalab.shtml Revelations: ScubaLab tests have led to many important revelations, including: a. A regulator that actually shut off the air supply (a voluntary recall by the manufacturer was initiated). b. Regulators that were advertised as upgraded and yet actually had increased work of breathing. c. Regulators that could not deliver adequate air flow below 100 feet. d. Regulators that were not adequately prepared for use as delivered. e. Add-on fittings for regulators, such as swivels, that changed a regulator's performance from acceptable to unacceptable. f. BCs that were supposedly improved with new airways or weight systems, but that actually performed worse on tests. g. BCs with advertised buoyant lift capacities that were significantly different from the actual values. h. BCs with mismatched inflator and ambient hose lengths, disabling the remote exhaust function. i. BCs with excessive inherent buoyancy. j. BCs with excessive body squeeze. k. A dive computer that "lost" four minutes during decompression. l. Dive computers that allowed continuous deep bounce diving. m. Dive computers that caused compasses to read incorrectly. n. Hoseless dive computers that lost their signal when other electronics were used. o. Dive computer PC interfaces that did not work. p. Dive computer instructions that were not correct. Setting the Record Straight ------------------------------ Date: Fri, 11 May 2001 22:16:48 -0400 (EDT) From: danny burstein <dannybat_private> Subject: More on that college network/spam (tls, RISKS-21.39) In RISKS-21.39, of 11-May-2001, your correspondent, tlsat_private, discussed the problems with the way a local university had recently set up an open 802.11 (wireless) network. He commented that while this was an arguably defensible decision for a university, he was quite concerned about its potential use by spammers. To quote him: > The RISK? Their campus mail-handling machines will relay mail to > any inside or outside destination if it's received from an address > "inside" their campus network. The network architecture they've > chosen for their wireless deployment dictates that anyone can walk > onto their (large, urban) campus, or even just park his car outside, > and spam away freely with hundreds of megabits per second of > bandwidth to most points on the Internet. Having tried exactly what tlsat_private describes (except that I sat in an air-conditioned van and only sent some test messages...). I can confirm that this university's mail servers work as he fears. Furthermore, any mail coming through them will have an envelope indicating it came from a well known and trusted source. Meaning not only would people be more likely to let it through their filters (whether computerized or the Mark One Eyeball method of glancing at the "from" and "subject" line), but they're also far more likely to open it. Meaning this type of service can easily be used to spread all sorts of nastiness. And not just limited to e-mail viruses and trojans. Getting back to spamming: this system doesn't block outgoing "port 25" access, meaning a spammer could set up their own mail server and pseudo-anonymously engage in all sorts of socially deviant activities. The RISK? If you leave your front door open on the Internet, you're leaving everyone else's front door ajar. ------------------------------ Date: Sun, 13 May 2001 18:11:09 -0400 From: Monty Solomon <montyat_private> Subject: Apple Powerbook 'bomb' shuts Burbank airport http://www.theregister.co.uk/content/2/18438.html Apple Powerbook 'bomb' shuts airport, article by Drew Cullen, 23 Apr 2001 A California airport was closed for six hours [20 Apr 2001], following a bomb scare. And the 'culprit'? Step forward the Titanium Powerbook G4. Operators of an x-ray machine installed at Burbank airport were unable to get a high-enough res look at a machine trundling through security. They called in back up for some chemical analysis. Swabs revealed "residues" which caused some concern The police and the FBI were called in, flights were cancelled, and hundreds of customers were left milling the booking hall. After six hours, the police determined that the Powerbook was indeed a Powerbook and not a bomb - its hapless owner was released from questioning, and the airport was free to return to its business. The scare was blamed on the titanium used in the laptop casing - officials said this could have given a false reading Let's hope this mix-up had something to do with the x-ray machine, rather than some magical shielding properties possessed by the Titanium PowerMac G4. If somehow it's the latter, Apple could have an awful lot of product liability suits on its hands. ------------------------------ Date: Sat, 5 May 2001 00:16:09 -0700 From: "Bob Frankston" <rmf2gRisksat_private> Subject: Re: Space Station software problems predicted four years ago (Gross, RISKS-21.39) Given that I'm in a plane and have time to catch up on old reading (but not follow URLs -- at least until Boeing deploys their IP-to-the-Seats infrastructure!), I might as well continue to take the contrarian role and defend the value of risk. There is no way to escape risk so might as well revel in it. In this case, I can't resist wondering how one can debug complex software before deploying it. The danger is more in assuming one can and not preparing for failure than in not doing complete debugging. This doesn't mean one should not do any testing, just that the limits must be recognized. I'm a great admirer of MIR -- the ability to keep it going with just the "chewing gum and bailing wire" (to use an old metaphor) impresses me more than a design which is "perfect". In general those who can experiment and survive have a major advantage over those who must put their energy into trying to avoid risk. If one never fails, one never succeeds. In the case of the Space Station, the real question is how the overall system is architected. Do point failures propagate or are the quenched? What are the fallback procedures? Is there an attempt at efficiency that tends towards depending on each module doing what it is supposed to do or is there the necessary mutual distrust. I fear that a procurement process that is overly specific actually increases the risk by making it more difficult to learn by doing. Bob Frankston Curmudgeonat_private http://www.Frankston.Com ------------------------------ Date: 19 May 2001 08:41:52 +0800 From: Dan Jacobson <jidanniat_private> Subject: The new Taiwan $1000 bill got the globe backwards The day I discovered this error, the chief had to call two press conferences the same day to deny it. If he admitted it, then he would have had to recall all the bad bills and print new ones (I suppose not to confuse counterfeit detection systems). It would not be possible to admit errors without revising the note. http://www.geocities.com/jidanni/1000xinxintaibi.htm http://www.geocities.com/jidanni Tel886-4-25854780 ------------------------------ Date: Sat, 12 May 2001 15:32:55 -0600 From: Schlake (William Colburn) <schlakeat_private> Subject: Police frequencies and fake calls (Re: Hutto, RISKS-21.39) I am a volunteer Field Coordinator for the New Mexico State Police (District 11). The Albuquerque Metropolitan area (District 5 SP) has been plagued by problems like this, but from cell phones and FRS (Family Radio Service) radios, not on police frequencies. Even so, police frequencies are nothing special. The quote "The police department's emergency radio system uses two sets of security identification codes and a computer to prevent unauthorized access." sounds like media hype to make it sound like something special was done. All police frequencies are well known, they are available from the FCC web page. The "identification codes" are most likely the sub-audible tones which tell the repeater how to process the signal. These are also well known. If I were to take my radio to Denver, I could probably be operating on their frequencies within a matter of minutes. The "modification" of the radio is also media hype. Almost any radio, except those purchased from Tandy, can be modified without any effort. You open the back of the radio, and (in most major brands) you will see a single copper wire amongst preprinted circuit boards. Anyone want to guess what happens if you cut the wire? The FCC laws require commercial radios to be fixed frequency. These laws were made for crystal radios, and shouldn't be on the books anymore. Most manufacturers make one radio, and just pack and wire it differently in different cases for different applications. The computer is most likely just the data link between the cars and the dispatcher that uploads and downloads information to the in car computers. As for bogus radio calls, we have had a veritable plague of fake distress calls from FRS radios and cell phones. Most cell phones will call 911 without a service provider or SIM card, which allows anonymous untraceable crank calls. SAR teams and emergency personnel have responded to crashed airplanes, automobile accidents, lost hikers, and lots more. They solved this problem by asking for a phone number that they can call to verify the callers identity. One real hiker was saved because he refered us to the car company that he rented his car from. A woman "lost in the mountains" was ignored because she wouldn't give her name, a name of a friend or relative, or a phone number where anyone who knew her could be contacted. ------------------------------ Date: Sat, 12 May 2001 23:28:24 +0100 From: "Marcus L. Rowland" <mrowlandat_private> Subject: Power safety (RISKS-21.36) I said >A couple of years ago we rebuilt two labs and were able to replace two >of these units with normal earth leakage and circuit breakers; there >has since been no trouble, nobody has been electrocuted, and we have >never had any loss of power in those labs. I'm now trying to get the >rest replaced. And as if by magic I've just heard that they're going to be fixed in the next holiday, apparently because my complaints finally convinced the school management that the cure is worse than the disease. Many thanks to everyone who made suggestions on this in e-mail. One point did arise in several messages, a suggestion that we have separate ring mains put in for the computers. Apart from expense, there was a serious safety issue with this; as mentioned in the original post, the room is running with the electrical supplies at about -110v negative, +110v positive, rather than the 0 negative, 220-230v positive of normal UK ring mains. If a separate supply was put in it would run at the normal voltage, and possibly a different phase, which could lead to much more serious problems if the two systems were ever linked. Marcus L. Rowland ------------------------------ Date: Sat, 12 May 2001 09:27:36 EDT From: Donn Parker <Donnlornaat_private> Subject: Ship to Internet Some cruise ships (Renaissance R Two) now have Internet cafes using satellite services. I was able to do all of my e-mail work 24/7 for two weeks ($100 fee) in the Mediterranean from Venice to Barcelona -- except for one day in Naples Harbor. On that day, the ship was in a position that precluded the dish line-of-sight to the satellite. The funnel was in the way. I received no refund. Donn Parker (retired in the nick of time and glad of it). [That would be known as A Napoli Day. Clearly, A Napoli Day Keeps the Internet Away. But there should also be a Napoli Woods in honor of the late movie actress. PGN] ------------------------------ Date: Mon, 21 May 2001 10:24:49 +0100 From: Cliff Jones <cliff.jonesat_private> Subject: 2002 ACM Symposium on Applied Computing: SAC '2002 2002 ACM Symposium on Applied Computing (SAC '2002), CALL FOR PAPERS Madrid, Spain, 10-13 March 2002 Special Track on Inter-disciplinary Approaches to the Design of Dependable Computer-Based Systems http://www.dai.ed.ac.uk/homes/rnp/sac2002/cfp.html All submissions must be received by September 1, 2001. A special track on inter-disciplinary Approaches to the Design of Dependable Computer Systems will be held at SAC'2002. Society's dependence on computer-based systems continues to increase. The systems themselves -- embracing humans, computers and engineered systems - become ever more complex as they feed an insatiable appetite for new and extended functionality. Furthermore, these trends coincide with pressure for systems to be brought to market faster and at lower (and more predictable) cost. Achieving sufficient dependability in these systems, and demonstrating this achievement in a rigorous and convincing manner, is of crucial importance to the whole fabric of the modern Information Society. Although progress has been made in achieving high dependability in computer hardware and software, wider systems involving computers, people and business or social organisations are often disastrously unsuccessful and the cause of huge financial losses or worse. It has become clear in recent years that satisfactory resolution of this situation demands an inter-disciplinary approach targeted at understanding the fundamental problems that arise in attempts to build systems involving complex interactions amongst numbers of computers and human beings. Inadequate understanding of the complete organisational and cultural context of use is often a significant cause of lack of dependability of major new computer-based systems, and will be a major focus of this track. By bringing together computer scientists, psychologists and sociologists who share an interest in the problems of dependability, the proposed track will make an important contribution to fostering this inter-disciplinary approach. Submissions will be invited on (but not limited to) the following themes: * Architecture and organisation of systems, processes and their environment, e.g., use of diversity in systems and processes * Work and its relationships with technological systems and artifacts, e.g., collaboration and interaction, organizational culture and trust * Reasoning about dependability attributes, e.g., temporal predictability and responsiveness of systems and processes, security and confidentiality, formal methods * Socio-technical approaches to systems design and development, e.g., knowledge management and process change, co-evolving work and technologies * Assessment and management of risks involved in system development and deployment Original papers from the above-mentioned or other related areas will be considered. Each submitted paper will be fully referreed and undergo a blind review process by at least three referees. The accepted papers in all categories will be published in the ACM SAC'2002 proceedings. ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-requestat_private 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 <risks-requestat_private> with one-line, SUBSCRIBE (or UNSUBSCRIBE) which now requires confirmation to majordomoat_private (not to risks-owner) [with option of E-mail address if not the same as FROM: on the same line, which requires PGN's intervention -- to block spamming subscriptions, etc.] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => 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 risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.41 ************************
This archive was generated by hypermail 2b30 : Wed May 23 2001 - 17:08:01 PDT