RISKS-LIST: RISKS-FORUM Digest Wednesday 20 April 1988 Volume 6 : Issue 65 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Creating Alternatives to Whistleblowing (Vin McLellan) Safety nets under falling bridges (Rob Horn) Datamation, 15 April 1988, on "Risk" (Martin Minow) Poorly designed error messages (Bob Larson) RISKy Airline Meals (Mark Jackson) Response-time variability -- prior art (Martin Minow) Re: Security of OS: who is responsible? Klaus Brunnstein Israeli Viruses (Fred Cohen) Time-zone problem (Peter Webb) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, ftp kl.sri.com, get stripe:risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: Tue 19 Apr 88 05:56:14-EDT From: "Vin McLellan" Subject: Creating Alternatives to Whistleblowing On April 14, an MIT graduate student organization sponsored a forum on Ethics in Engineering and Science which turned into a discussion of whistle-blowing: what can lead an engineer to consider it, how it can be done, and how badly one can expect to be punished for being the messenger bearing troublesome news. Sylvia Robins, the Rockwell software engineer from the space vehicle program who protested fraudulent and fudged testing, lack of required security, and contract featherbedding up the line within her company, Unysis, and then jumped into the hierarchy of the prime contractor, Rockwell, was a brisk, impressive, and inspiring example of the breed as she spelled out the difference between a salary hack and a self-respecting professional. With lives and important missions at stake, she said, she couldn't and wouldn't participate in massive and normative fraud. As a result, Robins said, she has been bugged, tapped, followed, slandered, had her property vandalized, and was subjected to repeated threats, even assaults. Robins' story has been reported in detail elsewhere (and recent federal charges seem to substantiate many of her specific complaints) but she gave the MIT kids a few thought-provoking bulletins from the real world. According to Robins, at Rockwell the Corporate Ombudsman and the Corporate Ethics Office are both managed by the corporate security staff -- the very thugs who apparently saw their duty in orchestrating the campaign against her within and around the company. (When she returned to her office after she finally went public with her charges at a press conference, the walls at Rockwell closed in around her -- literally. The partitions that shaped her workspace had been moved to crowd her desk: she could reach out, seated at her desk, and touch both sides of the room.) Lone messengers really do get the shaft, she said, no matter how real or accurate their complaints -- although sometimes, even so, a woman has to do what is right. Robins said she now realizes that many engineers unexpectedly find themselves confronted with major ethical issues on the job; in the past six months, she said, some 160 engineers have contacted her for advice in how to deal with such situations in their work. Among her bitter lessons, she said, was that anyone caught in her position should try to build a consensus among peer engineers and, if at all possible, to present major complaints in a group petition. A whole department is harder to ignore, slander, or ostracize. For a lady with a rep for a carbon steel spine, her suggestions and attitudes were politically savvy and not confrontational. Beside the pert matronly Robins, a slouched yet looming presence on the MIT stage was fellow panelist Ralph Nader. (Astonishingly, this was only the third time in 15 years that Nader -- still probably the leading critic of poor and unsafe engineering knowingly foisted upon the public -- had been invited to speak at MIT.) While the planning of the forum left much to be desired, in that Nader was given only 20 minutes to address a crowd largely drawn by his name, his sardonic and bitter humor brought an edge to what had been a sometimes blithering panel. After paying warm homage to the courage and honor of Ms. Robins -- and worrying aloud how many of the students before him could have survived the brutish campaign Robins endured -- Nader left the podum with an interesting observation, almost a challenge, to both the students and career engineers. In the mid-1970s, he noted, rising concern over social issues among law students was directly reflected in the sort of questions the students asked of the corporations which sought to recruit them from the campuses. And those questions, he said, quickly and quite directly shaped the image of themselves the major law firms learned to project -- and were soon reflected in the work practice of the best law firms themselves, those most successful in recruiting top students. Specific questions about the amount of time a law firm committed to pro bono legal work, for example, *introduced* the practice of pro bono work in many large law firms. If engineering is truly a profession, with minimal standards of technical prowess and personal integrity to be upheld, said Nader, engineering students could similarly have a major impact on corporate behavior by asking about specific policies and practices which could protect a dissident or worried professional within a corporate setting, perhaps guarrantee him or her a hearing (before engineering peers, in matters of technical or professional integrity) when immediate corporate superiors were hostile or unsympathetic. A lawyer, albiet one skilled in corporate infighting, Nader couldn't go into details for his suggestion. RISKS, however, is an unusual forum that reaches deeply into academic, corporate, and government engineering. Could we hear some suggestions for those students? What questions could be asked? What corporate structures and/or procedures could guarrantee an honorable engineer who confronts an issue of ethics on the job a viable alternative to the self-sacrifice of public whistle-blowing? Vin McLellan The Privacy Guild (617) 426 2487 Boston, Ma. ------------------------------ Date: Mon, 18 Apr 88 21:30:21 est From: Rob Horn Subject: Safety nets under falling bridges Brian Urquhart wrote ``I believed then, as most conceited young people do, that a strong rational argument will carry the day if sufficiently well supported by substantiated facts. This, of course, is nonsense. Once a group of people have made up their minds on something, it develops a life and momentum of its own which is almost impervious to reason or argument.'' This belief was based on his experience as intelligence officer prior to the Arnhem attack and in the UN where he reached Under-Secretary General. It is relevant to risks because engineers seem to fall into the perenially young category in their faith that evidence can change decisions. Most of the discussion of whistle-blower protection etc. make as much sense as putting a safety net under a poorly engineered bridge. It may help reduce injuries but it ignores the more fundamental problem. The problem is that momentum is built up in the system beyond the point where a decision can be reversed. This is inherent in Feynman's and others' complaints about the Challenger disaster. The problem is not the O-rings, it was that the momentum to launch was allowed to get so strong. This was clear for months prior to launch. Aviation Week was full of stories about rushed schedules, botched work, confusion, fatal and near fatal accidents. Yet no one could stop the launch. When a system has reached this point disaster is inevitable. All you can do is try to soften the blow. Yet the focus of debate here and elsewhere is on issues that arise too late. When the system has reached the point that a whistle-blower needs protection you are already past the point of no return. Much more important, but much harder, is understanding the human decision and organizational structures that lead to this momentum. How do you destroy this overwhelming force to completion without destroying the will to succeed? Rob Horn, Infinet, 40 High St., North Andover, MA ...harvard!adelie!infinet!rhorn ...ulowell!infinet!rhorn ..decvax!infinet!rhorn ------------------------------ Date: 19 Apr 88 16:00 From: minow%thundr.DEC@decwrl.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) Subject: Datamation, 15 April 1988 The cover article is on "Risk." "When you become dependent on any resource, you become more vulnerable." Martin. ------------------------------ Date: Tue, 19 Apr 88 00:33:02 PDT From: blarson%skat.usc.edu@oberon.USC.EDU (Bob Larson) Subject: Poorly designed error messages Organization: USC AIS, Los Angeles The message in a recent RISKS about starting from false assumptions when someone gives you their conclusions rather than the symptoms (which I assume many of us have discovered the hard way) got me thinking about how the bad conclusions are reached. Primos has a "standard" error message "Access Violation". On a number of occasions, people come to me (as the local primos "guru") asking me to help me find the file they can't access when they get this message. The error message is used exclusivly for MEMORY access violations. (This is one of several messages that usually indicate a bad pointer.) File messages include "insufficent access rights" and "not found" to cover files that can't be opened due to insufficent access rights. While not a huge error, this poorly designed error message has probably caused many man-months of time wasted looking for the wrong problem. Bob Larson blarson@skat.usc.edu {sdcrdcf,cit-vax}!oberon!skat!blarson ------------------------------ Date: 19 Apr 88 07:50:52 EDT (Tuesday) From: MJackson.Wbst@Xerox.COM Subject: RISKy Airline Meals The following is from the letters column of the "Travel" section of the April 17 /New York Times/. Mark To the editor: The perils of ordering special meals on airline flights cannot be overlooked. A while back we traveled from Fort Lauderdale to Detroit with Delta Airlines and ordered a cold seafood plate instead of the regular meal. Delta responded with a hot seafood plate. We wrote them a letter to complain and they apologized. However, since then we have been on three morning Delta flights where breakfast was served. Each time we were brought a cold seafood plate. We did not want it. We did not order it. Somehow, our name has gotten into the computer, and every time we fly we get the cold seafood plate. The last time it happened, the flight attendant referred to us as "Mr. and Mrs. Seafood" instead of Mr. and Mrs. Stanton. Roger Stanton, Grosse Pointe, Mich. /A spokeswoman for Delta Airlines replies:/ There are two codes that can be used to tell the computer that a request for a special meal has been made, one for a specific flight, the other for all flights a passenger might take. In Mr. Stanton's case, the agent apparently used the wrong code. That has now been corrected. We encourage passengers to request special meals at the time the flight reservation is made, but it can be done up to three hours before flight time for most meals, eight hours for kosher meals. Passengers should specify whether they want a standing order or a one-time-only order. [At 35,000 feet, on a clear day you can seafood forever, especially if you are standing -- or Stanton. PGN] ------------------------------ Date: 19 Apr 88 09:55 From: minow%thundr.DEC@decwrl.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) Subject: Response-time variability -- prior art The recent re-invention of response-time variability reduction techniques forced me to dig out an article I published in an obscure journal in 1977. In the Decus Proceedings vol. 4, no. 2, I wrote a long article on system performance and usability. To quote: One example of a simple method to improve the way a system seems to perform is illustrated by the program segment [as follows]: 100 PRINT "Prompt"; 200 INPUT request 300 start = [get time of day] 400 ... Calculate result ... 500 elapsed = [time of day] - start 600 IF (elapsed < 5) THEN sleep(5 - elapsed) 700 PRINT result ... This has several implications: -- Response times are less dependent on system load. -- The operator learns when to expect a response from the system and thus is able to build a rhythm by knowing when to look back at the terminal. -- The system response degrades more slowly. If the actual response time varies from one second to six seconds, the operator will see only a one-second variation, instead of an almost five- second variation. ... In general, your programs should be written so that the operator feels that "they're always there;" that they will always do something reasonable in a resonable time. Early computers often had loudspeakers attached to some part of the CPU. The operator heard what was happening: how far the production run ahd progressed, when it was about time to change tape reels. ... In all cases, try to keep the feeling that the system "listens" to the operator at all times, and -- especially -- "tells" the operator what is happening. I don't claim originality for these ideas: I was taught them by the customers I supported in Sweden in the early 1970's. I guess my mistake was not wrapping them inside some theoretical framwork ("System usability and implications for the eight queens problem") and publishing them in CACM. Of course, if I did so, the people who needed the information might not have seen it. Martin. ------------------------------ Date: 19-Apr-88 07:45:48-PDT From: Klaus Brunnstein Subject: Re: Security of OS: who is responsible? (RISKS-6.64) In his information how to cope with an error in DEC's Kid Install software for its recent security update for Vax Workstation Software, Darren compares the security of an operating system to a house. Inhabitants are, according to his example, themselves responsible to prohibit thieves from easy access by just using their keys and locks. Unfortunately, the example is misleading: while every `user' of a house knows about access and how to control it, complex operating systems have so many doors that nobody can understand the diverse control techniques. While house are designed, as socio-technical systems, according to a user-understandable model, an operating system is designed as a technical system without virtually any reference to users concepts. In this situation, the designers responsibility to guarantee a `safely usable operation system' (especially when a design or programming error is probable) cannot so simply be transferred to the users (also in the case of non-benevolent users). I therefore greet DEC's activities to provide better professional standards in dealing with security updates. Klaus Brunnstein, University of Hamburg, Fed.Rep.Germany ------------------------------ Date: 19 Apr 88 02:18:53 EDT (Tue) From: fc@ucqais.uc.edu (Fred Cohen) Subject: Israeli Viruses I should point out that I wrote the research papers that detailed the class of methods proposed for detecting viruses by the Isreali team - they were published in Computers and Security in 1987 - the checksums I have seen are fairly easy to forge, but even the very strong ones like the one I published can be broken given enough time. They are a "Complexity Based Integrity Maintenance Mechanism" (the name of one of those papers). Indeed, I suspect that I could still write a virus that they could not detect, as I have done considerable research into the topic and understand the underlying mechanisms. I should note that the source code for such a high quality checksum is to be published in the April issue of C+S, so you'd better take all the cash you can get right away, before the public finds out they can get the same or better protection for free. - FC ------------------------------ Date: Fri, 15 Apr 88 10:30:17 EDT From: webb@applicon.COM (Peter Webb) Subject: time-zone problem I have learned that Telnet announced, on April 7, that everyone who uses its Electronic Bulletin Board service should ignore any and all bills for daytime usage, from Sept 1987 to Feb 1988. Apparently, calls to Telnet are often automatically re-routed by the local phone company. In some cases the calls are forwarded to an exchange in a different time zone than that of the originating user. Under the correct circumstances, ie a user dialing in less than an hour after night/evening rates go into effect and having his or her call forwarded to a node in a time zone at least one hour earlier, this can lead the Telnet system to believe the call was placed during daytime hours, and to consequently bill the user at daytime rates. The problem is excaberated by Telnet's policy of billing an entire session at daytime rate if any part of it occurs during daytime hours Peter Webb. {allegra|decvax|harvard|yale|mirror}!ima!applicon!webb, {mit-eddie|raybed2|spar|ulowell|sun}!applicon!webb, webb@applicon.com [Again! This has happened to the competition as well. If it wasn't so late and I wasn't commuting to the Security and Privacy meeting, I'd dig up three or four previous cases in RISKS. PGN] ------------------------------ End of RISKS-FORUM Digest ************************