Thanks Jeff for your insightful response. In fact, here in California =
at
least, Diebold has already been found guilty of installing software on =
their
e-voting machines that was *never* certified by the state. This has led =
to
several of their machines being (rightfully) de-certified. So it seems =
they
already do just what you suggest they might.

I suppose though, that one could argue that posting *any* source code =
would
be quite an improvement. See
http://edition.cnn.com/2004/TECH/biz...oting.labs.ap/

~Jaeson


-----Original Message-----
From: Lorne J. Leitman [mailto:leitman@cs.pitt.edu]=20
Sent: Wednesday, September 22, 2004 1:05 PM
To: Jaeson Schultz
Cc: bugtraq@securityfocus.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