Subject: RISKS DIGEST 13.57 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 10 June 1992 Volume 13 : Issue 57 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Perot computers cracked (Larry Hunter) $150 printer hangs $0.5M VAXcluster (Marc Shannon) Reviewing Communications in the Gulf War (James Paul) Endeavor bug -- more details (Nancy Leveson) Where on earth are you? (Richard Murnane) Risk of Computer Generated Fund-Raising Letters (Lee Hasiuk) Car computer downloading (Bob Sidebotham) Telecom Australia allows easy denial of service attack [anonymous] Follow-up to Dead Driver story -- PennDOT replies (Mike Berman) Re: BBS Fraud (Fred Gilham) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ************************************************************** *** If you cannot read RISKS on-line, try FAX! For info, *** *** please telephone 310-455-9300 (or send FAX to RISKS at *** *** 310-455-2364). EMail to risks-fax@cv.vortex.com . *** ************************************************************** ---------------------------------------------------------------------- Date: 10 Jun 92 11:32:10 From: hunter@work.nlm.nih.gov (Larry Hunter) Subject: Perot computers cracked Richmond, June 9 (AP) -- An intruder erased information on about 17,000 supporters of Ross Perot from a computer file at the undeclared Presidential Candidate's Virgina headquarters, campaign officials said. They added, however, that they have copies of the files destroyed in the weekend incident. The data included the names, addresses, telephone numbers and notes on about 17,000 Perot supporters in Virginia. "It's not a political act as far as I'm concerned," said Mark Adams, the state petition coordinator for Virginians for Perot. "I don't feel threatened by anything of that nature." [From the NY Times, 10Jun 1992, p. A20] I understand that the spokesperson for the campaign would want to downplay the importance of the incident, and say that he didn't feel threatened, but it is hard to avoid the conclusion that this is a politically motivated dirty trick. The Virginia election petition filing deadline is less than 3 weeks away. With a hotly contested and unusually complicated Presidential election upon us, I would hope that electoral computer risks will be receiving heightened attention from the community of computer professionals. Lawrence Hunter, PhD., National Library of Medicine, Bldg. 38A, MS-54, Bethesda. MD 20894 (301) 496-9300 hunter@nlm.nih.gov (internet) ------------------------------ Date: Tue, 9 Jun 92 14:36:21 From: Marc Shannon Subject: $150 printer hangs $0.5M VAXcluster Most people tend to enjoy their days off, Memorial Day included. Unfortunately, I received a call from our Operations staff at 4:30 in the morning on Memorial Day. It seems that during their normal nightly backups, one of the systems seemed to have a problem. During processing of one of the disks, nothing happened -- the tape drive wasn't spinning and any attempt to exit out of the command (using ^Y) was ignored except for a useless "*INTERRUPT*" message on the console. In frustration, they accidentally hit ^P which halted the system and then attempted to reboot. The system just would not come back up. Something I should note about this system is that it (probably incorrectly) has the key "votes" for the VAXcluster to continue operating normally. Since it was down, all the other systems were waiting for it to come back up ("quorum lost, blocking activity"). After spending an hour fruitlessly searching for the problem, it turned out that the disk that the system had tried to backup had gone south. This disk was (incorrectly) single-ported to a single HSC (Hierarchical Storage Controller). The HSC's action to disk problems it to spit out the errors onto its console. The console had a locally attached printer which had run out of paper. So, since there was no paper in the printer, the console hung waiting for it. Since the console was hung, the HSC waited for it. Since the HSC was hung, the VAX couldn't come up. Since the VAX couldn't come up, the VAXcluster wedged. This is how a $150 printer could hang a half-a-million dollar VAXcluster. Sigh.. --Marc ------------------------------ Date: Tue, 09 Jun 92 14:01:44 EDT From: James Paul Subject: Reviewing Communications in the Gulf War The following are excerpts from the article "The Data Weapon" [Peter Grier, in _Government Executive_, June 1992, p. 21], discussing U.S. communications support during the Iraqi conflict: "...Throughout the Gulf theater of operations, satellite communications uplinks seemed as common as the crushed water bottles that littered allies' camps.... The ubiquitous dishes were visible evidence of the vast command, communications, control and intelligence (C3I) network the United States laid.... Getting it all working wasn't always easy. The communications network often needed workarounds and quick fixes to patch together equipment of different technical generations, with different software interfaces and protocols. One big glitch occurred early on. In September 1990, it became apparent that the new Defense Switched Network was experiencing a horrible call-completion rate back to the United States, with only 20 to 30 percent of attempts going through. It took a troubleshooting effort of almost three months, involving AT&T and GTE technicians as well as military communicators, before the trouble was found: a signaling incompatibility between tactical and fixed systems. Over a three-day weekend, Bell Labs finally produced a new software patch to connect the systems, raising the call-completion rate to about 90 percent. Another problem arose because the Army's new Mobile Subscriber Equipment communications switches had not yet been tested for operability with the older switches of the other services. The Joint Tactical Command, Control and Communications Agency back in the States had to whip up software fixes enabling the Army's switches to work the Marine/Air Force Unit Level Circuit Switch, as well as the French RITA communication system. This took 17 days, according to a DISA [Defense Information Systems Agency] report. Meanwhile, the demand for connectivity was so great that DoD communicators were involved in an almost continuous search for all possible means of carrying messages [earlier in the report Grier mentioned that the daily message load was 700,000 telephone calls and 152,000 messages]. Among other things, the amount of electronic data being sent back and forth for tactical reasons was larger than anyone had ever envisioned.... Every time a new [satellite] came on line, it was used up." _Government Executive_ is published by the same folks who put out the political magazine _National Journal_, and it's aimed at the inside-the-Beltway managerial crowd. One wonders what might have occurred had the Iraqis pursued a more rigorous electronic warfare strategy. "Interoperability" is still the big problem -- the Navy's inability to read the Air Force's computer-generated Air Tasking Order [the daily air war plan] is becoming almost as famous as the 82nd Airborne trooper who used his AT&T Calling Card to call Fort Bragg from Grenada, asking them to call the Navy because he couldn't get through on the radio to ask the ships offshore for fire support (I'm going to be _really_ disappointed if that story turns out to be apocryphal). It also seems Patriot batteries could receive data from the Airborne Warning and Control System (AWACS) only with difficulty due to incompatible data links. Typing errors are the fault of the contributor, not the magazine. ------------------------------ Date: Tue, 09 Jun 92 22:53:24 -0700 From: Nancy Leveson Subject: Endeavor bug -- more details >From Aviation Week as quoted by James Paul: Engineers have traced the problem to the sensitivity of NASA-developed equations to a particular set of numeric values that arose when Endeavour was making one of the final computer-targeted rendezvous maneuvers. Test show the software had been properly coded by IBM and therefore passed all preflight tests, according to Ted Keller, senior technical staff member at the IBM Shuttle Project Coordination Office, Houston. Here is some additional information about this event. You can evaluate it yourselves with respect to the statements in AW. The STS-49 failure of the flight software to converge during targeting has been traced to the Lambert targeting routine. The associated algorithms used by the routine converge on an independent variable called "U" which is a double precision scalar. U is iterated (up to 10 times) via this algorithm. The algorithm is designed to converge on a value of U between two dynamically updated limits called U_MIN and U_MAX, which are single precision scalars. On each iteration, either U_MIN or U_MAX is updated to decrease the interval within which the algorithm will search for the desired value of U. To determine which limit to update, the algorithm calculates a variable U_STEP, the amount by which U will be updated on this iteration. If its value is positive, U_MIN is set to U. If its value is negative, U_MAX is set to U. Then U_STEP is added to U, and the resulting value of U is compared to the limits U_MIN and U_MAX. If U is now outside the limits, U is recalculated as the average of U_MIN and U_MAX, thereby keeping U within the search interval. U |--------|-----------------------| U_MIN U_MAX U continues to be updated in this manner on each iteration until convergence is attained or maximum iterations are executed. Convergence occurs if the normalized transfer time that corresponds to the current value of U is close enough to the desired transfer time. "Close enough" is a function of a mission-specific data value. For the third rendezvous of STS-49, the value of U after the first iteration was very close to the desired value, and U_MIN was set equal to U because U_STEP was positive. On the second iteration cycle, U_STEP was smaller thana one least significant bit (LSB) for U_MIN. Since U_STEP was positive, U_MIN was set to U, and U_STEP was added to U. Algebraically, U should have been greater than U_MIN. However, due to precision differences, U_MIN was greater than U. (Loss of precision occurred when the double precision value of U was stored into the single precision variable U_MIN.) Therefore, U was recalculated to be the average of U_MIN and U_MAX, and the search interval no longer contained the desired value of U. |<---1 single precision LSB-->| | | | | | U U | | after after | | 1st 2nd | | pass pass* | |------|---------|------------| | | | |<------->| | U_STEP | U_MIN *Prior to recalculations after 2nd pass Note: both U and U-MIN had negative values On subsequent iterations, U was updated in the direction of the desired value, but never reached it before maximum iterations occurred because it was outside the search interval. To fix the problem and allow the mission to resume, they had to uplink a new state vector from the ground, by-passing the onboard routine. The permanent fix involves changing U_MIN and U_MAX to double precision. ------------------------------ Date: Tue, 9 Jun 92 15:07:38 AEST From: Richard Murnane Subject: Where on earth are you? On Monday 8th June, I was tuning my amateur radio set across the 20-metre band, when I came across an emergency traffic net on 14.245 MHz. Several radio amateurs, in Hawaii, California, Florida, and Mexico City, were assisting an American marine vessel in the Carribean, the "Sea Harvest", whose navigation systems had been disabled, apparently by a lightning strike. Miami Coast Guard was alerted and the Coast Guard cutter "Courageous" was dispatched from Jamaica to locate and assist the vessel. One problem that arose was getting accurate coordinates for the vessel: all they had to go on was the last known LORAN readout from the previous day, and the direction and speed she had been sailing. Later, Sea Harvest contacted another ship on the marine distress frequency, VHF channel 16. Because Sea Harvest had a hand-held VHF tranceiver, the other ship would have been fairly close, and that ship's position reading would have been a reasonable approximation. However, when it came to relaying that information to the Coast Guard, things became confused: the position was read out as "22 degrees, 34 minutes north, *08 42 92* West" (I don't recall all the digits correctly, but the longitude was read out as three pairs of digits). The "08 42 92" was interpreted by all on frequency as being degrees/minutes/seconds, as most of us have been brought up to read geographical positions. The "08" was immediately rejected as a mistake, possibly in translation from Spanish to English, as 8 degrees west is in the Western Sahara desert, and it was judges that it was in fact *80* degrees West, which is in the Carribean. The ship which provided the coordinates however insisted that "08" was correct. Several hours later, when authorisation was given to activate Sea Harvests's EPIRB (Emergency Positioning Information Radio Beacon), the longitude figure again came up as "084.."; it was only then that everyone realised that the first THREE digits represented degrees, and the remaining three the minutes in decimal format, eg 84 degrees 34.6 minutes. The misinterpretation of the data format, when relayed over a voice radio link, led to a lot of confusion: one of the degree/minute/seconds coordinate groups placing the Sea Harvest five miles inland! This confusion lasted several hours until the EPIRB was activated. I'm very suprised that the Coast Guard could have been caught out by this: It suggests that the "decimal minutes" representation is non-intuitive, or at least counter to the way most "non-mariner" people (e.g. the radio amateurs providing voice relays) have been educated to read geographical coordinates. (Or, perhaps, there are two different readout systems currently in use?) Of course, when passing messages through one or more relay operators, one must be very careful not to try to "interpret" the message being passed, rather to send it *exactly* as received. It also illustrates that even the most sophisticated, systems can fail, and that it's always best to have a safety backup. Presumably, Sea Harvest's HF radio antenna was on a different mast, and thus not destroyed by the lightning strike! 73 de Richard VK2SKY ------------------------------ Date: Tue, 9 Jun 92 17:49 GMT From: Lee Hasiuk <0003582947@mcimail.com> Subject: Risk of Computer Generated Fund-Raising Letters >From a recently received Caltech Office of Annual Giving letter: ... Last year you gave $0.00 to the Annual Fund. I would like to see you increase your contribution this year by 25% or more if possible. ... I can imagine the letter I'll get after I send them $100: ... Thank you for being so generous by increasing your contribution from last year by Divide by 0 Core dumped Lee Hasiuk, lee_hasiuk@mcimail.com ------------------------------ Date: Tue, 9 Jun 1992 15:41:30 -0400 (EDT) From: Bob_Sidebotham@transarc.com Subject: Car computer downloading I have a new '92 Saturn SL with a computer controlled ignition system. I've been having some minor problems with cold start--sometimes after starting the car, the car seems to "hunt" for a good fast idle speed. It slow's the engine down until the RPM's reach zero and the car is about to stall, then suddenly boosts the engine speed to about 2000 RPM. Then it repeats. The Saturn service manager mentioned that there is a software change due out at the end of the month. Saturn HQ will download this change to each dealership (by satellite link, I believe), and then each car will receive the software the next time it checks in for servicing. This is likely related to my problem. There's all sorts of potential risks here, and no doubt many of them have been raised in this forum before. The important point is that the car I drive in to the service center is not the same car that I drive out! Prototypes of the car may have been driven for N million miles at proving grounds, but it didn't have the same software. How extensively has the software been tested? What are the security measures, if any, to ensure that the software I get is the software distributed by the factory? Do I have the option of not accepting the new software? I wonder if it's crossed anyone's mind that only downloading to selected cars would be a way of performing economical field tests on large numbers of cars (at some risk to those owners)? Even if this isn't explicitly intended, it works out that way since not all the cars are downloaded simultaneously--not yet, anyway. As a sidenote, when you check in for Saturn service, your car's history is also uploaded to Saturn HQ. Every engine stall, my salesman told me, is recorded, as is the entire service history for each vehicle. Bob Sidebotham, Transarc Corporation ------------------------------ Date: Wed, 10 Jun 92 12:22:14 xxT From: [anonymous] Subject: Telecom Australia allows easy denial of service attack I was dismayed to find out today that Telecom Australia (which holds a virtual monopoly on telecommunications in this country) will disconnect a line given only two pieces of information: * telephone number * subscribers name Anyone listed in the phone book, therefore, is an easy target for "prank" denial of service. More seriously, however, are some of the technology related considerations. The building in which I work has a number of outside lines on a rotary. The alarm system when triggered, however, notifies a security firm on a fixed line. A high-tech criminal could simply have that line disconnected and we would never know (since the other lines on the exchange would still work). There are two morals to the story. Firstly, the old problem of bureaucracies not validating requests is still alive and well. Secondly, the shortcoming of yet another automated system (our alarm) is highlighted when examining the TOTAL environment. How many mission critical telecommunications users verify the internal checks and policies of their service provider? ------------------------------ Date: Wed, 10 Jun 92 09:30:30 -0400 From: berman@gboro.glassboro.edu (Mike Berman) Subject: Follow-up to Dead Driver story -- PennDOT replies The following appeared on the letters page, Philadelphia Inquirer, Wednesday, June 10, 1992: The rest of the story Your story relating Eugene F. Smith's troubles with the Pennsylvania Department of Transportation (June 2) was not a complete representation of Mr. Smith's dealings with us. I'd like to offer your readers the rest of the story. When we received a police report that Mr. Smith had been killed in a car accident, we edited his driving record accordingly. When Mr. Smith learned of the mistake to his record -- after the police stopped him for a driving violation -- he wrote to us, and we corrected his record and issued him a photo identification card since he was not eligible for a driver's license. State law prevents me from disclosing any violations on an individual's personal driving record, so I cannot explain to you why a driver may be suspended or for how long. I can tell you that an indication on our record that a driver is deceased would in no way lead to a suspension. [comment --- special zombie permit?] I can also tell you that the rest of Mr. Smith's problems with Penn-DOT are because of his own disregard for state traffic safety laws. I have asked the Pennsylvania State Police to investigate Mr. Smith's case so that it can be settled correctly as the law provides. Within those legal parameters, we will work carefully with Mr. Smith to ensure that he understands his responsibilities to drive legally in Pennsylvania. Howard Yerusalim, Secretary of Transportation, Harrisburg ------------------------------ Date: Tue, 9 Jun 92 11:36:12 -0700 From: Fred Gilham Subject: Re: BBS Fraud (Lawson, RISKS-13.56) Another moral: [...] 6) `For Sale' notices for PC's etc. at low prices are posted from the stolen accounts. 7) Victims replying to the postings are requested to transfer money into the bogus bank account. 8) The money is withdrawn and the victims are out of luck. [...] Morals of this story: A) Use different passwords for different accounts. B) Log on regularly to check for irregularities. C) When buying things advertised by computer, use COD. -Fred Gilham gilham@csl.sri.com ------------------------------ End of RISKS-FORUM Digest 13.57 ************************