Subject: RISKS DIGEST 10.01 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 1 June 1990 Volume 10 : Issue 01 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: RISKS, Volume 10, and FTPing back issues (PGN) Word Perfect Software Upgrade Crashes Utah Phone System (Bill Kules) Army finds new battlefield system vulnerable to software sabotage (Jon Jacky) Caller*ID illegal in Penn (tim, Keith Bradsher via Jerry Leichter) Denial of service due to switch misconfiguration (Marc Horowitz) Equipment failure or human failure? (Henry Spencer) More on the Steve Jackson Games raid (Walter Milliken, Stephen J. Webb) Mailing list risks (John Chew) ATM range checking (Andy) 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 (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]GET RISKS-i.j ; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*" gets you directory listing of back issues. ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. ---------------------------------------------------------------------- Date: Thu, 31 May 1990 13:18:38 PDT From: Peter G. Neumann Subject: RISKS, Volume 10, and FTPing back issues Welcome to VOLUME 10. RISKS will be beginning its SIXTH year on 1 August 90, although it will soon go into a first-month-of-the-summer sporadic mode until then. For FTPers who previously complained about the unfriendly sort order produced by the directory commands, you probably noticed that we recently switched the archive issue-number file name extensions to double digits (e.g., RISKS-9.01, 02, 03, etc.) and the volume summaries to RISKS-i.00, for i=1 to 9. Beginning with this issue we now have double-digit volume numbers for volume 10 and beyond, but the original single-digit volume numbers remain for the first 9 volumes. Beginning with this issue, ALL issue numbers will appear as two-digit numbers, even in the headers. (No volume has exceeded or will exceed 99 issues, a decision that ensures that the volume summary issues will be not much larger than RISKS-9.98 = RISKS-9.00, which was the largest yet.) Astoundingly, there is always someone going back to get the early issues, which affords an interesting chronological perspective of where we've been and how we got to where we are now. The historical archive also gives lots of clues as to what we need to do better in the future... Thanks for your patience through the multiple-copy ordeal. The various manifestations of it all seem to have been rectified on my end, although I still hear reports of problems elsewhere. PGN ------------------------------ Date: Thu, 31 May 90 10:16:32 +0100 From: m1wmk00@fed.UUCP Subject: Word Perfect Software Upgrade Crashes Utah Phone System >From an Infoworld article on Word Perfect ("Leader of the Pack," pp. 45-6, May 23, 1990): "When [Word Perfect] 5.0 shipped in May 1988, the company underestimated the demand for telephone support. Although it bought additional phone lines, traffic was so heavy that calls to the support department brought down the toll-free systems for the state of Utah, including phone systems for American Express, Delta Airlines, and the Latter Day Saints Church." Bill Kules, Automation and Research Computing, Federal Reserve Board, Washington, DC wmk@fed.FRB.GOV Phone: (202) 452-3933 ------------------------------ Date: Thu, 31 May 1990 21:54:24 PDT From: JON@GAFFER.RAD.WASHINGTON.EDU (Jon Jacky) Subject: Army finds new battlefield system vulnerable to software sabotage [More details on this item, first noted in RISKS-9.90.] Here are excerpts from a page 1 story in MILITARY AND AEROSPACE ELECTRONICS, vol 1 no 5, May 1990: VIRUSES COULD CRASH U.S. BATTLE SYSTEM by Lisa Burgess and Tobias Naegele WASHINGTON - Computer viruses could crash critical battlefield command and control computers, according to a draft version of the Army's new Command and Control Master Plan. The report says the Army's Maneuver Control System, touted by developer TRW Inc. as the "integrating node" of the Army's command and control battle plan, is vulnerable to sabotaged software designed to undermine and disrupt operations. ... The four-page subsection, titled "Subversive Software" and buried 10 items deep in a section on camouflage, warns that "contractor-developed non-developmental item (NDI) and `homegrown' software each present unique [software surity] problems that must be addressed." Generated by the Army's Combined Arms Combat Developments Activity at Fort Leavenworth, Kan., the report raises three questions about the potential for software sabotage to damage the $1.3 billion MCS battle management network: - Could virus software implanted in the system during the design phase attack MCS at a later date? - Could an agent introduce a virus during combat by surreptitious access to a workstation? - Could an enemy use a captured workstation to introduce a virus over the radio network? "Under its present configuration," the report states, "the answer is yes with regards to MCS." ... Defense contractors say any system using the sort of off-the-shelf hardware and software utilized in MCS and ATCCS --- the Army Tactical Command and Control System --- is potentially vulnerable to virus attacks. ... - Jon Jacky, University of Washington, jon@gaffer.rad.washington.edu ------------------------------ Date: Thu, 31 May 90 10:44:27 PDT From: tim@ggumby.cs.caltech.edu Subject: Caller*ID illegal in Penn >From the Los Angeles Times, May 31, 1990, p. D2: Court Rules Against Caller I.D.: Bell of Pennsylvania's caller-identification service is an invasion of privacy and violates the state's wiretap law, a state court ruled. The decision reverses an order by the state Public Utility Commission allowing Bell to offer the service. The service would let people know who is calling before they pick up the phone, even if the caller's number is unlisted. Several other regional phone companies already offer the service. [Also noted by schwartz@groucho.cs.psu.edu (Scott E. Schwartz).] ------------------------------ Date: Thu, 31 May 90 11:29:18 EDT From: Subject: Court Declares Caller*ID Illegal [From the New York Times, Thursday 31-May-90, Page D1] Services Identifying Caller Held Illegal In Pennsylvania, By Keith Bradsher A Pennsylvania court ruled yesterday that services that identify the telephone numbers of callers represent an illegal invasion of privacy. The verdict was the first in the nation on the legality of such services. The five judges of the Commonwealth Court, a mid-level state appellate court, ruled unanimously that caller identification services ... violate Pennsylvania's wiretap law. All five judges found that the services violate the law even when telephone companies allow some customers to block the release of their telephone numbers. And the court ruled by a 3-2 vote that the services violate privacy protections offered by the Pennsylvania Constitution. "In the framework of a democratic society, the privacy rights concept is much too fundamental to be compromised or abridged by permitting Caller*ID," Judge Doris A. Smith wrote in the majority opinion.... But Bell of Pennsylvania criticized the ruling. "Because of this decision, Pennsylvanians are being deined a service they eagerly want and badly need - a weapon against harassing, threatening or obscene calls," [a spokesman said]. Three Options for Panel The Commonwealth Court hears appeals of decisions by state and local administrative bodies in Pennsylvania, and its decisions may be appealed to the Pennsylvania Supreme Court. John F. Povilaitis, the chief counsel of the Pennsylvania Public Utility Commission, said his office would review yesterday's decision and make a recommendation to the commissioners within a few days. [He] said the commission had three options: to ask [for a rehearing], to file an appeal before the Pennsylvania Supreme Court, or to allow the decision to stand. Bell of Pennsylvania was not named as a defendent in the case. But [it] said it qualified as a party [and could appeal if the PUC chose not to]. Bell ... filed with the commission on June 18, 1989 for permission to offer caller identification. The commission approved the filing on Nov. 9 and the company scheduled service to begin Jan. 9. But a Commonwealth Court judge blocked the service pending judicial review. The suit was filed against the P.U.C. by the state's Office of the Consumer Advocate, the [ACLU], the Pennsylvania Coalition Against Domestic Violence and the Consumer Education and Protective Association. [Caller id is now] widely available in [five states] and on a limited basis in [three others] ... according to ... a spokesman for Bell Atlantic Corporation, the parent of Bell of Pennsylvania. Phone companies in nine other states and Washington are seeking to introduce caller identification. Long-distance companies, including [AT&T], also offer caller identification to some businesses with 800 and 900 numbers. Yesterday's decision ... did not address whether long-distance companies should stop providing information for Pennsylvania callers. "We have to see how, if at all, this ruling affects AT&T," said ... a spokesman for the company. Privacy Issue Cited Bell Atlantic and other defenders of caller identification have argued that the services discourage obscene callers and protect the privacy of people receiving calls by allowing them the choice of not answering. But the court ruled explicitly that the privacy of people making calls is more important. The court found that caller identification services function as call-tracing devices, which under the Pennsylvania wiretap statute may be used only under certain circumstances. The court noted that Pennsylvania requires the consent of all parties before a telephone conversation may be recorded. As of December, there were 15 other states with similar requirements. The remaining states and Federal law allow taping with the consent of one party. But [FCC] rules require that all parties to an interstate or international call be aware they are being taped. The Pennsylvania wiretap statute contains wording similar to the Federal wiretap statute. Bills are pending in the House and Senate that would amend the Electronic Communications Privacy Act of 1986 to make caller identification explicitly legal while requiring that telephone companies give customers the option of blocking release of their telephone numbers. A subcommittee of the Senate Judiciary Committee has scheduled a hearing for June 7 on caller identification. [Because of the remarkably complex tradeoffs between defensive functionality and offensive violations of rights, this item seems worth including in its entirety for its intense educational value. PGN] ------------------------------ Date: Thu, 31 May 90 03:15:15 EDT From: marc@ATHENA.MIT.EDU Subject: Denial of service due to switch misconfiguration The Massachusetts Institute of Technology runs its own 5ESS switch to provide telephone service on campus. This has significant benefits, including many different telephone classifications (office, dormitory, etc), a modem pool, and ISDN phones in the offices which pay for them (most do). This week, I discovered what I consider a serious problem, however. A friend was at the Massachusetts General Hospital (MGH) for surgery. (I'll save you the suspense: the surgery went well.) I wanted to call and check on him to see how the surgery went. I called the hospital's main number, and was transferred to his room, except the phone was busy, so the operator gave me his phone number. The next day, I attempted to call his room, only to be greeted with "I'm sorry, but your call cannot be completed as dialed...." I thought about the situation, and after placing a call to the MGH operator, discovered that my friend was in a brand new building with a brand new exchange all its own. I called the MIT operator, who told me that the number I was trying to reach was in Petersburg, over a half hour away (I can see MGH from my room). I finally convinced her that this was a number at MGH, but she told me that she couldn't connect me. My phone is only able to make local calls, so I called a friend who works in the same office as the people who run the switch. They couldn't make the call. In other words, neither the operator nor the top class of phone could make the call. Today, I called MIT's help line, and described my problem. Within several hours, my theory was confirmed. The switch simply didn't know the new exchange existed. It turns out, that as a "client," MIT doesn't get automatic updates when new exchanges are created. Without this information, the switch has no clue how to bill the caller, or even if it should let the caller make the call. So it assumes the worst case, and disallows anyone from making the call. The switch had to be manually programmed with the necessary information about the new exchange. This worries me, as someone who isn't as familiar with telephone switching equipment might not have known what caused it, assumed it was his/her fault, and been denied service because of it. It is surprising, to me that our switch is not configured to take updates of this kind of information automatically from the New England Telephone switches it talks to. I was trying to call a hospital; fortunately it was not an emergency. My workstation has dynamic nameservice; my doesn't my telephone switch? Marc Horowitz ------------------------------ Date: Wed, 30 May 90 23:19:46 EDT From: henry@zoo.toronto.edu Subject: Equipment failure or human failure? Some little while ago, Risks published the report of a flight crew landing an airliner in Britain after a very difficult time with wind readings of 100+ knots and repeated equipment failures (in a "glass" [computerized] cockpit). There is an interesting sidelight on this in the May 2 issue of Flight International: CAA appeals for CHIRP pilot to step forward The UK Civil Aviation Authority is publicly appealing to an unknown pilot to file a Mandatory Occurrence Report about a serious digital cockpit systems failure which it is unable to investigate, because the airline pilot involved reported it through a confidential reporting system. Investigators and airline maintenance staff have no access to details of the apparently first-time incident. The MOR would allow the aircraft to be identified and its cockpit systems failures identified... [Recap of incident, as reported by pilot.] The confidential human factors incident reporting program (CHIRP) was designed to encourage pilots who have experienced a potentially dangerous incident because of human error to report it without fear of any disciplinary repercussions. It is unclear why this pilot used CHIRP, because there is no indication of human error -- only bad weather and systems failure... [More recap.] One really has to wonder just what really went on on that flight. Use of CHIRP might seem appropriate to a pilot fearful of management reaction to criticism of electronic aircraft, but as a result the people who want to investigate the problem are hamstrung, doubts are cast on the accuracy of the report, and if it *is* factual, that aircraft is still in service and potentially a lethal hazard to crews and passengers. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry ------------------------------ Date: Thu, 31 May 90 17:03:04 EDT From: man@cs.brown.edu Subject: More on the Steve Jackson Games raid I have a friend who's involved with Steve Jackson games and here is his response to the articles that have appeared recently in RISKS. -Mark [I had to edit a bit to make it self contained, rather than including all of the previous items. PGN] Date: Thu, 31 May 90 14:03 EDT From milliken@BBN.COM Thu May 31 14:04:19 1990 Subject: Re: Debate on SJG raid in comp.risks Re: Sherwood, RISKS-9.96: To the best of my understanding, this account is correct except for trivial details (not a footlocker, but some filing cabinets were broken open in the account SJ himself wrote). Re: Von Rospach, RISKS-9.97 > the person working on for Jackson Games was a former Legion of Doom member... This first part of this also appears to be true -- Loyd was apparently associated with some bunch of crackers sometime in the past, and apparently discussed some of the stuff he was doing with Cyberpunk with them, in the way of reality-checking. However, Cyberpunk was certainly *not* a "manual on hacking" -- I haven't read my copy yet, but I'm quite certain the game rules don't go into details of breaking computer security -- it just has abstract security programs and "cracking" programs as things that exist in the game world. These things also exist in cyberpunk novels, which is why they're in the book. >If you're running a BBS that's supporting a group of system crackers, you are, >at least, contributory to felony crimes... The problem was that SJG *was* clean, as far as I know -- the Secret Service just went overboard in their search for "contamination". I believe guilt-by-association is not a tenable legal theory in the US. Grounds for some amount of suspicion, yes. But search and seizure? >>Or does it indicate that games which involve "hacking" are subject to ... >Not if the Legion of Doom angle is true.... The Legion of Doom connection appears to have been there, but very tenuous. The Feds seem to have been unable to draw the line between fantasy and reality, and appear to have been operating under a "guilty until proven innocent" premise as far as the seizure of equipment went. As far as I know, the Secret Service had no direct evidence that SJG or the BBS had *anything* to do with their case -- mere proximity to the principals seems to have triggered the raid. I would expect that they would have done more research before swooping down and carting off someone's business equipment. I can understand how the raid happened, and even sympathize somewhat with the motivations of the Secret Service, but I think that they definitely stepped over the line here. One of the principles of the law in this country is that the innocent shouldn't be harmed in the pursuit of the guilty. ---Walter ------------------------------ Date: Fri, 1 Jun 90 09:15 EST From: WEBB3840@SNYPLAVA.BITNET Subject: RE:Steve Jackson Games The chance of GURPS Cyperpunk being used as a manual for computer crime is very slight indeed. In Cyperpunk fiction, a hacker's interface with the computer network he or she is trying to operate in is an actual physical connection with the computer. This connection is usually in the form of a direct link to a person's brain through jacks surgically implanted in their skull. It is my understanding that Steve Jackson Games used the same method of interfacing with computers in GURPS Cyperpunk. This would make it a little difficult for a person to use the game rules a handbook for crime. Unless they had a friend real handy with tools...:-). Stephen J. Webb ------------------------------ Date: Thu, 31 May 90 12:43:56 EDT From: john@trigraph.uucp (John Chew) Subject: Mailing list risks I received two copies of a well-known Macintosh software company's "Technical Solutions" newsletter today, identically addressed. It happens fairly often and I wouldn't have given it a second thought, except for the lead article: "Eliminate Duplicate Records: Omitting and Deleting Duplicate Records in ". It starts off "Eliminating duplicate records is part of the ongoing maintenance of any mailing list...." John Chew ------------------------------ Date: Fri, 01 Jun 90 07:07 PDT From: ZENITH Subject: ATM range checking In RISKS 9.96, Richard Muirden writes of his experience with $89m showing up in his bank account; his bank blamed him for keying in the amount at the ATM. He went on to wonder about the range checking that might or might not be employed at the ATM to catch "such obvious erroneous data". It is my experience that there is, indeed, NO such checking performed--at least at one institution, at one time. A few years back, my credit union installed an ATM machine; as part of the hoopla surrounding the event, they had a demonstration where members could "practice" on the machine, using a card provided by the demonstator. I, being the obnoxious sort, made use of the opportunity to determine an empirical answer to the question of range checks. I cheerfully deposited the amount of $99,999,999 in the account. The demonstrator was rather worried when I showed him the receipt (oops--I meant "transaction record"); it seems that they were using a live account for the demo, which meant that all these phoney transactions would show up on the balance sheets at the end of the day! I did hear later that the trouble caused was minimal, but they did have to jump through some hoops to make sure there were no ripple effects caused by that $99m. P.S.--My personal feeling is that any non-zero deposit is an "obviously erroneous value"; I don't like giving my money to a machine in exchange for a worthless transaction record. Andy ------------------------------ End of RISKS-FORUM Digest 10.01 ************************