RISKS-LIST: RISKS-FORUM Digest Monday 17 July 1989 Volume 9 : Issue 6 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Mitnick sentenced as an addict (Rodney Hoffman) Long addresses confuse bank's computer (Paul Leyland) Town Hall's computer snags trouble old age pensioners (Olivier Crepin-Leblond) Re: Automobile Electronic Performance Management (Charles Rader) Re: UK Defence Software Standard, non-determinism, recursion and armageddon (Victor Yodaiken, anonymous via Tim Shimeall, Bob Estell, Martin Minow) Telephone technicians tapping into other phone lines (Olivier Crepin-Leblond) Re: New Yorker Article on "radiation" risks (Gordon Hester) RISKS SUMMER SLOWDOWN AHEAD. CONTRIBUTORS PLEASE BE PATIENT. THANKS. PGN The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. * RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j, ftp KL.sri.com[CR]login anonymous (ANY NONNULL PASSWORD)[CR] get stripe:risks-i.j ... (OR TRY cd stripe:[CR]get risks-i.j Vol summaries (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99),(8.88). ---------------------------------------------------------------------- Date: 18 Jul 89 08:49:34 PDT (Tuesday) From: Rodney Hoffman Subject: Mitnick sentenced as an addict Kevin Mitnick is the hacker once called "as dangerous with a keyboard as a bank robber with a gun." (See RISKS 7.95, 8.1, 8.3, 8.43, 8.65, 8.70, and 8.76.) His first plea bargain was rejected by U.S. District Judge Mariana R. Pfaelzer as too lenient. He subsequently reached a new agreement, with no agreed-upon prison sentence, in which pleaded guilty to stealing a DEC security program and illegal possession of 16 long-distance telephone codes belonging to MCI Telecommunications Corp. If convicted of all counts, Mitnick faced a maximum sentence of 20 years and a fine of $750,000. According to a story by Henry Weinstein in the 18 July 1989 'Los Angeles Times', Judge Pfaelzer said Monday that she will sentence Mitnick to a year in a rehabilitation center, where he can be treated for his "addiction." It is believed to be the first time a person indicted for a computer hacking - related crime will be treated as an addict. Harriet Rossetto, the director of the rehabilitation center said that Mitnick would benefit from the program. She said that Mitnick's "hacking gives a sense of self-esteem he doesn't get in the real world.... This is a new and growing addiction . There was no greed involved. There was no sabotage involved.... He's like a kid playing Dungeons and Dragons." Asst. U.S. Attorney James R. Asperger told Pfaelzer that he was amenable to the rehabilitation plan, in part because Mitnick has cooperated extensively with the government in its case against DiCicco, Mitnick's one-time friend who turned him in. Asperger said that Mitnick had turned out to be considerably less harmful than the government had originally thought, particularly since he not broken into DEC's computer system out of malice or to make money. Judge Pfaelzer said she will rule today on whether Mitnick should serve any additional prison time, beyond the seven months he has so far spent in federal custody. DiCicco still faces one federal charge of illegally transporting a stolen program (!). ------------------------------ Date: Tue, 18 Jul 89 15:04:00 BST From: Paul Leyland Subject: Long addresses confuse bank's computer In today's copy of "The Times" (of London), there is a sketchy description of problems which arose from the country's first flotation on the stock exchange of a building society. [For the benefit of non-UK readers, a "building society" is an organisation whose purpose is to collect deposits from its members; pay them interest on the money; provide mortgages secured on property and collect the interest due on the loan. Sort of like a bank, but more restricted in what it can and cannot do. I forget the name of the US analogue.] It is only recently that building societies have become allowed to raise finance by public flotation and there has been much heated debate about the morality of the operation. In particular, people with accounts at the Abbey National Building Society were guaranteed cheap shares at the flotation. Lloyds Bank, who handled the flotation, are the third largest bank in the UK -- certainly *not* a tin-pot outfit. The following is from "The Times", Tuesday 18 July 1989. Compensation offer for Abbey delay. Lloyds Bank Registrars are offering to compensate 120,000 Abbey shareholders whose share certificates and return cheques have been held up in the post. This group suffered because their addresses were jumbled up by the computer, which was unable to read addresses with more than five lines. It was originally thought no more than 10,000 people were affected by this error, but it emerged last night that 120,000 people are involved. The Abbey National has already said it will back-date -- to Wednesday, July 12 -- delayed cheques that are returning sums over-paid for shares, if they are paid into an Abbey National Account. But many would-be share owners say they have borrowed large sums to buy shares and the delay in returning cheques is costing them missed interest and also interest on loans. All Abbey members who applied for more than 600 shares at 130p were scaled down to 775 shares. As a result, some people who made massive applications are awaiting the return of hefty cheques. Mr Charles Wootton, a member of the Abbey National Protest Group, who applied for 100,000 shares at a cost of \pounds 130,000 [[approximately US$ 200k]], said that he had lost interest on the money taken out of a higher interest account. "They have had our money for an awfully long time", he said. It is unprecedented for Lloyds Bank Registrars to offer compensation for a bungled share allocation, but a Lloyds spokesman said: "The scale of the thing was unprecedented". Lloyds is writing to the 120,000 people whose addresses were jumbled by the computer asking if they had any special problems. Each compensation claim will be dealt with individually on its own merits. Lloyds will want proof that a loan was outstanding against the cash used to apply for shares. There is no question of any compensation for the slide in the Abbey share price from a brief high on the first day's trading of 161p to 145p yesterday. [I wonder what 120,000 personal letters and investigations are going to cost.... Paul Leyland] ------------------------------ Date: Mon, 17 JUL 89 19:35:08 GMT From: ZDEE699@elm.cc.kcl.ac.uk Subject: Town Hall's computer snags trouble old age pensioners TOWN HALL'S COMPUTER SNAGS TROUBLE OAP'S [OCL. Old Age Pensioners] [From the Kensington and Chelsea Times, a [very] local newspaper] Many private tenants in Kensington & Chelsea are living in poverty as a result of the council's inability to cope with its housing benefit work- load, claims Kensington & Chelsea "Put for the Elderly". "Everyone who claims housing benefit must fill-in a new benefic appli- cation form every year", says the group. "If the application is not received by the Housing Benefit Office within four weeks, a reminder is sent-out and if this is ignored, housing benefit is stopped." "However, in Kensington & Chelsea, payment is bein gstopped because council staff are unable to feed the information into the computer quickly enough. There is a huge backing of such information waiting to be logged into the computer's memory." It is alleged that Housing Benefit payments have been stopped for "hundreds" of people while their re-applications wait to be dealt-with. "It can be weeks before payments resume." "This is particularly hard on senior citizens who are known as society's most conscientious bill-payers. Many older people will go without, rather than get into debt." The Royal Borough Council admits that there is a problem, and expresses its intention to remedy the situation. "There has been a backlog but we hope to have the situation under control by the end of the month". A report by the Royal Borough Council's Benefit Working Party analyses the reasons for the build-up of work in the benefit's division: " The computer is not powerful enough to cope with the heavy demands that are being placed upon it. Consequently, the officers are struggling to process assessments sufficiently quickly to match incoming work. There have been a number of computer crashes in recent months, resulting in a lot of 'down' time." The report continues: "The computer software developed a fault which resulted in our inability to produce the weekly notification letters that have to be sent to the claimants. This continued for some eight weeks during March and April this year, and meant that when the fault was rectified, there was a large backlog of letters produced. "Statuory case reviews have brought about large numbers of claims being processed. Between April 1988 and March 1989 it was not possible to undertake these reviews because of computer difficulties. Olivier Crepin-Leblond, Computer Systems & Electronics, Electrical & Electronics Engineering, King's College London, England ------------------------------ Date: Mon Jul 17 01:13:23 1989 From: Charles Rader Subject: Re: Automobile Electronic Performance Management I have three anecdotes related to this topic. First: A personal experience several years ago suggests General Motors enforces the "performance envelope" on its cars. While descending a steep mountain grade in a 1981 Chevrolet Cavalier using engine braking to control speed, the automatic transmission shifted into second gear even though the gearshift lever remained locked in first gear. The engine speed was near the "yellow line" when it shifted, so I suspect this was a feature intended to prevent engine damage. The behavior was reproducible. I had left GM for my present job and didn't ask my GM contacts about it. In this case, I had good brakes. What if the brakes had failed? Second: I heard of an incident several years ago where electronic component failure caused a vehicle to exceed the design envelope. During quality assurance testing at an assembly plant (on dynamometer rollers), a cruise control component failure caused wide-open throttle and loss of brakes. The technician cut the ignition before the engine destroyed itself. The design problem was apparently fixed before it recurred. I wasn't present when this happened so I'd rather not name the company or plant, but the story was reported by individuals I trust to have the facts. Third: Bootleg PROMs exist in North America, too. Some auto company engineers have mentioned programming them for personal use. Charles Rader, Systems Manager, Univ. of Detroit Computer Services, 313-927-1349 ------------------------------ Date: Sat, 15 Jul 89 20:14:52 EDT From: yodaiken%ccs2@cs.umass.edu (victor yodaiken) Subject: non-determinism, recursion and armageddon I'm puzzled as to what Nancy Leveson means when she uses the term ``non-deterministic". Leveson seems to be arguing that any program with hidden side effects is non-deterministic. The dangerous techniques she mentions, distributed processing, interrupts, dynamic memory allocation, recursion, have in common an effect on program state that are not exposed in the program text. That is, to verify a recursive subroutine written in Pascal, one needs to also verify the stack management methods of the compiler, and the memory limits of the machine. As the entire Hoare/Floyd etc. approach to verification is based on reasoning about program text, these techniques can pose problems for the verification method. I have 4 critiques of this analysis (3 technical, 1 horrified): 1. The inability of a verification system to handle a programming technique does not imply that the technique is at fault. The verification method might just be too weak. 2. Even if we give up all these very useful techniques, there are still hidden side effects in programs, especially real-time programs, which cannot be deduced from the program text. Subroutine call stacks may overflow, even without recursion, and access to statically allocated memory is not necessarily uniform ( suppose that A[i] is compiled to a single machine operation for i < 256 and requires segments and some other mess for i >255). 3. Hidden side effects != non-deterministic. A non-deterministic system can react to one input in more than one way --- there is no way, even in principle, to deduce output from input. But, even poorly written programs are deterministic --- the same environment will cause the same execution trace. Am I confused here, or is non-determinism being used in some other way. 4. If X (name your favorite agency or company) is going to have the gall to develop programs that might kill millions of people when they fail, e.g. nuclear reactor control programs or missile control programs, then X should at least have the decency to hire the best programmers for the job and have the entire system checked out by technically competent experts ( at least several independant certifications would also seem reasonable) Leveson seems to be saying that since military programmers, and the people who certify military programs are sometimes bad, we should force them to use very simple programming methods. The following quote (from Leveson) gave me the shakes. >Although I have great confidence that David >Parnas or Edsgar Dijkstra could use ANY techniques with great skill, I >have less confidence that this is true for all the programmers writing >military software. ... >Remember, we are talking about a potential nuclear >armageddon here and with certifiers who may be no more knowledgeable >than the programmers. The rational approach here is to send a check to SANE (CND for Brits), not to try to forbid recursion. ------------------------------ Date: Mon, 17 Jul 89 12:17:17 PDT From: shimeall@cs.nps.navy.mil (Tim Shimeall x2509) Subject: Re: UK Defence Software Standard [Forwarder's Note: The following is a statement by a close friend, who wishes to remain anonymous but asked me to forward this statement to risks. His comments do not apply to his current employer, and any identification of him might generate misunderstandings. My friend does read RISKS, and any personal replies may be addressed to me and I will relay them. Tim] I have some experience in working in a RISKy (non-aerospace, non-military) branch of the software industry, and for this reason I have read with interest and increasing concern the debate in risks over UK Defence Software Standard. My concerns are not so much with the standard itself, as with the academic viewpoint reflected in the arguments stated there and their broader implications for those of us who worry about software quality in the real day-to-day world. The basis of my concern is the assumption that either all software engineers working on RISKy projects would understand well such concepts as recursion, multi-tasking, and dynamic memory allocation, or that only people with these qualifications would be assigned to work on such projects. I do not have the academic credentials of Professor Parnas, but I do have a number of years of experience in QA and Test of software in the real world. I have been responsible for the evaluation of well over 100 pieces of software. Only a small fraction of the engineers working these projects understood well the nuances of the methods listed above. Most of them have never heard of Dijkstra, and of the few who have, none to my reasonably accurate knowledge have ever read anything he has written. Many of them have only high school diplomas or AA degrees in electronics. The point I am trying to make here is that, rightly or wrongly, the real world does not reflect the academic one in these areas. In my experience, the aerospace companies generally have much better educated software engineers, but even there, many of them have not been to school in over 20 years. For this reason, I think that instructing or allowing the average software enginner in industry to use some of these techniques in life-critical applications is a lot like putting a loaded 45 into the hands of a child. Thus, in my humble and very pragmatic opinion, statements by Professor Parnas such as: > Nor, would I agree that non-determinism is bad. Non-determinism has been > demonstrated by Dijkstra (and much earlier by Robert Floyd) to allow > programs that are much more easily verified than some deterministic ones. > I believe that organisations such as MoD would be better advised > to introduce regulations requiring the use of certain good > programming techniques, requiring the use of highly qualified > people, requiring systematic, formal, and detailed documentation, > requiring thorough inspection, requiring thorough testing, etc. > than to introduce regulations forbidding out the use of perfectly > reasonable techniques. To be very naive. Professor Parnas has experience with aerospace, but in many other software industries with life-critical applications things are much worse. These industries would hire people with the kind of qualifications he discusses were they available. The fact of the matter is that the people are simply not there. Thus it seems to me that the best approach to take is to develop standards designed to work with the present environment, rather than try to build standards designed to work in the environment that should be. Comments to me may be made via Dr. Shimeall. Thank you for considering the views of one eminently less qualified on academic grounds. These opinions are my own, and are not the opinions of either Dr. Shimeall or my present or previous employers, both of whom would be very upset to find that I had expressed them in public. ------------------------------ Date: 17 Jul 89 15:31:00 PDT From: "FIDLER::ESTELL" Subject: polling vs. interrupts: some perspective' A comment on the "interrupt vs. polling" debate, if I may. I submit that which is better is very much a matter of perspective; and further, that the perspective is scenario or (environment) dependent. If one takes the point of view of the "operating system kernel" looking from inside ONE processor, out to the world, AND *IF* that world is simple and small, and *docile*, then polling is very straightforward. Using Prof. Einstein's rule [... simple as possible, but no more ...] perhaps then polling is to be preferred, in those cases. However, as the world [system] grows larger, more complex, and less well behaved, polling becomes enormously more complex. Not the least of the problems is, what algorithms does one use, when and how, to handle emergencies [call them "interrupts" is you wish] that occur randomly, in such a way that the priority of handling them MUST change? Example: In a tactical combat system, implemented on several processors, distributed among several sites (with at least 2 but at most say 7 processors per site), a normal goal is to share messages in real time; under fire, however, most especially when one or more processors at any given site may suffer damage, priority swiftly shifts towards defending oneself; i.e., the "data link" module becomes somewhat less important than the "track and shoot" modules. However, since coordinated fire is often more effective than "self defense" fire, some link should be maintained. Perhaps we can learn from successful (?) systems significantly more complex than those we seek to build; e.g., ourselves. SOME of our sensors usually do polling; e.g., our eyes; occasionally we get interrupted by flashes of light; but more often, we scan the scene. However, our ears most often operate on interrupts. And our brains use adequate algorithms to process and correlate those diverse data. Bob ------------------------------ Date: 17 Jul 89 21:34 From: minow@bolt.enet.dec.com (Repent! Godot is coming soon! Repent!) Subject: re: Non-deterministic interrupt handling In risks 9.5, Dave Parnas writes: >The non-determinism associated with interrupt handling comes from the unknown >timing of the external events and is not affected by the replacement of >interrupts with polling. Much of the variation in interrupt handling comes from other operating system processing, such as (in modern computer systems) page-faulting and job/swap/memory management. Also, in very modern systems, the hardware instruction and data cache mechanisms introduce additional variation. This is true in all aspects of interrupt processing: not just in the response time as measured in the user's program. It should also be noted that there are "real-time" operating systems that are carefully designed to allow interrupt-driven I/O with minimal variation. Variation caused by the system itself (for example "uninterruptable" instruction sequences for managing system queues) is still a problem, however. > If, because I am forbidden to >use recursion, I write a complex program that does the stacking and >backtracking hidden by recursion, I am likely to introduce more errors than >were present in the compiler's well-tested implementation of recursion. Perhaps, but these are usually the kinds of bugs that are caught during initial testing. "Recursion bugs" in bounded systems are often not caught, but discovered when some combination of data causes the stack to overflow into another variable's (or task's) data storage. One "real-time" system that I developed had a stack boundary check routine in its "idle task." (This was *not* a safety-critical system, by the way.) [Confession: I added these checks after taking Nancy Leveson's Software Safety seminar.] >Similarly, if I introduce busy waiting and polling in my programs because I >cannot use interrupts, I may again make things worse rather than better. Good software engineering will make low-level mechanisms (I/O strategies) invisible to the high-level programs. On Unix, for example, device drivers log errors by calling a printf() function that busy-waits output to the console. The format of that function is identical to the interrupt-driven printf() that normal user programs call. Martin Minow minow%thundr.dec@decwrl.dec.com The above does not represent the position of Digital Equipment Corporation ------------------------------ Date: Mon, 17 JUL 89 19:48:19 GMT From: ZDEE699@elm.cc.kcl.ac.uk Subject: Telephone technicians tapping into other phone lines There is a rumour going round in the South of France (French Riviera) concerning telephone technicians servicing grouping boxes, and since "there is never smoke without a fire", I believe it has to be taken seriously. The technician traces a friend's line and calls him. He then connects the line to someone else's line, and tells his friend that he can phone free for the next 30 minutes. As a result, that person can call free of charge. The person who pays is the owner of the other line. After the 30 minutes, the techinician interrupts the conversation, and eventually connects his friend's line to another line, etc. etc. The bills received by the people paying for the conversation are only slightly higher than usual and the whole thing goes un-noticed. But the word spread round, and it seems that the trick has gone out of hand. Normal users are complaining of being often cut-off, or having a third person joining in their conversation, and of varying phone bills. The answer from the French Telecom, is to ask for itemised bills. And believe me, it comes as a shock when your bill says that you've been calling St. Bartholomew and you don't even know where it is ! Olivier Crepin-Leblond, Computer Systems & Electronics, Electrical & Electronic Engineering, King's College London, UK ------------------------------ Date: Fri, 30 Jun 89 20:45:47 -0400 (EDT) From: Gordon Hester Subject: Re: New Yorker Article on "radiation" risks There have been a couple of postings about the series of New Yorker articles by Paul Brodeur recently. I happen to work (as a researcher) in the area of electric and magnetic fields (EMF) risks. (The use of the term "radiation" by Brodeur is a complete misnomer, by the way - he's talking about fields.) I'm not a health effects researcher - my field is risk communication and public policies for risk management. Anyway, I would like to pass along a couple of comments. The first comment is that no one really knows at this point whether there are risks (i.e., adverse health effects) from EMF. Scientific investigation in this field is very complex and difficult. There have been a lot of flawed studies (with both positive and negative results.) There are clearly demonstrated biological effects, but no one knows whether these cause health effects. (The alternative is that the body adjusts to the biological effects, or that they are somehow unimportant.) There is certainly reason for sufficient concern to continue to fund research, although money has been hard to come by in this area as a rule. A little more support seems to be forthcoming recently. Second, Brodeur's descriptions of the ways scientists have supposedly "cooked" their data to suit the preferences of funding sources are, in large part, B.S. Not that none of this has ever occurred - it has, and on both sides of the issue. But it is the exception, not the rule by any means. There are some good scientists working in this area, and they are men and women of high integrity. Their's are the results worth taking seriously, and fortunately they are getting the lion's share of the funding these days. The third thing, in case it's not obvious to anyone who read the articles, is that Brodeur is anything but an unbiased observer. He has reached his own conclusions, and is seemingly out to convince people no matter what it requires saying. Notice that, for example, according to him it's only the scientists who come up with negative results (on health effects) who are cooking their data. I would caution net readers against relying on these articles as your sole source of information if you have a serious interest in this topic. If you do, send me email if you want recommendations for other sources.) BTW, despite my reservations about the Brodeur articles, the most recent posting to the net on this topic (sorry, I don't have the name handy) did pick out some interesting points from them. gordon hester, carnegie mellon u., department of engineering and public policy pittsburgh, pa 15213 gh0t+@andrew.cmu.edu ------------------------------ End of RISKS-FORUM Digest 9.6 ************************