Subject: RISKS DIGEST 12.17 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 26 August 1991 Volume 12 : Issue 17 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Computer-related problems at Cape Canaveral (Steve Bellovin) Computer communications and the aborted Soviet coup (PGN) Medical records for sale (Jerry Leichter) Citicorp selling of credit card data (Bud Couch) Automating commodities markets (Cameron Laird) Re: Bank Shot (RISKS of automatable documents) (Jerry Hollombe) Re: Microsoft, IBM demonstrating faults in each other's products (Flint Pellett) More about California's Automatic Vehicle Identification spec (Steve Bagley) California DMV AVI proposal (Phil Agre) Use of ATM for blackmail in UK TV script (Mark Evans) Desktop Forgeries (John Moore) Re: SSNs (Brad Templeton) Sometimes you can only get there using the long way around (Bob Cunningham) Re: canopus.stanford.edu goes nova (Joe Dellinger) FTCS 22--Symposium on Fault-Tolerant Computing (Jack Goldberg) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Mon, 26 Aug 91 16:31:22 EDT From: smb@ulysses.att.com Subject: Computer-related problems at Cape Canaveral Last week, the range safety officer at Cape Canaveral had to destroy a rocket because it was off-course. The reason: a technician hit the wrong key while loading the guidance software, and the ground test version was loaded instead of flight software. And that caused the steering nozzles to lock in place. The error was apparently obvious on printouts, but no one checked them. Even the right code were loaded, the rocket may have malfunctioned anyway. A bug was discovered in the navigation programs of a second rocket of the same model; it would have caused the rocket to head in the wrong direction. Launches have been suspended until they can check things over some more. (It isn't known if the destroyed rocket had the same bug.) The two rockets were conducting SDI-related experiments. The article I saw made no mention of the irony. --Steve Bellovin ------------------------------ Date: Thu, 22 AUG 91 08:04:06 PDT From: "Peter G. Neumann" Subject: Computer communications and the aborted Soviet coup Apprently EMail, Internet, CompuServe, and FAX played a major part in foiling the aborted coup attempt in the Soviet Union. Despite local news blackouts, various communiques found their way around quite successfully. ``While messages from Russian President Boris Yeltsin and other coup opponents were being sent throughout Asia, Europe and North America this week, the committee that tried to seize power either didn't know about or couldn't keep up with the instantaneous network transmissions. ... The unprecedented connection, made possible by the introduction of thousands of personal computers into the Soviet Union under President Mikhail Gorbachev, put a kink into plans to control the flow of information.'' [Source: DURING COUP ATTEMPT, SOVIET COMPUTER USERS FED NEWS TO OUTSIDE WORLD, By ROGERS CADENHEAD, c.1991 Fort Worth Star-Telegram, 22 Aug 91] ["Coup" is of course pronounced "coo", the sound of the dove.] ------------------------------ Date: Thu, 22 Aug 91 12:48:38 EDT From: Jerry Leichter Subject: Medical records for sale No computers seem to be involved in this story, but it's an illustration of modern trends. The New York Times (14 Aug 91, page A10) reports on a controversy that has arisen in Greenville, South Carolina. It seems that Dr. Donald Miller moved to Michigan not long ago. He tried, but without success, to find another doctor to sell his practice to. Ultimately, it was sold at auction. Bidding against a number of doctors and other salvage dealers, Claude Rogers, an area businessman who runs an auto body and salvage company, an auto leasing concern, and various real estate ventures, bought the building that held the practice and all the equipment for $92,000. He was also the only bidder at a separate auction, at which he obtained thousands of patient records for $4,000. Mr. Rogers felt the records were a valuable resource, defining a ready made market of some 8,000 to 10,000 potential patients; he intended to sell them, along with the physical pieces of the practice, to another doctor. However, he drew no offers - only cries of outrage that someone who was not a medical provider ended up with access to confidential medical information. Mr. Rogers says he signed a document, at Dr. Miller's request, pledging to maintain the confidentiality of the records. In a move he viewed as a service to the patients - but which many saw as an additional cause for concern - Mr. Rogers ran ads in the local papers offering people copies of their medical records for $25. Mr. Rogers says the fee is the standard amount doctors charge insurance companies in accident claim cases. (According to a doctor I spoke to, $25 would be a rather low fee. However, doctors do not normally charge patients for copies of their own records.) He says he's had about 30 requests for copies, about half from people on fixed incomes, for whom he's waived the charge. There appears to be no clear legal protection for the confidentiality of doctor's records when the doctor dies or dissolves his practice. According to the American Medical Records Association, which represents 35,000 people who maintain medical records (is it my imagination or is there an "Association" for every possible grouping of businesses?), privacy rules are clear regarding hospitals, but less so for private practices. The article doesn't indicate what the rules are, or whether they are voluntary or enforceable under state or Federal law, but the association's spokeswoman implied that hospitals must keep medical records confidential. According to Mr. Rogers, all that counts is a happy ending, and the story appears to have one: Dr. Kevin Smith bought the records (at a "considerable profit" to Mr. Rogers), and is leasing Dr. Miller's old practice. Mr. Rogers says the ready-made patient pool won Dr. Smith over; Dr. Smith was unavailable for comment. -- Jerry ------------------------------ Date: Fri, 23 Aug 1991 16:42:58 GMT From: kentrox!bud@uunet.uu.net (Bud Couch) Subject: Citicorp selling of credit card data (Leichter, RISKS-12.15) Jerry Leichter reports about Citicorp's plan to sell marketing data on it's credit card customers buying habits, and notes that "American Express has done this for years". When my Amex card comes up for renewal, there is always a little box on the form which allows me to opt out of this plan. I check it. Bud Couch - ADC/Kentrox ------------------------------ Date: Mon, 26 Aug 91 13:50:59 -0500 From: cl@lgc.com (Cameron Laird) Subject: Automating commodities markets "The Chicago Board of Trade, departing from its 143-year-old tradition of frenzied pit trading, announced plans Wednesday [21 August 1991] for a new steel futures contract to be traded only on computer screens. [...] It also represents a cautious step ... away from the increasingly controversial open-outcry trading technique that the Board of Trade practically invented. [...] Open-outcry trading has been criticized in recent years ... prosecutors alleged corrupt traders used the pandemonium of the pits to cover for illegal schemes. [...]" [AP wire story] It happens quite often that an organization or individual proposes to sanitize the operation of some market--soybean oil, Impressionist masters, gold coins, ...--by moving the operation on-line. It is EXTREMELY rare for an appropriate discussion of the comp.risks of automation to accompany the litany of benefits. Among the chief concerns of existing market participants are: privacy; reliability; response time; exception-handling; and synchronicity. Automated data-processing certainly has experience addressing precisely those requirements, but not all the experience has been happy. There are bound to be more problems in the future. Personal opinion: from the little contact I've had, the Chicago exchanges have been effective in their automation efforts. I expect the BoT will make this latest experiment a success, too. However, it's quite typical of them to present information to the public which includes no hint of the possible negatives. Cameron Laird +1 713-579-4613 +1 713-996-8546 cl%lgc.com@uunet.uu.net ------------------------------ Date: Wed, 21 Aug 91 19:10:11 -0700 From: The Polymath Subject: Re: Bank Shot (RISKS of automatable documents) (Ed Ravin) }... The bill, for which Rep. Wyden is now seeking comment, }could even include restrictions on the types of companies that can buy }sophisticated check-printing equipment often used in the crimes. ... They plan to restrict the sale of laser printers? This month's issue of "Byte" lists a relatively inexpensive software product that prints checks, including the MICR encoding, with a laser printer. Magnetic toner cartridges are available for about $150. So much for "... sophisticated check-printing equipment ..." Even if they restrict the sale of magnetic toner, most banks take the occasional unreadable MICR numbers in stride and simply re-encode them on a strip of paper glued to the original document. The sheer volume of checks processed makes examining even these special cases impractical. Jerry Hollombe, M.A., CDP, Citicorp, 3100 Ocean Park Blvd. Santa Monica, CA 90405 (213) 450-9111, -2483 {rutgers|pyramid|philabs|psivax}!ttidca!hollombe ------------------------------ Date: 26 Aug 91 15:12:01 GMT From: flint@gistdev.gist.com (Flint Pellett) Subject: Re: Microsoft, IBM demonstrating faults in each other's products JON@GAFFER.RAD.WASHINGTON.EDU (Jon Jacky) writes: >"... Mr. (William) Gates said he is angry about a demonstration by I.B.M. a few >months ago in which it showed how easy it was to make (Microsoft's software >product) Windows "crash" or stall. Microsoft responded last month by showing >securities analysts how easy it was to crash (I.B.M.'s software product) OS/2 >as well. ..." I don't mind seeing them throw stones: in fact, I hope to see more of it. Then maybe some of these industry giants will put a little money into making products that don't crash or hang instead of piling on more features most of us won't use. (It would be nice if other people, like UNIX developers, spent a little money in that direction as well, since the Dec 1990 CACM article on how 25 to 30% of UNIX utilities could be crashed or hung demonstrates they also need to.) Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint ------------------------------ Date: Fri, 23 Aug 1991 14:27:09 PDT From: Steve Bagley Subject: more about California's Automatic Vehicle Identification specification A brief addendum to Phil Agre's note in Risks 12.15 about the State of California's Department of Transportation and Automatic Vehicle Identification (AVI): The current version (dated 20 Aug 91) of the specifications for the compatibility of the AVI equipment is now a "Notice of Proposed Regulatory Action". There will be a public hearing about this spec in Sacramento on October 18, 1991. Written comments will be accepted up to that date at the address below. "Following the public hearing and comment period, the proposal may be adopted substantially as set forth without further notice." The section on encryption, in the current version, reads in total: "The encryption methodology to be used is defined with individual data message formats. There is no requirement that subsequent message definitions share encryption method [sic] with previously defined data messages." Elsewhere, the standardized DES encodings are referenced although the requirement to use encryption appears to be outside the boundaries of the technical specification. Each type of radio message between fixed receiver and mobile transponder has both an encrypted and unencrypted form. A rather short, but useful, section in the preface entitled "Informative Digest" details some of the history of AVI spec. Basically, in Sept 1990 Senate Bill No. 1523 added some sections to the Streets and Highways Code, that provided, in part, that "The Department of Transportation, in cooperation with the district and all known entities planning to implement a toll facility in this state, shall develop and adopt functional specifications and standards for an automatic vehicle identification system." "Requests for copies of proposed regulations or the initial statement of reasons, written comments, or proposed regulations and questions concerning the proposed adoption of the regulations and the public hearing should be addressed to: Les Kubel, Chief, Office of Electrical & Electronics Engineering Department of Transportation, Division of New Technology - Materials and Research 5900 Folsom Blvd., Sacramento CA 95819 (916) 739-2405" Comments about the Senate Bill are probably best addressed to your state representative and the Governor. --Steve ------------------------------ Date: Mon, 26 Aug 91 13:35:15 pdt From: pagre@weber.ucsd.edu (Phil Agre) Subject: California DMV AVI proposal It would seem that the version of the DMV's AVI proposal to which I was referring was out of date by the time I got around to writing my note. I hope that others with access to the newer version will report on it to Risks. Phil Agre, UCSD ------------------------------ Date: Fri, 23 Aug 91 12:43:21 +0100 From: Mark Evans Subject: Use of ATM for blackmail in UK TV script A recent TV program in the UK shows a police investigation into a crime (Indelible Evidence). A blackmailer worked by requesting that money be deposited into an account, which they then withdrew by ATM. There was a point in the program where a terminal was shown listing the card and account numbers of EVERY use of an ATM. (Such equipment had been set up initially covering all possible machines country wide. Surely it would have been possible to have the Bank's central computer recognise the card and put the location of use on a terminal, without needing to display details of any of the customers who may have used the machine.) Mark Evans, University of Aston, Birmingham, England ------------------------------ Date: Fri, 23 Aug 91 8:45:18 MST From: sunburn.West!gtx!anasaz!qip.john@fernwood.UUCP (John Moore) Subject: Desktop Forgeries (RE: Sherizen, RISKS-12.15) Sanford Sherizen posts comments regarding use of desktop publishing to forge paper documents: >The first is using computers to make duplicate copies of important documents. One wonders if this is significant in comparison to copies made by high quality copiers. >A related issue is the modification of documents, so that unauthorized changes >can be made and distributed on what appears to be authentic official >information. Employees and others can obtain documents or create their own This would seem to be a serious risk. In the electronic document world, much work has been done on the issue of cryptographic signatures, which both certify the signature and protect the contents from undetected alteration. Since most important documents today are generated by computer systems, is there any reason that the same technology could not be used for paper documents? When a document is generated, a cryptographic hashing function would be computed, and the result PRINTED on the document. With certain standardization on what is included in the hash, and what formats are used (no old English script, or whatever), the document could be validated using a scanner with associated crypto algorithm (probably using public keys). Is any work being done in these areas? Should it be? John Moore ------------------------------ Date: Thu, 22 Aug 91 23:49:43 EDT From: brad@looking.on.ca (Brad Templeton) Subject: Re: SSNs (Agre, RISKS-12.15) Phil Agre's not-uncommon story of the hassle he encountered in not giving his SSN to the power company made me wonder about the consequences of such actions. In an attempt to remain private, one is often required to make a big fuss and draw attention to one's self. I wonder if such contradictory behaviour might have bad consequences. Is somebody keeping a database of people who don't want too much information about them to be on file? ------------------------------ Date: Thu, 22 Aug 91 07:48:25 HST From: bob@kahala.soest.hawaii.edu (Bob Cunningham) Subject: sometimes you can only get there using the long way around The primary Internet link between North America and Asia uses circuits in HAW-4 undersea fiber optic cable between California and Hawaii, and from Hawaii, other undersea cable circuits to Japan and Korea (indeed, until recently most Internet traffic between North America and Australia went through HAW-4 as well, then via satellite between Hawaii and Australia; though recently they switched to a direct satellite link with California). At about 0100HST Saturday, repeater #37 on HAW-4 failed, bringing down all the circuits on the cable. An AT&T cable repair ship was dispatched from Honolulu on Saturday, has been on site since Monday, and at last report was still grappling to try to bring the repeater to the surface for repairs. The precise cause of the failure is not yet known. Estimates of full restoration of HAW-4 service range from several days to as long as a couple of weeks. Overseas telephone services were switched over to other, older (copper) cables and various satellites in a fairly straightforward manner. And while there's less trans-Pacific phone capacity now, I don't believe there's been much if any noticeable interruption of service. Overseas television flows primarily via satellite anyways, and as far as I know, hasn't been affected at all. Finding alternative computer network circuits turned out to be considerably more challenging. An alternate circuit using international satellite connections was set up between North American and Japan fairly quickly. But between the limited capability of the older undersea cables and a shortage of U.S. domestic satellite transponder capability (more precisely: an apparent shortage of transponders which can use "spot beam" capability with Hawaii), there didn't seem to be any way to set up an alternative connection between Hawaii and the rest of the United States. Until someone remembered that the circuits between Japan and Hawaii were still working perfectly well... As of approximately 1000HST Tuesday, Hawaii was reconnected with North America via: an international satellite link between California and Japan, and an undersea cable link between Japan and Hawaii. Only at 384Kbps (1/3rd of the former HAW-4 circuit speed), and it's a rather roundabout "bypass", but it seems to work quite well. ------------------------------ Date: Thu, 1 Aug 91 03:14:58 HST From: joe@montebello.soest.hawaii.edu (Joe Dellinger) Subject: Re: canopus.stanford.edu goes nova On June 18, 1990 I reported how the Hitachi monitor of my color Sun 3-110 workstation had suddenly released enough irritating fumes to prompt the evacuation of our (extremely poorly ventilated) Stanford building the previous evening. Here is the promised followup... Stanford Health and Safety was quite concerned about the incident; there are a lot of Suns at Stanford, and the fumes were still powerful enough a day after the event that persons entering my office would develop a headache and watering eyes within a few minutes. People in our building naturally wanted to know what toxic chemicals they were being exposed to. Health and Safety wanted to know if this might happen again. (I wanted to know when I could use my office again.) The Sun front-office people that Health and Safety first contacted insisted that this failure mode was virtually unknown and it would almost certainly never recur. We were suspicious of this claim, since in our research group we owned only six Suns of that particular model, and mine was the _second_ monitor to fail this way within as many years. (The first one fortunately had failed when the building was empty and when the ventilation was working better, so Health and Safety didn't get called that time.) My posting to risks which appeared a few days later netted a handful of accounts about similar incidents, mostly in Europe. More importantly, it prompted an immediate response from more informed people within Sun [Health and Safety was still trying to beat past the outermost layer of bureaucracy by telephone with little success]. Sun quickly retrieved the offending monitor from Health and Safety (who had carted it off and stored it as toxic waste) and launched an investigation. Sun determined the part that failed was a capacitor in the high-voltage line. This caused the flyback transformer coils to overheat, which in turn caused "a small amount of the case material of the flyback transformer to burn". Sun asked Hitachi, who made the monitor, to investigate what was in the resulting smoke. The conclusion was "There were trace quantities of a number of chemicals in the smoke. We do not believe that a short exposure to the small amount of smoke emitted represents a hazard to the individuals involved." Sun helpfully included a copy of Hitachi's lab tests showing what they got when they burned some transformer casing in a test chamber. It showed 10 parts per million CO (with 100 the maximum allowed by the American Conference of Governmental Industrial Hygienists), 800 ppm CO2 (no limit), 2 ppm Formalin (3 max allowed), 1.2 ppm Toluene (150 max), 1.7 ppm Ethylbenzene (125 max), and 3.4 ppm Styrene (100 max). This seemed strange to me; if the smoke were so innocuous why did breathing the air in my office still make me sick more than a day after the event, despite my best attempts to dissipate the fumes? I wanted to know how big a sample Hitachi had burned, and how much air the resulting smoke had been diluted in! The contact person at Sun seemed a little annoyed that I still wasn't satisfied, and resignedly explained again and again that "parts per million" was independent of the air volume. It didn't matter what size room the Sun was in, how good the ventilation was, or how much transformer case burned. I pointed out that it was a good thing my sun hadn't been outside, or the entire Earth's atmosphere would be contaminated with 2/3 the legal limit for Formalin. Right? They promised to get back in touch with Hitachi. Three months later I got another letter. It had the same numbers (in ppm) as before, and again had no information about the volume of the test chamber or the amount of transformer casing material burned in the test. It further patiently explained "All of the measured smoke constituents are significantly below OSHA's established minimum exposure levels. Since the smoke examined in the analysis is of the same type as emitted during flyback transformer failures at Stanford, no significant concerns are raised by the monitor failures you experienced." I tried calling and asking for clarification again, got the same explanations about ppm being independent of air volume (why couldn't I understand such a simple concept?!). Finally I gave up (after all the smell was gone by this time and there seemed to be no ill aftereffects). The second letter did have some interesting new information, however. Previously we had been told our monitor failures were practically unique; the new letter stated that "When the flyback transformer failure was discovered the total failure rate per month attributable to the flyback capacitors was only .4 percent. After the process improvement, which was promptly implemented, the failure rate was reduced to .04 percent. Although the newer model is superior, the older model was within the range of reasonable failure. Sun recognizes the frustration and disappointment that you must have experienced as a result of two monitor failures. This is an extremely unusual occurence [sic] and one that Sun would like to avoid in the future." Was it unlucky? We had 6 monitors for 3 1/2 years; given Sun's stated rate of .4% per month, the chance of at least one failure was 1.-(1.-.004)^(12*3.5*6) = 64%. Having 2 failures instead of just 1 _was_ probably a little unlucky. Was our problem _unusual_? Probably yes; from reading between the lines it sounds like the problem only occurred with certain smaller-sized Hitachi monitors delivered around the same time ours were, Sept 1986 - Jan 1987. Our bad luck was in getting 6 monitors from this batch, and then keeping them in near constant use for several years. The letter continued "Sun is prepared therefore to replace, at no charge, the four monitors remaining in the Department of Geophysics ... for your understanding that the failure rates are negligible and that in any event, monitor failures are unlikely to pose future problems." Our research group took the deal. Not surprisingly, the Geophysics department at Stanford has had no more such incidents since the monitors were replaced (despite a significant expansion in the total number of Suns in the building). Since my research group accepted the deal, I thought it was appropriate to wait until I graduated and had left Stanford before posting this. I do have a Sun on my desk here in Hawaii and like it a lot; I don't expect it will go "Nova" like canopus.stanford.edu did! I'll let readers draw their own conclusions about the various sorts of RISKS illustrated by my story... ------------------------------ Date: Fri, 23 Aug 91 14:09:25 -0700 From: Jack Goldberg Subject: FTCS 22--Symposium on Fault-Tolerant Computing Originally-From: MAA@ecs.umass.edu CALL FOR PAPERS 22ND FAULT TOLERANT COMPUTING SYMPOSIUM (FTCS 22) LAFAYETTE HOTEL, BOSTON, MA JUL, 8-10 1992 SUBMISSIONS AND INQUIRIES SHOULD BE SENT TO: DR. J. H. Lala, MS: 6F, C. S. Draper Lab., 555 Technology Square Cambridge, MA 02139 USA (Mark the envelope "FTCS22 Submission") Tel: 617-258-2235; e-mail: lala@draper.com; FAX: 617-258-4444 IMPORTANT DATES: ABSTRACTS DUE: OCT. 18, 1991; PAPERS DUE: NOV. 22, 1991 ACCEPTANCE NOTIFICATION; MARCH 16, 1992 The Fault-Tolerant Computing Symposium is the major international forum in fault-tolerant computing. Represented are specification, design, modeling, implementation, test, diagnosis, evaluation and validation of dependable and fault-tolerant computing systems. The symposium scope spans hardware, software and system issues. Original papers not submitted elsewhere are invited from all these areas. Also, solicited for special sessions are practical experience reports in fault-tolerant computing such as design and deployment of a system, field data on failures and recoveries, and correlation of field data with model predictions. Major topics include, but are not limted to: Fault-Tolerant Architectures, Safety-Critical Systems, Testing and Verification, On-line transaction Processing Systems, Fault Tolerance in Real-Time Systems, Defect Tolerance, Concurrent Error Detection in VLSI circuits, Software Fault-tolerance, and Modeling issues. INFORMATION FOR AUTHORS: Six copies of a 1-page abstract and a list of 5 keywords should be submitted before Oct. 18, 1991. Six copies of the paper (1-1/2 spaced, 12 point font) should be submitted before Nov. 22, 1991 and should not exceed 20 pages including figures and text. The paper should be accompanied by ten copies of a title page which includes: the title, author name(s), affiliations, mailing address, phone number, FAX number and e-mail, a maximum 150-word abstract, five keywords, an approximate word count and a declaration that the paper has been clear through author affiliations. For multi-authored papers principal contact should be indicated. Submissions arriving late or significantly departing from length guidelines, or papers submitted elsewhere must be returned without review. For industrial experience reports, the contributor(s) should submit six copies of a 5 - 10 page written description of the experience along with a one-page outline for a 5- 10 minute presentation. For panel session recommendations, submit the topic(s), names, addresses, and biographies of the proposed panelists, and a maximum two-page description of the panel objectives. This year marks the inauguration of technical exhibits at FTCS. Exhibitors from both industrial and academic communities are encouraged. This will be an opportunity to present advanced products to an informed and sophisticated audience. ------------------------------ End of RISKS-FORUM Digest 12.17 ************************