bugtraq - RE: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44.0409221553560.12537-100000@selenium.cs.pitt.edu>
Date: Wed, 22 Sep 2004 16:04:57 -0400 (EDT)
From: "Lorne J. Leitman" <leitman@...pitt.edu>
To: Jaeson Schultz <jaeson@...son.net>
Cc: bugtraq@...urityfocus.com
Subject: RE: Diebold Global Election Management System (GEMS) Backdoor   
 Account    Allows Authenticated Users to Modify Votes

What's to stop them from giving you source code for one executable, and
then installing something totally different on the machines, come election
day?

If you've read Ken Thompson's article "Reflections on Trusting Trust," you
realize that even the source code won't provide ultimate proof of security
and trustworthiness.  Only dissecting the object code taken from one of
the voting machines in production can do that, and that's an exteremely
difficult thing to do.

To quote from Ken Thompson's article (which can be found at
http://www.acm.org/classics/sep95/ ):

"The moral is obvious. You can't trust code that you did not totally
create yourself. (Especially code from companies that employ people like
me.) No amount of source-level verification or scrutiny will protect you
from using untrusted code. In demonstrating the possibility of this kind
of attack, I picked on the C compiler. I could have picked on any
program-handling program such as an assembler, a loader, or even hardware
microcode. As the level of program gets lower, these bugs will be harder
and harder to detect. A well installed microcode bug will be almost
impossible to detect. "

--Jeff Leitman

On Wed, 22 Sep 2004, Jaeson Schultz wrote:

> How about providing the source code so we can see for ourselves?  Shouln't
> the machines used for elections in a democracy such as The United States of
> America be open to such review?  Just because you refute the existence,
> doesn't mean that the "back doors" or "hidden codes" aren't there.  Only the
> source code can prove that.  Why should we just take your word for it?
>
> ~Jaeson Schultz
>
>
> -----Original Message-----
> From: pressinfo@...bold.com [mailto:pressinfo@...bold.com]
> Sent: Tuesday, September 21, 2004 8:05 AM
> To: bugtraq@...urityfocus.com
> Subject: Re: Diebold Global Election Management System (GEMS) Backdoor
> Account Allows Authenticated Users to Modify Votes
>
>
> In-Reply-To: <20040831203815.13871.qmail@....securityfocus.com>
>
> Diebold strongly refutes the existence of any "back doors" or "hidden codes"
> in its GEMS software.  These inaccurate allegations appear to stem from
> those not familiar with the product, misunderstanding the purpose of
> legitimate structures in the database.  These structures are well documented
> and have been reviewed (including at a source code level) by independent
> testing authorities as required by federal election regulations.
>
>
>
> In addition to the facts stated above, a paper and an electronic record of
> all cast ballots are retrieved from each individual voting machine following
> an election. The results from each individual machine are then tabulated,
> and thoroughly audited during the standard election canvass process. Once
> the audit is complete, the official winners are announced.  Any alleged
> changes to a vote count in the election management software would be
> immediately discovered during this audit process, as this total would not
> match the true official total tabulated from each machine.
>
>