Subject: RISKS DIGEST 16.38 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 2 September 1994 Volume 16 : Issue 38 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Football interference without penalty? (PGN) RFI and "winchcraft" (Mich Kabay) Drawbridge controls -- fail-safe? (Steve Summit) Chile: "Multicarrier" telephone system collapses (Patricio Poblete) Anarchist files linked to child mutilation (Mich Kabay) Poulson Pal Pinched (Mich Kabay) Barclays Bank's new computer system (Steve_Kilbane) Risks of living abroad (DelleraK) Re: Changeable `constants' (George W Dinolt, Joseph H Presley, Mark Brader, Bob Frankston, Steve Kilbane, Lars-Henrik Eriksson, James Cottrell, James Carlson, Mark Nelson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 2 Sep 94 8:47:48 PDT From: "Peter G. Neumann" Subject: Football interference without penalty? National Football League coaches will have radio transmitters this year to send plays in to their quarterbacks. RISKS readers may suspect that unless the communications are encrypted, the opposing coaches will be able to listen in. However, a different security problem must also be solved. The last time this was tried in the World Football League, quarterbacks sporadically picked up signals from local radio stations and air traffic controllers. You can imagine a situation in which the flight instruction just happened to coincide with the name of a play. Well, apparently the NFL techies believe they have solved the interference problem this time around; perhaps they resorted to the Playfair Cipher. [Thanks to Tom FitzGerald in the San Francisco Chronicle, 2 Sep 1994, p. E6, for reminding me of this risk.] ------------------------------ Date: 02 Sep 94 07:40:26 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: RFI and "winchcraft" The _Globe and Mail_ newspaper in Canada for 94.09.02 (p. A8) reports on radio-frequency interference with building-construction cranes and other devices: Breaking the spell of `winchcraft' by Mary Gooderham, Applied Science Reporter ....Without warning--and with no obvious electrical or mechanical fault--the Kroll K-154 crane would shut itself off, sometimes while hoisting a bucket filled with a couple of thousand kilograms of concrete. Two transmissions blew, their gears suffering when the machine's emergency braking system stopped the bucket in mid-air. The crane sputtered, losing power last week to the point where it could lift loads only slowly, only a few metres off the top of the building. The article explains that these problems caused major delays in the construction site at Simcoe Place in Toronto. Investigation revealed that the equipment was being disrupted by radio-frequency interference (RFI), probably from nearby microwave relay dishes and broadcasting stations. Workers with experience at the Scotia Plaza site built during the late 1980s recalled similar problems there; intermittent problems began once cranes were raised above the 60th story and depended on the orientation of the cranes--apparently because the cranes acted like antennas. In that case, engineers figured out that the RFI was disturbing "the wiring on the cranes' direct-current motors." Significantly, the Simcoe Place crane also has a new DC motor, whereas the other, unaffected crane uses an AC motor. The engineers installed some metal-coated foam usually applied to ductwork. The problems stopped. A lead shield is now being installed for more secure isolation. According to the contractors erecting the outer walls of Simcoe Place, their laser level "started acting funny when it was used above the 20th floor." The receiver that picks up the laser signal beeped when the laser was off-target or wasn't even turned on. Wrapping all but its tiny electronic eye with the aluminum foild that usually keeps sandwiches fresh in the workers' lunch boxes seemed to solve the problem. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Fri, 2 Sep 1994 08:59:31 -0700 From: scs@eskimo.com (Steve Summit) Subject: Drawbridge controls -- fail-safe? The Evergreen Point Floating Bridge across Lake Washington in Seattle (SR 520) has been notorious for its control problems -- either it gets stuck open or stuck closed, or opens partially for no reason (which has led to one death and one serious injury, on two separate occasions). The draw span has been rebuilt this summer, although the following account (from the Seattle Times of September 1) of the new controls will perhaps not be as reassuring to RISKS readers: To ensure that the center lift span never again pops up accidentally, the old mechanical system has been replaced and is now controlled by a computer with a series of safety features that must be overseen by the bridge operator. "You have to push buttons to make the gates go down, the lights come on and the [actuating hydraulic] pumps to start," [project engineer Jay] LaVassar said. "Every step has to be completed before you can go to the next step." Steve Summit scs@eskimo.com ------------------------------ Date: Fri, 2 Sep 1994 18:15:07 GMT From: ppoblete@dcc.uchile.cl (Patricio Poblete) Subject: Chile: "Multicarrier" telephone system collapses MULTICARRIER TELEPHONE SYSTEM COLLAPSES AFTER 4 DAYS-- A telecommunications system that allows callers to choose their own long-distance telephone company, called the multicarrier, collapsed only 4 days after its inauguration. The system failed because callers were using codes obsolete with the start-up of the multicarrier, confusing the system. Talca and Curico, the first cities to have the multicarrier installed, were the first to experience problems. The entire country will be hooked up by late October. (La Epoca, p. B6) ------------------------------ Date: 02 Sep 94 07:40:34 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Anarchist files linked to child mutilation The Montreal _Gazette_ for 94.09.01 reports on page E1 about a pipe-bomb explosion related to computer bulletin board anarchist files: Boy loses 3 fingers in pipe-bomb explosion: Kirkland youngster, 13 and 15-year-old friend were following instructions on a computer. by Ann Carroll, _The Gazette_ A 13-year-old Kirkland boy lost three fingers on one hand and his 15-year-old friend was seriously injured last week when a pipe bomb they were making --following instructions on a home computer disk-- accidentally exploded. The article states that the boys had "decided to try an experiment they had picked up from a computer information network." The little idiots ignited the "high-powered flare" and it exploded in the hands of the 13-year-old. The other boy is undergoing continuing treatment to remove shrapnel from his hand. The mutilated victim's mother destroyed the diskette containing the instructions but does not know the information's source. {Comments by MK: Discussion at HoHoCon 94 in Austin, Texas: Q: "What about the Alansky case in Hartford where the cops are attacking a BBS for having bomb-making info?" A: [Deth Vegetable answers] I wrote those files when I was 15; and the files are in the news again in Montreal. Some kids used my files and blew up their fingers. I feel bad about that. However, anyone stupid enough to use the files to make bombs deserves what they get. It's like Darwin, you know? In Canada they don't have guaranteed free speech, so the cops are taking boards down for having this stuff on them. Alansky got 28 onths in jail. His lawyer said he didn't want to get involved with the First Amendment. So Alansky plea-bargained and then went to jail. There were other irregularities; e.g., they didn't inform the lawyer of the location for the indictment. Q: [MK, loudly] "Why publish such files at all?" [Furious faces circle on me from all quarters; people recite, "Information Wants to be Free" and snarl, "There was nothing illegal about it" and "He had a right to post it."] A: [Someone hands me a note written by Voyageur] "We provide the files in order to protest our rights to the freedom of information. If we voluntarily censor ourselves, we do as much as if the government were doing it itself. We maintain our rights through the exercise and use of our rights. In addition, many adults enjoy pyrotechnics as a recreational activity. Quality information provided at low or no cost greatly reduces the risk of pyrotechnic experimentation resulting in unfortunate accidents." .... Discussion about posting bomb files with Deth Vegetable and others: [Would you like to be called Mr Deth or Mr Vegetable?] Most people call me, "Veggie." [Why did you post the bomb-making files?] "The government has the power; so publishing the anarchy files is important. It's as if one day the revolution will come and these files will arm the masses to rise up against the establishment. Anyway, it was funny to me at the time [when he was 15, 4 years ago]". [What about now?] "I wouldn't do it now. I can't say exactly why. I'm a different person now.... Anyway, who's to say if it's right or wrong?" [MK, seizing D.V.'s shirtfront and slowly drawing him to an inter-nose distance of 1 inch: "Who's to say if it's right or wrong? _YOU_ are. _I_ am. [sweeping arm to indicate entire room] _We_ are. We live in a society of human beings who have responsibilities to each other. We don't live in an anarchic paradise where you can ignore the consequences of your actions by appealing to a vapid ideology of non-involvement."] \set disgust = on I wonder if the fools who posted the pipe-bomb information have any shred of self-respect. "If it's legal it must be OK" is a prescription for amoral anomie. The National Computer Ethics and Responsibility Campaign sponsored by the National Computer Security Association and the Computer Ethics Institute includes a discussion of this attitude; we call it the "video-game syndrome." The syndrome entails assuming that if something is feasible it must be acceptable; "after all, if the game designers meant to forbid pressing CTL-ALT-7 to shortcut to the winning frame, they should have programmed the game to prevent it." The next stage is, "If the system administrator wanted to keep us out of the medical records, she should have put up better security." And then "If it were wrong to [name of reprehensible act], it should be impossible to accomplish it. set disgust = off\ M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: 01 Sep 94 13:22:37 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Poulson Pal Pinched The Reuter newswire for 30 Aug 1994 issued a report on the capture of Justin Petersen, a criminal hacker involved in Kevin Poulson's radio-station contest fraud in Los Angeles: HACKER NABBED AFTER NEARLY A YEAR ON THE LAM LOS ANGELES, Aug 30, (Reuter) - After nearly a year of searching, the FBI nabbed a computer hacker who pleaded guilty to tapping radio station phone lines to win contest prizes, a federal prosecutor said Tuesday. Justin Petersen, 34, was arrested after an agent spotted him getting out of a car in West Los Angeles on Monday, Assistant U.S. Attorney David Schindler said. Petersen tried to flee, but was apprehended after a brief foot pursuit. The article explains that Petersen admitted June 1993 to having committed "computer fraud, conspiracy and illegally accessing computer files of a credit rating agency...." in connection with his nefarious deeds as a close collaborator of the notorious Kevin Poulson. At his October 31 sentencing, he could receive 40 years of jail and be fined up to $1.5 million. Although he cooperated with law enforcement officials in tracking down other criminal hackers, Petersen disappeared from view and an arrest warrant was issued for him. Petersen called himself "Agent Steal" and boasted about how much he was being paid by the FBI to inform on his pals at hacker conferences. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Wed, 31 Aug 1994 14:51:00 +0000 From: steve@cegelecproj.co.uk (Steve_Kilbane) Subject: Barclays Bank's new computer system Barclays Bank in the UK have a new computer system, and are currently inviting customers to check their records, in groups. This week, customers with surnames beginning with J-M are asked to check their records. So I did. I gave my surname and postcode to the assistant, who promptly brought up my records on a pretty Motif interface (used to be Windows, as I recall). Numerous records needed updating. Some were rather dubious. The first recorded how long I had held an account with them. This hadn't been altered since the last time I gave them this information, two years ago. It's bad enough telling them how long they'd had a record of me when they first got the earlier system going, but they don't seem to update this information at all, and it doesn't seem to be a time reference. sigh. The other dubious field was my salary, which occurred in two places (general form, and employment form), and needed updating in both places. Why is there this duplication? A couple of other things bothered me about all this. The first was that I wasn't asked for any more proof of identity other than my surname and postcode, and I got to play with all the fun figures that affect my life. I know this information about at least one friend who banks with Barclays, and their surname's further down the alphabet. :-> More seriously, this information is pretty easy to obtain. I raised it with the assistant, and she informed me that these two pieces of information were considered more secure than an account number. Sigh. I wasn't even asked to produce an physical ID. The other problem didn't occur to me until I started writing this. The assistant turned the screen towards me, and away from all the other people in the bank. Unfortunately, this also means that she turned it towards the large wall-like window, and all the people in the street. :-( Steve_Kilbane@cegelecproj.co.uk ------------------------------ Date: Fri, 02 Sep 1994 18:08:48 +0100 From: DelleraK Subject: Risks of living abroad I have discovered that living outside the US puts you in the database-never-never-land of People with Foreign Addresses. I now expect to have to follow up several times after giving my address to just about any US business: the first time to be told "we can't mail out of the country" (read: "we can't make the computer mail out of the country"); the second time to talk to a supervisor, who checks the procedure and tries to enter the address; the third time to call back and discover it was somehow mixed up (frequently as an American address with the German postal code as the ZIP); the fourth time to request a resend with the correct additional postage, which often must be hand-carried to the mail room... you get the picture. With luck, I eventually receive a tattered envelope bearing several layers of metered postage stickers, US postal reject stamps and some handwriting from the Bundespost employee who managed to successfully interpret the address once the letter finally crossed the ocean. Then there are the firms like the credit reporting agency that told me the only way to fix my garbled address was to contact each of the companies listed on my credit report...which of course couldn't be mailed out of the country. The risks? As usual, computerization can greatly streamline handling of the routine, but can also eliminate the flexibility to handle exceptions. And, in an increasingly international world, not everybody has a ZIP code. ------------------------------ Date: Thu, 1 Sep 1994 19:10:07 +0800 From: dinolt@wdl.loral.com (George W Dinolt) Subject: Re: Changeable `constants' (RISKS-16.37) Re James Ashton's comments in RISKS-16.37 on changing the value of constants in Fortran compilers, it was indeed possible to do so on some Fortran and other compilers. I demonstrated this to my students in the fall of 1972 using one of the Fortran (I think it was either G or H) compilers on MTS (the Michigan Terminal System, a time sharing system using IBM 360 tools). The compiler would not let you assign a new value to a constant directly. One had to pass the constant as an argument to a subroutine. Inside the subroutine, one referenced the argument as a variable and hence one could assign new values to it. Since subroutine arguments were passed by reference, the value was changed by the assignment and subsequent references to the constant at any later time and in any procedure reflected the new value. My guess is that this trick would have worked on any IBM 360 system using the same compiler. Other compilers would flag the assignment line in the called subroutine, complaining that one was changing the value of an argument of the subroutine. The issues arising from overwriting supposedly constant memory with new and ``useful'' information have been discussed many times in Risks. This example is more insidious than some because both the calling and called procedure appear to be ``correct'' as stand-alone modules. It is the glue (calling mechanism) which causes the problem. My application of this particular compiler ``feature'' is just another example of what happens when the ``equivalence'' between algorithms and implementations fails in obscure and hidden ways. George Dinolt, Loral WDL [The rest of this issue continues this thread. My inconstant moderation allowed me to let the following items through the filter. PGN] ------------------------------ Date: Thu, 1 Sep 94 15:24:08 EDT From: presley@astra.mh.att.com (Joseph H Presley) Subject: Re: Changeable `constants' (Ashton, Risks-16.37) On the IBM 1130 system (circa 1970 for me), constants were kept in memory. The following would output 1 + 1 = 4 as the answer: CALL X(1) I = 1 + 1 WRITE (6, 10) I 10 FORMAT (1H1, 7H1 + 1 =, I2) STOP END SUBROUTINE X(I) I = 2 RETURN END Additionally, floating point operations were done via subroutines. One night during "student time", I exchanged the + and - subroutines (actually entry points in one routine) on the system disk for about an hour. Joe Presley j.h.presley@att.com ------------------------------ Date: Thu, 1 Sep 1994 16:30:49 -0400 From: msb@sq.com Subject: Re: Changeable `constants' (Ashton, Risks-16.37) Some years ago when I was at university I heard about a student who had tried a similar statement in whatever language they were working in at the time (I think it was a COBOL dialect) and it had worked. The student showed the program to a more knowledgeable person with great concern -- in case the program had "broken the 3 in the computer." Mark Brader, msb@sq.com SoftQuad Inc., Toronto ------------------------------ Date: Thu, 1 Sep 1994 21:24 -0400 From: Bob_Frankston@frankston.com Subject: Re: Changeable `constants' Fortran wasn't so bad as to allow "4=3". The problem is that parameters were always passed by reference, including constants. so that if you had a subroutine that incremented its parameter, calling it would increment the constant. This was worse than "4=3" since you couldn't tell by inspection that CALL SCORE1(3) would change the constant. There would normally be a single copy of the constant in memory since machines like the IBM 7094 didn't have inline constants. ------------------------------ Date: Thu, 1 Sep 1994 08:18:41 +0000 From: steve@cegelecproj.co.uk (Steve_Kilbane) Subject: Re: Changeable `constants' Believe it or not, there *is* a useful application for this sort of thing. The IEC1131-3 compiler generates object code where all data objects are stored in a lookup table, with constants and variables being virtually indistinguishable. One reason for this is that while commissioning control systems at site, field engineers often have to tune "constant" values to get maximum results from the system. The object file format allows the engineer to change what the programmer originally considered as a constant. Ok, so I'm talking about changing the constants after compilation is complete - the compiler won't allow the programmer to write to a constant - but it's near enough. steve ------------------------------ Date: Thu, 1 Sep 1994 From: lhe@sics.se Subject: Changeable `constants' (Ashton, RISKS-16.36) ... Statements like `3=4' could then cause the chaos that you might expect. This is syntactically incorrect and should not work. However, the following fragment could have the effect of changing 3 to 4. CALL ASSIGN(3,4) ..... SUBROUTINE ASSIGN(I,J) I=J END Lars-Henrik Eriksson, Swedish Institute of Computer Science Box 1263 S-164 28 KISTA, SWEDEN lhe@sics.se +46 8 752 15 09 ------------------------------ Date: 1 Sep 1994 09:03:51 -0500 From: "James Cottrell" Subject: Changeable `constants' While at RCA in the early 80's I was developing Fortran code for PDP/11-70's and showed a colleague an example of what you described. I believe the example you cite is incorrect since the compiler could determine that the left hand side of the equation contained a constant making the statement illegal. The procedure that would work, turning the constant '3' into any other value is as follows. Subroutine Foo call change (3) printf (I5)3 return Subroutine Change (I) Integer I c change the value of 3 for routine Foo I=4 Return In subroutine Foo after the call to change, the compile time constant '3' would be equal to the value assigned in subroutine change. This change occurs because PDP Fortran parameter passing was call by address. I believe, and with age my memory is getting dimmer on the technical details, the PDP Fortran compiler would gather all constant declarations in a subroutine and allocate memory for the constants and load the constants in the memory. I don't remember if this memory was in the code space of the routine or in the data space. If the memory was allocated in the code space, the modification of '3' would remain until the subroutine was overlayed. If the memory was allocated in the data space, the modification of '3' would remain until the program stopped. This problem would not modify the value of the constant '3' in other subroutines, since the compiler would generate a new (local) copy of all constants for each subroutine. !The opinions expressed here are mine and may conflict with my employer, !wife or any other person. ------------------------------ Date: Thu, 1 Sep 94 10:55:54 EDT From: James Carlson Subject: Changeable "constants" in Fortran Close -- the actual problem was a bit more obscure. I know; I've been bitten by it. Years ago (about 1983), I worked on Finite Element Analysis software at a small company in Pittsburgh. Of course, all of this stuff is done in Fortran since the original public-domain SAP-IV and PLOT-10 packages were in highly condensed and uncommented Fortran. We ran into a problem with the "constant" zero occasionally assuming other values in one particular module on a Prime 750 running PRIMOS. The problem was caused by a sequence of statements of the form: call somefunction(iargument,0) ... call anotherfunction(0) The first callee looked something like this: subroutine somefunction(iarg,icount) integer*4 iarg,icount ... icount = icount + 1 ... return end Of course, Fortran uses call-by-reference rather than call-by-value, so it has to push an address on a stack instead of a literal value. To do this with a constant, like 0, it has to dump the constant into a literal pool and pass the address of the literal pool entry to the subroutine. The compiler "optimized" the other zero-value references in the same module to refer to this "convenient" constant. Then, when the subroutine modified the value of zero in the literal pool, the optimized references were then subtly wrong. The following call passed a value of 1 instead of 0 to the next function, resulting in a skipped element in an array. Fortunately for my sanity, PRIMOS had a superb debugger, and I knew enough assembly to figure out what had happened. (Playing with memory- to-memory only architectures like the Westinghouse W2500 -- a machine with core memory and a RAM scratchpad -- in my misspent youth also helped. ;-}) James Carlson Annex Software Support / Xylogics, Inc. 53 Third Avenue / Burlington MA 01803-4491 +1 617 272 8140 ------------------------------ Date: Thu, 1 Sep 94 18:20:57 EDT From: Mark Nelson Subject: Re: Changeable `constants' I've never seen a Fortran compiler that allowed assignments of this form, as this should be easily detected by the parser. However, code similar to the following has worked on every Fortran I've ever tested it on (various DEC, CDC, Cray, and Sun compilers, at least); program modify c attempt to modify the value of a constant c output will probably be 987.654, not the expected 123.456 call modif(123.456) print *,123.456 stop end subroutine modif(x) real x x = 987.654 return end Tricks like this generally don't work with small (absolute value) integer constants, as most machines provide instructions to load such values into registers without accessing memory. But as Mr. Ashton noted, other constants are often stored as literals in memory, with the compiler efficiently reusing the same location for each use of a particular value. Mark Nelson, Department of Computer and Information Sciences, University of Delaware mnelson@cis.udel.edu ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.38 ************************