Re: Optical scan computers shown vulnerable

From: Jim March <jmarch_at_prodigy_dot_net>
Date: Tue May 31 2005 - 20:57:37 CDT

Quoting Charlie:

>>It's not unprecendented.<<

OH yes it is, in the context of CERTIFIED CODE.

Charlie, this can't be passed off as stupidity. This is NOT normal PC
software we're dealing with, it's election products. The ability to add
new code to a machine that's NOT supposed to have field-loading of code
via normal operator control in a certified environment is deep into
"creepy music in a "B" movie grade sinister".

Lookit: we're talking optical scan boxes. They have firmware that's
certified and flashed in. There's no disk drive of ANY sort on the
sucker, only a PCMCIA slot that's supposedly used for DATA only.

Now we find that the motherboard firmware goes out to the PCMCIA card
and looks for new code to run?

Oh no. Like hell. Cue up the pipe organ set to "deep bass" 'cuz Boris
Karloff is gonna come shambling out next and try and suck somebody's
brains out through their eye sockets.

Jim

charlie strauss wrote:

>I dont know if I'd go so far as to say its sinister. Just to play the devils' advocate I'll suggest two (quite lame) situations where a programmer might think that calling code on the card was a good idea.
>
>if the card were the ballot description card as well as the vote storage card, the code might be code that was required to interpret some novel image format used in the display of the ballot.
>
>if the card were the vote storage card perhaps the card alos contains an algorithm used to encode the data stored on it rather than placing this in firmware on the machine itself.
>
>These of course are not sufficiently justifiable reasons to call executable code on something that most people would expect should be an inert obejct.
>
>It's not unprecendented. smart credit cards and smart RFID tags also can execute programs in response to queries. But in this case the processor is part of the credit card or tag. it is not running in the memory space of the polling unit's CPU. That would be viewed as asnine from a security standpoint.
>
>I guess the closest analogy to this sort of stupidity are the imbeciles that try to do secure website input validation on the client computer rather than the server. duh!
>
>
>-----Original Message-----
>From: Jim March <jmarch@prodigy.net>
>Sent: May 31, 2005 4:14 PM
>To: Open Voting Consortium discussion list <ovc-discuss@listman.sonic.net>
>Subject: Re: [OVC-discuss] Optical scan computers shown vulnerable
>
>To me, one of the key things Bev is pointing out here is that the
>documented and supposedly "certified" known code inside the Opscan
>firmware is "calling" any available code on the memory card, whatever it
>may be.
>
>This speaks of a very deliberate plot versus "security hole".
>
>Bev knows there's a June 16th deadline looming for the VSPP is and will
>have much more technical detail out by then or at that meeting.
>
>Jim
>
>Charlie Strauss wrote:
>
>
>
>>While it wont truly surprise anyone here, Bev harris's crew recently
>>demonstrated a design vulnerability in Diebold's optical scan computers.
>>
>>http://www.bbvforums.org/cgi-bin/forums/board-auth.cgi?file=/
>>1954/5921.html
>>
>>It's a seriously dumbed down breathy explanation. As I read it in a
>>nutshell, diebold's removable vote storage memory cards, which have a
>>high level physcial access, contain executables that get called
>>directly by the main program. Moreover these executable are
>>unencrypted and undergo no validation before being called.
>>
>>They showed that for example there were not even program length or
>>checksums to validate the stored procedures.
>>
>>they showed that infact the stored executable could alter the vote
>>totals and produce
>>1) perfect "zero" tapes
>>2) perfect total sums
>>3) shift an arbitrary number of votes from one candidate to another
>>4) do so without any diagnostics catching the switch.
>>5) pass logic and accuracy tests.
>>
>>One of course still needs physical access, but this considerably
>>lowers the barrier and most importantly enables the dreaded software-
>>injection-after-candidates-are-known threat.
>>
>>Why do people think it's a good idea to use fonts, graphics and now
>>memory storage formats that allow code execution? It's not like one
>>needs that sort of flexibility in a voting system. All the
>>executables should either live in one single defensible place or if
>>distributed then at least act as objects that don't allow each other
>>to modify their protected data.
>>
>>In other news intel is finally making computers that can do hardware
>>validation of the signed software for the entire boot process. I
>>strongly recommend that OVC only use such hardware.
>>
>>
>>
>>_______________________________________________
>>OVC discuss mailing lists
>>Send requests to subscribe or unsubscribe to
>>arthur@openvotingconsortium.org
>>
>>
>>
>
>_______________________________________________
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
>
>_______________________________________________
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
>
>
>

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue May 31 23:17:50 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:53 CDT