Subject: RISKS DIGEST 12.39 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 23 September 1991 Volume 12 : Issue 39 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Carpal Tunnel Syndrome strikes (Peter Mellor) Risks of technical translation (Bertrand Meyer) Patent for Travelmation on Fare-Search System (Bob Frankston) Rounding and truncating within multilevel software (Brenton Hoff) Re: SunOS SPARC Integer Division Vulnerability (Dik T. Winter) Re: Risks of mistreating programmers (Vesselin Vladimirov Bontchev) Re: Play the lottery via Nintendo (Mike Cepek) Re: documentation and the obsolete parts problem (Lou) Ideas made simple (Bob Frankston) Book review: Technological Risk, H.W. Lewis (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, 23 Sep 91 12:10:21 BST From: Peter Mellor Subject: Carpal Tunnel Syndrome strikes A friend of mine has suffered for years with what she thought was arthritis. About 18 months ago, she was diagnosed as having a classic case of CTS. She is due to have an operation to "depress the nerve in the wrist" very shortly and is a bit concerned about the likely outcome. A few people she knows have undergone the same operation with good results, but she has ben warned that the scar will be extremely sensitive for a long time. Does anyone out there have any experience, which I can quote to reassure or warn her? A have noticed a few curious things while this has been going on:- - All the people she knows who have suffered from CTS are female, and the affected hand has been the non-dominant hand. Is this a general rule? - The operation list at the consultant's surgery showed that he does around two CTS cases a week. That's one consultant in London, and only the cases severe enough to be operated on! How prevalent is CTS? Any statistics? - My friend is a highly-skilled touch typist (who for years trained other people to professional qualification standard), and very careful regarding the ergonomics of typing, position of seat, hands, etc. Why does CTS strike the professional, and not the idiot amateur like me, who types with one hand only (having lost the use of the other years back in a road accident), and whose idea of ergonomics is having the ash-tray and the coffee cup within easy reach? (I put in sufficient hours at a workstation to qualify for the "at risk" category, though!) All information gratefully received. (I am aware of the correspondence around RISKS-10.12 from Andrea Frankel et al., and have already passed on that information.) Peter Mellor, Centre for Software Reliability, City University, Northampton Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 p.mellor@uk.ac.city (JANET) [RESPONSES TO PETER MELLOR, PLEASE, NOT TO RISKS. I TRUST HE WILL SHARE ANYTHING SIGNIFICANT WITH THE REST OF US... Thanks. PGN] ------------------------------ Date: Thu, 19 Sep 91 12:07:27 +0200 From: bertrand@eiffel.fr (Bertrand Meyer @ SOL) Subject: Risks of technical translation Being interested in languages (both natural and artificial) I lent an ear to the following story, heard from a participant to a seminar I recently taught in Berlin. I tried to get the details right, but this is all hearsay and I can make no guarantee of accuracy. It appears that the UCSD Fortran (?) compiler had a confusing option which enabled programs to write to a ``device'' as well as to a Fortran ``unit''. In particular, unit 6 is the standard output in Fortran; but writing to DEVICE 6 rather than UNIT 6 would erase the whole disk... Such an event, disastrous as it was, could only occur as a result of some combination of bad luck and carelessness - for people using the original documentation. But according to my source the German translation used the word ``einheit'' as a translation for ``device''. (Apparently the translator also rendered ``unit'' by ``einheit'', which is indeed appropriate; but I am not sure of this point.) The result is obvious: in German-speaking countries an inordinate number of people lost everything as a result of erroneous write-to-device operations... Perhaps someone with first-hand experience can confirm or correct. Bertrand Meyer bertrand@eiffel.com (temporarily: bertrand@eiffel.fr) [In UNITy there is DEVICEiveness? PGN] ------------------------------ Date: 20 Sep 1991 20:28 -0400 From: Subject: Patent for Travelmation on Fare-Search System There is an article in the Sept 16th issue of Business Travel News. To quote one paragraph "The patent decision recognizes as unique Travelmation's system for checking its own database of fares and flight availability and automatically selecting low fares that conform to corporate travel policies." Later in the article, "Part of the patent also covers Travelmation's Trip Planner system, a program that allows travelers to send their travel requirements from a personal computer to Travelmation..." ------------------------------ Date: Sun, 22 Sep 1991 17:45 +0930 From: behoffski Subject: Rounding and truncating within multilevel software Rounding and truncating data can often get you into difficulties, as we found recently in our fuel management system. We collect data about refuelling transactions, and record the quantity of fuel measured and the price of the transaction. We report the quantity to the nearest hundredth of a unit (litres), and the price to the nearest hundredth of a dollar. Recently, one of our customers complained that at a price of $1.00 per litre of fuel, the quantity would sometimes be 0.01 higher than the price. What we found was that the program in the system that collected the transactions and forwarded them to the database handled the numbers differently: quantities were rounded to 2 decimal places, but prices were rounded to 3 decimal places (effectively tenths of a cent). The program which brought these transactions into the main reporting database then truncated the price to two decimal places. I believe that this truncation was unintentional. Our options in fixing this problem were: 1. Rounding the 3-decimal digit price to 2 decimal places. 2. Storing all 3 decimal places of the price. 3. Reporting the price to 2 decimals, instead of 3. Option 1 was quickly discarded: you must not round a number twice, as distortions creep in (0.4449 -> 0.445 -> 0.45 instead of 0.44). Option 2 was unacceptable: since every transaction report only reported 2 decimal places, the totals might be corrupted where they were computed using the unrounded price instead of the rounded display. Option 3 was chosen, so that the precision of the raw data agrees with the precision for individual transactions shown on reports. Given the accuracy of the fuel measuring equipment, the thousandths of a cent was mostly garbage. Just a small reminder of the hazards of truncation, rounding and significant digits. Brenton Hoff (behoffski) | Senior Software Engineer | My opinions are mine xtbjh@Levels.UniSA.edu.au | AWA Transponder | (and they're weird). ------------------------------ Date: 21 Sep 91 01:00:03 GMT From: dik@cwi.nl (Dik T. Winter) Subject: Re: SunOS SPARC Integer Division Vulnerability Newgroups: comp.risks, alt.security OK, some sensible information from Barry Margolin : > The patch replaces the C runtime library linked into the kernel; > we disassembled the old and new versions and compared them (actually, we > only disassembled the portion that implements the C integer division > operator, because of the description of the bug). I intended to do that, but never came to doing it, although apparently I only needed to look at the code presented in Version 7 of the Architecture manual on page 183! > The change has to do with the action taken when division by 0 is detected. > In both cases, it does a "ta T_DIV0", i.e. signal a division-by-zero trap. In the Architecture manual it says "te ST_DIV0", not a big difference. > The old code assumed that this instruction would never return; if it did, > it fell through to the rest of the code that implements division, and > presumably gets some wrong answer. The new code is prepared for the trap > instruction to return, and the operator returns 0 in that case. Yup. In the first case, who are you if you return from the second trap? And who are you when you return again? > Note that the description of the vulnerability is somewhat misleading. The > perpetrator doesn't gain privileges by using division in his own program. > He somehow has to get the kernel to try to divide by zero; I suspect the > vulerability is that the kernel then might use the result as in array index > into some kernel structure (e.g. the u area). No, not true. With version 8 of the architecture Sun introduces instructions for multiplication and division. These are on non-version 8 machines trapped as illegal instructions and emulated in software (since SunOS 4.0?). > As far as I'm concerned, the fact that the kernel ever even *tries* to > divide by zero is a bug. True, but the reasoning is wrong. Why is this code executed in kernel mode? It ought to be executed in user mode. The same holds by the way for a number of fp emulation routines, plus some more. The risk is that people concentrating on getting there emulation code right are also bothered by security issues. The fix is completely bogus (although it serves as a kludge or hack). When something has to be done to support the user for which kernel mode is not needed, the processor should go in user mode. I think that Sun failed big with its traps on unimplemented instructions. Just try to single step under adb an instruction that adb knows about but as does not; expect a panic. dik t. winter, cwi, amsterdam, nederland dik@cwi.nl ------------------------------ Date: Thu, 19 Sep 91 09:25:15 +0200 From: news@rzsun2.informatik.uni-hamburg.de (Mr. News) Subject: Re: Risks of mistreating programmers (Welch, RISKS-12.36) Well, since probably I am the source of the information, permit me to add my two cents worth. Yes, the above is mostly correct, althoug a bit scatchy. For more information, see my paper "The Bulgarian and Soviet Virus Factories", published in the proceedings of the First International Virus Bulletin Conference on Computer Viruses, which was held in Jersey, UK, September 12-13. A slight correction of your message - the town mentioned is Sofia (not Sophia) and it is the capital of Bulgaria. :-) The BBS mentioned really exists, it is called Virus eXchange, SysOp is Todor Todorov, and it is indeed specialized in virus exchange and virus discussion between virus writers. I'm really sorry, but this is not illegal in Bulgaria, so we really cannot stop them. :-(( Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Sun, 22 Sep 1991 11:16:23 CDT From: "Mike Cepek, MGI" Subject: Re: Play the lottery via Nintendo (RISKS-12.27) In followup to the article I repeated here recently, George Anderson, director of the Minnesota State Lottery, writes in the Sun 22 Sep 91 Minneapolis [MN] Star Tribune "Letters from readers", (pg 22A): [...] The play at home test will use Nintendo's control deck, a modem by which the deck communicates to the Lottery computer and a Lottery cartridge. Transactions occur much as they do in the terminals found at our retailers across the state. The cartridge will not be available through retail outlets. No "children's games" are involved. Only existing Lottery games will be available. Adults must preregister, predeposit (no credit play) and prove their age. Adults will control a password for limited access. The deck will shut down if incorrect passwords are entered or if the machine is left unattended. Daily play will be limited. Statements will be [mailed]. [...] The control deck has enormous potential for interactive transactions -- it is used in Japan for personal banking and stock transactions. Control Data Corp. and the Lottery believe that this test will demonstrate that the security and controls over player access removes the specter of minors' play, even as it provides the convenience demanded by Lottery players. Oh, yes, lottery players here in Minnesota are quite near rioting at how inconvenient it is to have to go to the nearest gas station or quick mart to play! Seriously, I'd like to know more about how the Japanese use it. Security issues must have been adequately addressed for people to be comfortable playing with their money via Nintendo. Or maybe there aren't any hackers in Japan? ------------------------------ Date: Sat, 21 Sep 91 23:55:22 EDT From: lou@cs.rutgers.edu Subject: Re: documentation and the obsolete parts problem In RISKS-12.38, Stanley (S.T.H.) Chow comments on the military's "obsolete parts" problem (the difficulty of obtaining obsolete replacement parts for military systems). He says: >Given the well-known mountains of paper that the Pentagon requires for any >hardware, and the many mil-spec's for documenting and testing any and >everything, it is quite a surprise to me that anyone should need to reverse >engineer anything. [...] >Even excellent documentation is useless, Unless you can find it again. I was peripherally involved in one effort to get around the obsolete parts problem, and my impression is that the problem is NOT in finding the old documents. The problem is is that you can't rely on the documents. They are often out of date or incomplete. There is always that one last minute design change to fix the "final" (:-) bug, that may well not make its way into the formal documents. The basic problem is that there is no affordable way to check whether the documents are correct, and without checking such documents aren't much more reliable than an untested program. ------------------------------ Date: 21 Sep 1991 23:01 -0400 From: Subject: Ideas made simple This is a copy of a letter I just FAXed to Business Week in response to their article that presents object oriented programming as the grand solution to all software problems. This is absurd, but it is hard to blame Business Week by itself when many within the industry espouse such views and some even believe it. As we've seen in some of the recent articles on representations many of the fundamental difficulties aren't even related to programming as such. As we try to model the real world in our computer systems we are discovering what a messy place it is. But wouldn't it boring otherwise? I apologize for the tone of this article, the moderator suggested that I be stronger. In appropriate circumstances I would much more forceful but I think this letter represents the limit of what I can explain to a publication like BW. Feel free to send your own comments. The fax number of "Readers Report" (letters to the editor) is 212-512-4464. To: business week From: Bob Frankston Date: (09-21-91 22:49:19) Subject: Ideas made simple At the risk of great oversimplification, I'll be extremely brief. In doing so, I appreciate your difficulty in covering complex issues of technology in a small amount of space in a general (albeit business) publication. Your two recent articles, one on user interface and one on software development do a disservice by announcing "solutions" to complex problems. In your recent article on simplified controls for consumer appliance such as VCRs you gloss over the fact that good (interface) engineering involve more than just limiting capabilities until products become trivial to use. While this is indeed a valid and often appropriate technique, the problem faced by product engineers is presenting the user with access to advanced capabilities in a way that makes them obvious without being trivial. In a similar vein, the problems of developing software are not suddenly solved by the use of "objects". Like structured programming, modular programming, programmer teams, databases, relation databases, automatic programming (now called programming languages), object-oriented programming is yet another useful tool. But it doesn't magically solve all problems. In fact, some of the capabilities described in the article are more the result of taking advantage of the additional power of today's computer systems than completely new techniques. Many of the traditional programming techniques represent engineering tradeoffs given the limited slack available and not just ignorance. With more powerful systems, more attention can indeed be played to assembling components rather than crafting each one. But we still have much to learn about what the components should be and how they can fit together. As you pointed out in this article, to some degree the task is one of finding programming analogues to real world complexity. If we indeed reflect the complexity of the real world, why should it suddenly become simpler when it is modelled in a computer? In other articles Business Week has explained that "reengineering", or the process of rethinking a system as a whole, is much more effective than naive modelling. In contrast, the Software Made Simple article advocates mimicking existing systems. I do sympathize with the difficulties of presenting ideas concisely and understandably. In writing this letter I too have had to resort to extreme simplification. The price is a loss of accuracy. But simplifying shouldn't mean misleading the reader by suggesting that we have a grand solution to an intrinsically complex problem. Personal Categories: Use Inner Header: Delivery Priority: High Delivery Report: Basic Receipt Report: Sender phone number: 617-945-9199 (Personal Pager) Sender fax number: 617-244-1567 Cover Text for Faxes: Cover Page for Faxes: ------------------------------ Date: 22 Sep 1991 10:55 -0400 From: Subject: CANCEL: Ideas made simple You think BW shuts off its FAX machine on weekend or do they just get overwhelmed after a particular stupid cover story? To: Bob Frankston| EMS: Slate Corporation| MBX: Bob Frankston cc: From: MCI Mail Fax Service| EMS: MCI Mail| MBX: POSTMASTER @ mci @ FRANKSTON Date: 09-22-91 03:10:00 (09-22-91 03:39:37) Subject: CANCEL: Ideas made simple Your fax message To: Readers Report Destination Fax: 212-512-4464 Date/Time Sent: Sun Sep 22, 1991 3:02 am GMT Message ID: 24910922030242/0004464426NC4EM was not delivered. Date/Time Cancelled: Sun Sep 22, 1991 7:10 am GMT Delivery Attempts: 12 Cancellation Code: 0015 - Ring no answer For online assistance type HELP FAX CANCEL or contact MCI Mail Customer Support at 800-444-6245 (U.S. only) or 202-833-8484. Please retain the information contained in this cancellation when calling for assistance. ------------------------------ Date: Mon, 23 Sep 91 13:48:35 -0700 From: Jack Goldberg Subject: Book review for risks I found the book "Technological Risk" by H.W. Lewis, W.W. Norton & Co., 1990, to be a very thoughtful and readable introduction to risk assessment. Lewis is a professor of physics at UC Santa Barbara and has chaired numerous government risk assessment committees. The dust cover has high and accurate praise from Hans Mark (former deputy administrator of NASA), W.H. Press (professor of Astronomy and Physics at Harvard) and James Schlesinger (former Secy of Defense and Secy of Energy). The first section, Generalities, talks about the risks and value of life, the measurement, perception, politics, assessment and management of risks, and "The delusion of Conservatism". The second section, Specifics, gives examples from toxic chemicals, chemical carcinogenesis, highway safety, air transportation, ionizing radiation, fossil fuels, nuclear winter and non-ionizing radiation. There is no major discussion of computer risks, but the subject is touched on in discussions of air transportation. Lewis has lots of experience. The book has much wisdom and is free of dogma. It is also a pleasure to read. ------------------------------ End of RISKS-FORUM Digest 12.39 ************************