RISKS-LIST: RISKS-FORUM Digest Sunday 3 December 1989 Volume 9 : Issue 50 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Vote counting problems - experience in Michigan (Lawrence Kestenbaum, PGN) Specs and custom software (Curtis Jackson) Pentagon Computer Costs (Gary Chapman) Software tool munges code (Nick Lai) Marshall Williams convicted of destroying data (PGN) Mitnick's accomplice sentenced (Rodney Hoffman) Desktop forgery (Rodney Hoffman) Paul Brodeur's "Currents of Death" (Werner Uhrig) McRisks - Electronic Interference in Fast Food Automation (Robert Horvitz) 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 . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: Wed, 29 Nov 89 20:38 EDT From: WCLX@VAX5.CIT.CORNELL.EDU Subject: Vote counting problems - experience in Michigan I have followed with interest the recent discussions of vote-counting errors in Durham NC, Yonkers NY and elsewhere. Perhaps the following may be of interest. It is a discussion of a specific vote counting problem in a jurisdiction where I served until last year as an elected official. Lawrence Kestenbaum, 506 S. Albany St., Ithaca NY 14850 (607) 272-7750 [grad student at Cornell University in City and Regional Planning (specializing in Historic Preservation), an attorney licensed in Michigan (number P34957), and a former Ingham County Mich Commissioner, elected from the 8th District in 1982, 1984 and 1986. Nothing in this message is private or privileged information.] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Some of the recent problems with inaccurate election-night vote tallies can be traced to the badly-handled interface between computer and manual systems. Non-electronic vote counts, for example, are mistyped on computer screens during the hectic atmosphere of election night. Of course, when the computer system plays the dominant role, the difficulties with the non-computerized parts are even greater. While most of the Northeast still votes on the old-style lever machines, the Midwest -- Michigan at least -- has largely moved to computer punch card ballots. Punch cards have certain advantages: in the event of a recount, a tangible, anonymous record exists of each voter's choices. By contrast, recount lawyers are often able to find whole voting machines whose votes must be excluded from the count because of mechanical problems, thus disfranchising anyone who voted on that machine. Other problems are possible, but all in all, results from punch card jurisdictions are regarded as being much more 'firm' and resistant to being altered in recounts and challenges. At the same time, it lulls political people into a sometimes unjustified faith in computer-generated vote tallies. When I served on the county board in Ingham County, Michigan (1983-88), we had a mixed system. The choice of voting method was made individually by the 21 townships and cities within the county. Thanks to strong persuasion by the county clerk, almost all of the 250 or so voting precincts in the county voted on punch cards. The remaining five precincts, in four small jurisdictions, used voting machines; absentee voters in those five precincts used punch cards. In no other part of the county were absentee votes counted separately. Under contract with most of the punch-card jurisdictions, the county provided the materials and organized the ballot counting process. The software which aggregated and reported the votes for the county, and also automatically generated all of the official statements to be attested to by the Board of Canvassers, did not allow for the entry of non-computer precincts. Thus, the county clerk's people had to break into the program and override its security features in order to input the numbers for the five rogue precincts. The risks here should be obvious! Invariably, this task was postponed until very late at night, when the operators (who normally worked 8am to 5pm) were extremely tired. More than once, as I recall, this led to errors in the overall totals, though none which changed the outcome, and all were corrected by the following day. After a few years of this, the county clerk (with full support from the county board) mounted a major effort to corral the five remaining precincts. He succeeded with all but one of them, the City of Leslie. So, on a smaller scale, the problem -- and RISK -- continues. Lawrence Kestenbaum, wclx@vax5.cit.cornell.edu ------------------------------ Date: Sun, 3 Dec 1989 12:57:33 PST From: "Peter G. Neumann" Subject: Vote counting problems - experience in Michigan (Kestenbaum) Lawrence Kestenbaum's message gives an interesting first-hand account. However, there is much debate in the election computing community about the relative tamperabilities of machine-readable cards (punched or mark-sensed), lever machines, and direct-entry screen menus. Punched cards give results that are more or less repeatable (ignoring the hanging chad problems). But they are subject to tampering BEFORE any votes are ever tabulated (removed cards, added cards, multipunched cards, hidden prepunches, trick punches that unleash Trojan horses, etc.), which can make the repeatability argument moot. The RECOUNT would mask the prior fraud and even add apparent credibility! The fantasy that there is a CORRECT anonymous physical record is very tricky to convert into a reality. (There are different vulnerabilities in the other types of systems, such as the presence of perfectly repeatable but hidden and probably undetectable Trojan horses in the direct-entry systems -- especially in proprietary systems. See earlier RISKS...) ------------------------------ Date: 30 Nov 89 23:13:32 GMT From: jackson@adobe.UUCP (Curtis Jackson) Subject: Specs and custom software (Re: RISKS-9.47) I worked on custom military design for almost 7 years recently. I have two anecdotes to relate regarding recent RISKS discussions: 1) Some colleagues and I endeavored to design the operating systems for the latest in a series of custom large-control-word multi-processor signal processors using a purely waterfall model. We insisted on writing the design spec before writing any code, and finalizing the design spec (after initial review) down to the individual bit level. We then wrote pseudo-code for all modules, and peer-inspected those. Finally we wrote the code with strict commenting standards and assembled it, then peer-inspected that. Finally we wrote module tests, simulated those, then string tests, simulated those, and one day the hardware was off the drawing boards and in the lab. The results? The development cycle, with full waterfall design method and full regression tested test database, was only 2 months over schedule (former efforts on similar jobs ran up to a year over). The norm for getting a basic operating system up and running in a lab environment without bells and whistles was 6-9 months -- it took us a week. Overall savings in development/debug time -- probably at least 40%. Overall savings in down-the-road software maintenance -- untold. So let me say that I am skeptical at best when someone tells me that waterfall design should be dumped on large involved custom software/hardware projects. 2) I had a chance to have a several-hour chat with a Navy commander who headed the technical management on the Navy end of our several-hundred-million-dollar project. He noted that the average time for delivery of a large military contract now was 8 years and growing, and that the results were far from satisfactory, particularly in the RISKS area. He blamed much of this on government procurement and the rampant cover-your-ass overspec'ing that went on. He proposed a system wherein the contractor(s) would study and prototype for some time, a year for example, then come back and note the 10% of the job that they felt was overspec and would cause serious money, time, and risk problems. Independent government negotiators would then attempt to take these portions out of the contract if they were indeed overspec, but the contractor would suffer little or no degradation in the original price quoted for the contract for their having pointed these overspecs out. He estimated the average deliverable time would go down to about 5 years, and the products delivered would be slightly cheaper and much more reliable. He also was sure his ideas would never fly at the Pentagon. :-( Curtis Jackson @ Adobe Systems in Mountain View, CA (415-962-4905) uucp: ...!{apple|decwrl|sun}!adobe!jackson ------------------------------ Date: Fri, 1 Dec 89 11:22:11 PST From: chapman@csli.Stanford.EDU (Gary Chapman) Subject: Pentagon Computer Costs The New York Times today (12/1/89) features a story by Jeff Gerth that says that the modernization of a Pentagon computer system used for general data processing is a billion dollars over budget, and far behind schedule. And the congressional report released about this system says that Pentagon computer systems have experienced "runaway costs and years of schedule delays while providing little capability." Charles A. Bowsher, the head of the General Accounting Office, says that problems with the Pentagon's accounting system may impede efforts to reduce spending in the Department of Defense because of inaccuracies in the data used to manage the Department. Today's New York Times article reports only on cost overruns and delays in accounting and data-processing systems used by the Department of Defense and the services. But there are also these examples one could add to the list: * The C-17 cargo plane being built by Douglas Aircraft has a $500 million cost overrun because of problems in its avionics software, and the software contractor has been fired, according to a member of Congress. * The B-1 bomber still needs more than $1 billion to improve its ineffective air defense software. The B-1 was originally sold as a "penetrating bomber," meaning it was supposed to be able to penetrate Soviet air defenses. Because of problems with its computer software, however, the B-1 is not expected to be able to penetrate Soviet air space, and that's why the Air Force is asking for the B-2 (which has its own software problems). (At one point the B-1 electronic countermeasures software created what was called a "beacon" effect, meaning it would actually alert Soviet air defenses and give their radars a clearer signal of the aircraft than they would have if the airplane's systems had been turned off.) * The software for the modernization of the Satellite Tracking Control Facility is about seven years behind schedule, about $300 million over budget, and will provide less capability than what the original con- tract called for. * The modernization of the software at NORAD headquarters is about $250 million over budget, years late, and still non-operational. * The Airborne Self-Protection Jammer (ASJP), which is an electronic air defense system installed in over 2,000 Navy fighters and attack planes, is $1 billion over budget, four years behind schedule, and, accord- ing to a Navy report, is only "marginally operationally effective and marginally operationally suitable." As General Bernard Randolph, commander of the Air Force Systems Command, said in February, "We have perfect record on software schedules--we have never made one yet and we are always making excuses." Gary Chapman, Executive Director, CPSR chapman@csli.stanford.edu ------------------------------ Date: Thu, 30 Nov 89 15:53:24 PST From: lai@east.Berkeley.EDU (Nick Lai) Subject: Software tool munges code The "indent" program (C code formatter) distributed with Berkeley UNIX has an insidious misfeature/bug in it. The bug is also present in the version that comes with SunOS. The Ultrix folks appear to have written their own "indent", which does not have the bug. The problem is that "indent" takes expressions of the form "=-" and silently converts them to " -= ". So instead of *assigning* the negative value on the RHS to the variable on the LHS, the variable is *decremented* by the RHS value. I discovered this because an instance of the above expression occurred in an initialization ("int x=-1;" -> "int x -= 1"), generating a syntax error. If this had not occurred in an initialization, who knows when the impact of the change would have reared its ugly head ("Hey! My F-16 just started plummeting towards the ground!"). K&R Appendix A.17 ("Anachronisms") notes that the "op=" assignment operators were once written "=op". So at some point in the prehistoric past, the above conversion might have been valid. Under the standard C syntax, however, "indent" simply munges your code. Nick ------------------------------ Date: Fri, 1 Dec 1989 16:01:26 PST From: "Peter G. Neumann" Subject: Marshall Williams convicted of destroying data Marshall Williams, a former company cost estimator for Southeastern Color Lithographers Inc., Athens GA, was convicted on 16 Nov 89 for "using his company's computer network to destroy billing and accounting data as well as backup copies of that data". A key piece of evidence was a computer audit trail of data-deletion commands that traced deletions to his terminal. The defense raised the potential for a frame-up resulting from someone tampering with the audit trail data. (No one seems to have suggested that someone else might have been using his terminal.) The crime allegedly cost Williams' former employer more than $400,000 in lost business and downtime. He faces up to 15 years in prison. Williams contended that he "knew nothing about his employer's complicated Xenix operatiung system and could not have deleted the data." He plans to appeal. [Source: PC Week, 27 November 1989, p.1, article by Richard March] ------------------------------ Date: 1 Dec 89 14:39:33 PST (Friday) From: Rodney Hoffman Subject: Mitnick's accomplice sentenced Leonard DiCicco was once a friend of convicted hacker Kevin Mitnick (see RISKS 9.6 and 9.7). In July, DiCicco pleaded guily to charges of permitting Mitnick to gain access to a computer at DiCicco's workplace last December, which was then used to steal a $1-million DEC security software program. According to a small notice in the "Los Angeles Times" 30-Nov-89, DiCicco has now been sentenced to 5 years' probation, plus 750 hours of community service, part of which will be spent installing a computer system at a shelter for the homeless. ------------------------------ Date: 1 Dec 89 17:59:20 PST (Friday) From: Rodney Hoffman Subject: Desktop forgery DESKTOP FORGERY, by David Churbuck, is the cover story in the 27-Nov-89 issue of "Forbes". It tells how to scan in a check, alter it, print it, and pass it (with a few details omitted), and it tries to frighten bankers and others with the endless possibilities. Churbuck does note, "To be sure, the desktop computer did not create the crime of forgery. All it did was make the tools user-friendly. Check-passers can now practice forgery in the privacy of their own homes...." ------------------------------ Date: Thu, 30 Nov 1989 3:16:45 CST From: Werner Uhrig Subject: Paul Brodeur's "Currents of Death" (new book) On the CBS program NightWatch (for vampires and am-hackers) I just watched an interview with Paul Brodeur who wrote those articles in the New Yorker this spring on the danger of radiation of electrical fields (high voltage power-lines, heating blankets, display terminals) and who has just come out with a new book titled "Currents of Death" which some of you may want to put on your Xmas reading list also. I had not realized this before, but this man was also in the forefront of the battle of getting the public's attention on the Ozone problem (10 years ago) and the Asbestos problem (20? years ago). A man worth paying attention to, it seems. ------------------------------ Date: Sat, 4 Nov 89 22:33:34 pst From: rh@well.UUCP (Robert Horvitz) Subject: McRisks - Electronic Interference in Fast Food Automation "The Importance of EMC in the Preparation and Selling of Big Macs," by Fernando M. Esparza is a fascinating article in the September- October 1989 issue of "EMC Technology." (EMC = Electromagnetic Compatibility, the science/art of getting electronic devices to work properly without interfering with one another.) Esparza, the author of McDonalds' "Electrical Disturbance Standards," has some great war-stories to tell about problems cropping up in these highly automated fast-food environments due to unforeseen interactions among appliances. One he described as "the most serious interference incident that McDonalds has ever experienced" involved toasters and timekeeping. It seems that when McDonalds decided to introduce McMuffin products, they had to install special toasters. Soon, many of their employee time-clocks inexplicably started to gain 2 to 4 hours each day, crediting workers with more hours than they had actually worked. After a lot of head-scratching (and testing), they discovered that the new toasters' voltage control circuits induced voltage spikes in the powerline during normal operation - sometimes as many as 120 per second. This disrupted the clocks on the same power circuit, since they monitored the alternating current's waveform for the purpose of time-keeping: the voltage spikes increased the number of "zero-crossings," which were used as the metric. "By the time we were able to pin down the problem exactly, there were more than 5,000 toasters installed in the restaurants... Some restaurants reverted to manual procedures for payroll timekeeping, but there were a number of employees who were paid for extra time because of the clock errors. Although the managers were understandably upset, none of the crew complained." "Ghosts in the Drive-Thru" was another baffling problem, affecting the POS (point-of-sale) system of a McDonalds in suburban Los Angeles: "The POS system is a collection of computerized cash registers that are networked together in a somewhat sophisticated and proprietary network," Esparza explains. The problem was that bogus food orders showed up randomly in the system. "The restaurant could distinguish ghost orders from real orders because the quantity of the items displayed was the same - 11 cokes, 11 fries, 11 hamburgers, etc. The items themselves were directly copied from the previous, actual order. These orders could not be cancelled but had to be cashiered out of the system, thereby rendering all product mix and sales information invalid and creating a potential security/theft problem, in addition to slowing customer service in the drive-thru." The restaurant's POS system and all of its software was replaced, but the problem continued. To make a long story short, this McDonalds happened to be near a cluster of radio and television transmission towers. The POS system's wiring acted as an antenna, capturing the signals, and corrupting some of the data that flowed thru the wires. One problem described in this article stands out as a potential threat to many more retailers than just McDonalds: "The Cash Drawers that Opened by Themselves." Again making a long story short, Esparza discovered that the problem began soon after the local police department upgraded their communications system with higher-power mobile radios. "Whenever they responded to a call while in the drive-thru, the cash drawers opened... An open cash drawer without a cashier to supervise it is...a large security liability." Have any RISKS readers heard of police radio transmissions inadvertantly opening other businesses' cash registers? ["EMC Technology" is a controlled circulation bimonthly. Subscriptions are free to those who qualify, $40/year for those who don't. For more information contact EMC Technology Circulation Dept., 5615 West Cermack Rd., Cicero, IL 60650-2290 USA.] ------------------------------ End of RISKS-FORUM Digest 9.50 ************************