[lbo-talk] more e-vote leakage

Curtiss Leung curtiss_leung at ibi.com
Fri Oct 31 09:40:46 PST 2003


Dwayne Monroe
> Is the source, at least from a technical point of
> view, of the profound suck-i-tude of electronic voting
> in the US becoming clear?

I haven't encountered published reports of the source code. That might actually violate copyright. On the other hand, the database practices Diebold used (and may still be using) are given in the article http://www.scoop.co.nz/mason/stories/HL0307/S00065.htm and they're pretty fucking awful:

--Vote tallies are duplicated across database tables (the five dollar phrase for th particular sin of duplicating information that should only be in one place is that the database tables are "denormalized," in case you're curious.) The obvious risk here is that the tally in one table can become out of sync with the tally in another--whether through malice or error--and the article shows what happens when the duplicated tallies are out of sync: a summary report prints one vote count, while a detail report prints another.

(Aside: I don't think this was done to assist in vote fraud. It's a common piece of short-sightedness. My experience is that denormalized databases are more common than normalized ones. The usual justification is that having copies of the same information, despite the risk of duplicates going out of sync, will result in better performance. The ironic thing is that to duplicate data in the first place, some sort of batch job is required, and as the application becomes more complex the data eventually does go out of sync, which requires some sort of reconciliation procedure, and in the end everyone ends up regretting that the database wasn't normalized in the first place. End of aside.)

--The default administrator password is the same for all installations. I wonder how many users bother to change it? Failure to change a default administrative password was a security problem with VAX systems; see Clifford Stall's _The Cuckoo's Egg_ for the whole awful story.

--Although the article is fuzzy on this, it seems a user with administrative privlege for one election (the Diebold system allows multiple elections using the same software and database) can gain administrative prilege for all elections: any administrator can modify the operator table to give users administrative privleges.

--The audit trail for database access can be altered. All database activity is logged in a table--but the table can be altered, and malicious activity deleted.

The actual DB used is MS Access. I haven't used it, but it may not make a difference; many of the flaws wouldn't be automatically effaced by using a fancier DB like Oracle, Sybase, or DB2. On the other hand, MS Access may itself have some inherent security weakness that make it unsuitable even if these flaws were corrected.

Curtiss



More information about the lbo-talk mailing list