The RISKS Digest
Volume 9 Issue 50

Sunday, 3rd December 1989

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Vote counting problems - experience in Michigan
Lawrence Kestenbaum
Specs and custom software
Curtis Jackson
Pentagon Computer Costs
Gary Chapman
Software tool munges code
Nick Lai
Marshall Williams convicted of destroying data
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
Info on RISKS (comp.risks)

Vote counting problems - experience in Michigan

Wed, 29 Nov 89 20:38 EDT
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,

Vote counting problems - experience in Michigan (Kestenbaum)

"Peter G. Neumann" <>
Sun, 3 Dec 1989 12:57:33 PST
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...)

Specs and custom software (Re: RISKS-9.47)

Curtis Jackson <jackson@adobe.UUCP>
30 Nov 89 23:13:32 GMT
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

Pentagon Computer Costs

Gary Chapman <chapman@csli.Stanford.EDU>
Fri, 1 Dec 89 11:22:11 PST
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    

Software tool munges code

Nick Lai <lai@east.Berkeley.EDU>
Thu, 30 Nov 89 15:53:24 PST
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 "<ident>=-

Marshall Williams convicted of destroying data

"Peter G. Neumann" <>
Fri, 1 Dec 1989 16:01:26 PST
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]

Mitnick's accomplice sentenced

Rodney Hoffman <>
1 Dec 89 14:39:33 PST (Friday)
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.

Desktop forgery

Rodney Hoffman <>
1 Dec 89 17:59:20 PST (Friday)
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...."

Paul Brodeur's "Currents of Death" (new book)

Werner Uhrig <werner@rascal.ics.UTEXAS.EDU>
Thu, 30 Nov 1989 3:16:45 CST
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

McRisks - Electronic Interference in Fast Food Automation

Robert Horvitz <rh@well.UUCP>
Sat, 4 Nov 89 22:33:34 pst
"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

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

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.]

Please report problems with the web pages to the maintainer