Reply #28: join the club, lol

[Neil B Forzod]

That said, I'm happy that I managed to evade the Mighty Forzod Boot.

LOL. :D

That's crucial. I wouldn't assume that that actually happens. Violations of basic procedures seem to be very common, so I would not count on this being an exception. (Especially in elections where new technology is being rolled out, I can imagine anarchy being the rule.) But I certainly hope that it happens somewhere, and that should be a constraint on the amount of fraud that can go down via memory cards.

You're absolutely right on all counts. Following procedures like the one referred to here (and various others) is absolutely crucial, and I'm quite certain you're right that violations of those procedures are probably common. When correct procedures are followed, a lot of potential attack vectors are minimized. When they're not followed, well... you probably deserve whatever you get. By the same token, people should lock their car doors and take their keys with them after exiting. People who don't follow this basic procedure and leave the car unlocked with their keys in the ignition risk having bad things happen to them. It's mostly common sense.

All that said, if there are specific vulnerabilities identified in a particular voting system, those vulnerabilities should be addressed. To treat it like the coming of the apocalypse a la Bev Harris is silly. Microsoft released updates to Windows for three "critical" security issues this week alone. Does this mean nobody should run Windows? Hardly. Does it make Windows a bad system? No, it means somebody missed something in a large, complex system (although I do admit to knowing several Linux purists who will claim everyone should dump Windows and switch to Linux instead, so maybe my example is a poor one ;) ). So if there's a real issue with a Diebold unit, Diebold should simply fix it, then certify and make available a new release containing the fix. Security issues in all kinds of software are reported literally all the time. Big deal.

Pardon me if I am asking you to repeat yourself, but since I gather that this exploit doesn't make your list of major security concerns, what does?

That's a good question, but kind of a tough one to answer. I'm actually reserving judgment on the severity of this particular exploit pending some more investigation... I'm not classifying it as major or minor at this time, since it's impossible to tell based on Ion Sancho's willful ignoring of basic procedures.

But in more general terms, major security concerns (to me) include anything that can be perpetrated without detection, assuming realistic operational procedures. The ability to make "wholesale" manipulations of the results (e.g. for a whole jurisdiction at once) versus a more "retail" attack (e.g. for individual machines) increases the severity of an issue, in my view.

Attacks that are described as "an attacker could do X if procedure Y was ignored" aren't that interesting to me. "You can remove and modify a memory card if nobody inspects the tamper seals". OK, fair enough. But "my house could blow up if nobody turns off the gas oven" too, although I'm not going to lose any sleep over it. My statement holds true as long as "Y" is actually reasonable. Inspecting tamper-evident seals is reasonable, in my view. Asking a poll worker to execute a dump of memory card contents to a local computer and perform a binary comparison against a trusted copy of the expected data is something that might equally detect tampering but it isn't a reasonable procedure to require. On the other hand, asking a poll worker to verify a hash value printed on the report tape by the voting machine firmware is something that I'd classify as reasonable.

I could go on, but it's late and I'm tired. Besides, I don't have any specific vulnerabilities to post here about any voting system I'm familiar with -- and even if I did, it would be foolish and irresponsible for me to post them here anyway. :) More responsible would be to document the issue and any exploit of it, and to submit that to the vendor in question so that they can investigate and/or fix it. Trying to ambush a vendor (whether it's Microsoft, or Apache, or the Linux group, or Diebold, or whoever) by publishing a perceived exploit without notifying that vendor first is irresponsible and juvenile.


Neil