Slashdot Mirror
Diebold Voting Machines Audited by California
Panaqqa writes "Diebold must be wondering what else can go wrong. Considering their arrogance in the past, their comeuppance is truly well deserved. The State of California's source code review [PDF] of the Diebold voting system has been released. Additional reports will be made available as the Secretary of State determines that they do not inadvertently disclose security-sensitive information. One wonders what it will take to convince voting machine manufacturers not to do things like hard coding passwords as '12345678.'"
12345678... That sounds like the password some idiot puts on their briefcase.
09F911029D74E35BD84156C5635688C0
+2 Troll is Slashdot's way of saying groupthink is confused
how after all the many serious screw-ups and warnings that Diebold has had in the past couple of years, this report shows they still didn't do anything at all to improve the situation.
I often wondered how managers and CEO's that don't even have a clue get given companies to control. This level of obvious incompetence makes me wonder even more.
Voting machines are a technical non-solution to a non-existing problem. Counting votes by hand in public view is almost as fast, has much fewer things that could go wrong with them, and is intrinsically open to public scrunity like no machine system can ever be. Plus, it's cheaper. It works in Denmark, it should scale perfectly well to the US.
We have a psychic bond! I use that exact same password on my luggage and machines!
We're password buddies!
I prefer Flambe as apposed flamebait.
They'd never sell a single one. No bank would accept an ATM that couldn't accurately track the thousand or so transactions that they see each day, or that anyone could gain control of by typing in a few keys followed by "12345678".
And yet somehow (through much campaign cash, etc.) they managed to convince politicians that all that stuff would be too hard and unnecessary in voting machines, despite the technology already being available from the same company. That it's not hard to count accurately millions, even billions, of dollars in transactions each day, but that it's too hard to simply increase by one the count in the proper register to greater than a few percent accuracy. And despite numerous security incidents, they are still fighting tooth and nail these simple things.
I'm not convinced electronic voting is necessary...but I'm wary of any politician that keeps trying to tell me there's no need to increase the security of such systems. Unless they say they're OK with their own banks using that kind of security, voting shouldn't use it either.
It's a step in the right direction, but really, is an audit even needed?
This is like building a nylon tent to hold your valuables, then performing an audit to evaluate the strength of its zipper. The entire concept is idiotic from the start.
There's a simple solution to voting machine security: use paper ballots. The machines can help you fill them out, but the result should always be a paper ballot which is the authoritative record of your vote. Simple, easy, secure. Why isn't this being done? Who knows, but it's clear the concerns of the people in charge are something other than correct vote counts.
From AV-TSX bootloader code:
// Check for library not initialized or (x,y) out of range
// Compute the frame buffer offset and write the pixel
void GlibPutPixel(UINT xx, UINT yy, Pixel_t Color)
{
if(FrameBuffer != FALSE || (xx < USER_X) || (yy < USER_Y))
{
FrameBuffer[FB_OFFSET(xx,yy)] = Color;
}
}
TCHAR name;
_stprintf(&name, _T("\\Storage Card\\%s"), findData.cFileName);
Install(&name, hInstance);
First uses logical OR instead of logical AND to check boundaries, second writes a string where there is only storage for one character!
I can almost imagine that being a deliberate ploy. "
I'm sorry your honour, but one of our programmers (no longer under our employ) hard coded a weak password in complete disregard of coding standards. Regretably, the weakness of the password has enabled certain parties to guess what it is, and thereby subvert the electoral process. But it's not our fault."
Hanlon's Razor be dammned. In cases like this we should start assuming malice unless they can prove stupidity beyond any reasonable doubt.
Don't let THEM immanentize the Eschaton!
The votes on 10 ballots are totaled and this total is recorded on a marker sheet placed on top. Then the bundle is tied up. (10 ballots)
10 of those bundles are totaled on a different marker sheet and bundled together. (100 ballots)
10 of those bundles are totaled on a different marker sheet and bundled together. (1,000 ballots)
10 of those bundles are totaled on a different marker sheet and bundled together (10,000 ballots)
And so on. The idea being that any individual bundle can be quickly verified or re-counted. And because it's all base 10, it is easy for MOST humans to visually verify the bundles themselves. The ones that can count to ten, that is.
I believe that it can be (but not necessarily is) pure incompetence. Most developers that I've met have no business writing code that would be usable in a 'secure' environment, and the pen tests that are now done as a matter of practice on our outward-facing systems routinely rip our devs work to shreds. It's gotten to the point that the developers want to know what methods will be used in the pen tests so that they can protect against them. We in the security group have steadfastly refused to provide them anything other than a timespan when the test will be happening, so that they know not to update code in the middle of it, and so that they can't do targeted coding before-hand.
One of the major problems that I see is that the developers rely far too much on security by obscurity, no matter what the project covers, figuring that if the attacker can't see the code, then he can't see vulnerabilities, and they don't read enough about vulnerability research to understand how critically dangerous this is. They do things like requiring SSL for the front-end session, encrypting the back-end FTP transfer, and splitting off the management interface to an internal server, while leaving the access controls for the database identical for both systems, requiring only short passwords, allowing an inordinate number of password retries, using poor seeding techniques for session IDs, and leaving nearly-default configurations of the web server in place.
I tend not to place as much value in accusations of malice as I do in observations of incompetence. When presented with a result like this from any random company, I am far more likely to attribute it to the latter, unless presented with some fairly strong evidence to the contrary.
You can never go home again... but I guess you can shop there.