Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Voting Machine Attacks Proven To Be Practical

kdawson posted about 5 years ago | from the back-up-the-dumpster dept.

Security 225

An anonymous reader writes "Every time a bunch of academics show vulnerabilities in electronic voting machines, critics complain that the attacks aren't realistic, that attackers won't have access to source code, or design documents, or be able to manipulate the hardware, etc. So this time a bunch of computer scientists from UCSD, Michigan, and Princeton offered a rebuttal. They completely own the AVC Advantage using no access to source code or design documents (PDF), and deliver a complete working attack in a plug-in cartridge that could be used by anyone with a few private minutes with the machine. Moreover, they came up with some cool tricks to do this on a machine protected against traditional code injection attacks (the AVC processor will only execute instructions from ROM). The research was presented at this week's USENIX EVT."

cancel ×

225 comments

Sorry! There are no comments related to the filter you selected.

Hey slashdot! (-1, Troll)

Anonymous Coward | about 5 years ago | (#29026349)

Rob Malda's asshole is so blown out that when we had sex last night he kept shitting even when I WASN'T asking for the cleveland steamer!

Re:Hey slashdot! (0)

Anonymous Coward | about 5 years ago | (#29028031)

I would say switch to Steve Job's but the apple fanboys beat you to it.

If they own it, whats the problem? (4, Funny)

A. B3ttik (1344591) | about 5 years ago | (#29026419)

They completely own the AVC Advantage using no access to source code or design documents

What do Source Code and Design Documents have to do with purchasing something?

Re:If they own it, whats the problem? (0)

jittles (1613415) | about 5 years ago | (#29026563)

The point of the article was to show that without any insider information, they were able to take control of the results of an election. That seems to have gone right over your head.

But of course any sophisticated hacker is going to do whatever they can to get access to the internal workings of the box.

Re:If they own it, whats the problem? (3, Funny)

amicusNYCL (1538833) | about 5 years ago | (#29026591)

Jeez, talk about going right over your head.

Re:If they own it, whats the problem? (5, Funny)

A. B3ttik (1344591) | about 5 years ago | (#29026599)

That seems to have gone right over your head.

The irony here is palpable.

Re:If they own it, whats the problem? (0)

Arthur Grumbine (1086397) | about 5 years ago | (#29027705)

That seems to have gone right over your head.

The irony here is palpable.

Palpable?! Bah! Let me know when it's pulp-able, so I can start making smoothies from it.

Re:If they own it, whats the problem? (5, Insightful)

Anonymous Coward | about 5 years ago | (#29026565)

The problem is our elections are supposed to be transparent by law.
The problem is our elections are supposed to have public oversight.
The problem is a private company can not provide public oversight.
The problem is electronic vote tabulation devices use invisible signals which no human (especially a poll watcher) can see.
The problem is China or North Korea could decide our elections and we wouldn't know.
The problem is there is no electronic vote tabulation device (or electronic vote registration poll book device) which can be validated with public oversight.
The problem is without public oversight, no election can be validated.
The problem is if our elections can not be validated, we can not hold our representatives responsible.
The problem is if our representatives can not be held responsible, they tend to ignore the rule of law.
The problem is if our representatives ignore the rule of law, they tend to ignore protecting the US Constitution against all enemies.
The problem is when the US Constitution is ignored, we no longer live in a Constitutional Republic.
The problem is when we no longer live in a Constitutional Republic, we slip into fascism.
The problem is we have slipped into fascism.
The problem is ignorance is no longer an excuse for corruption.

Re:If they own it, whats the problem? (0, Troll)

Anonymous Coward | about 5 years ago | (#29026753)

I agree wholeheartedly.

Let's all grab our torches and pitchforks and storm the House and the Senate while they're in session, beating the living shit out of everybody inside. Then we hold them all for ransom and exchange their worthless lives for our dignity and a working middle class. We can use the ones from the Southern states as food if negotiations take too long.

Re:If they own it, whats the problem? (0)

Anonymous Coward | about 5 years ago | (#29027111)

I think that's a fantastic idea to be perfectly blunt. I don't see any point in holding them ransom though. Simply throwing out all the bullshit laws they've passed for the last 100 years and executing them for abuse of power would be enough. Then put in place people who actually want to serve the public ... and term limits.

Since WW2 our federal government has operated in the absence of accountability ... and humans allowed to operate in such a way will abuse their power and those around them 99 times out of 100.

Re:If they own it, whats the problem? (1)

FiloEleven (602040) | about 5 years ago | (#29028025)

Then put in place people who actually want to serve the public ...

And just how do you propose to discern between those people who desire to serve the public and those people who say they desire to serve the public but are really more interested in power?

Instead of calling for executions, you ought to execute calls. Public pressure is the only way to keep politicians working for the public, and the telephone is the most powerful way to communicate with them. It's more important than voting and makes more of a difference.

Re:If they own it, whats the problem? (1)

Merls the Sneaky (1031058) | about 5 years ago | (#29028121)

And stop paying them, you shouldn't be in government for a salary. Also stop non-individual entities (corporations) from providing "campaign contributions".

Re:If they own it, whats the problem? (2, Funny)

whopub (1100981) | about 5 years ago | (#29027219)

Finally, a plan!

Re:If they own it, whats the problem? (1)

JustOK (667959) | about 5 years ago | (#29027515)

Can we stop and get something to eat first? I'm hungry. Dave says he needs to get some sun-block.

Re:If they own it, whats the problem? (1)

HTH NE1 (675604) | about 5 years ago | (#29027341)

The problem is if our representatives can not be held responsible, they tend to ignore the rule of law.

We've already got that without everything that you listed before.

Re:If they own it, whats the problem? (1)

Tubal-Cain (1289912) | about 5 years ago | (#29028119)

The problem is our elections are supposed to be transparent by law.
The problem is our elections are supposed to have public oversight.

Down with transparent elections and public oversight!

Re:If they own it, whats the problem? (1)

Stupendoussteve (891822) | about 5 years ago | (#29026575)

Generally without access to source code or design documents you are merely licensing the software. In this case they managed to completely own it! I'm sure they somehow activated Windows without clicking the EULA.

Re:If they own it, whats the problem? (1, Funny)

RobotRunAmok (595286) | about 5 years ago | (#29026605)

I think -- and I could be wrong -- that "Owning" is like "Pwning," and it means "to dominate," if you're fourteen.

Re:If they own it, whats the problem? (1)

HTH NE1 (675604) | about 5 years ago | (#29027595)

Owning is done to you; pwning you do to yourself out of your own stupidity. See also FAIL.

Still not fair. (5, Funny)

MartinSchou (1360093) | about 5 years ago | (#29026449)

What these "intellectuals" and "researchers" have to keep in mind, is that in reality, no one would ever dream of committing election fraud.

We all live in a utopia, where everyone has equal say, no one would ever coerce others and there's a kitten on every lap. That's why there are no such things as secret ballots. In every voting booth there will be three heavily armed guards who will watch you vote to ensure that you won't be doing anything you shouldn't do.

Have a cotton candy, drink your beer and turn on the TV. The shiny shiny is on again, you like that. You have always liked that.

</sarcasm>

Re:Still not fair. (5, Insightful)

InsaneProcessor (869563) | about 5 years ago | (#29026547)

I work in the computer industry and do not trust any electronic voting system. The more complex a system (any physical system) the more susceptible it is to attack. Give me good old paper ballots any day.

Re:Still not fair. (1)

Helios1182 (629010) | about 5 years ago | (#29026787)

There are ways of combining electronic and paper systems so that they are more reliable and more difficult to defraud then either paper or electronic alone. The problem is that no one seems to be willing to sell such a machine.

Re:Still not fair. (1)

causality (777677) | about 5 years ago | (#29026921)

There are ways of combining electronic and paper systems so that they are more reliable and more difficult to defraud then either paper or electronic alone. The problem is that no one seems to be willing to sell such a machine.

I'm perfectly happy with elections being as low-tech and simple as reasonably possible, i.e. paper. I'll gladly pay the few more cents in taxes every few years that ultra-efficient electronic elections would have saved me. All of this desire to have marginal gain at the expense of substantial risk is one of the worst examples of decision-making.

Re:Still not fair. (1)

Missing_dc (1074809) | about 5 years ago | (#29026983)

There are ways of combining electronic and paper systems so that they are more reliable and more difficult to defraud then either paper or electronic alone. The problem is that no one seems to be willing to sell such a machine.

No, the problem is that no one wanting to count the votes would be willing to BUY such a tamperproof machine.

Re:Still not fair. (2, Interesting)

Anonymous Coward | about 5 years ago | (#29027781)

The fact that we had one election "stolen" by the R's in 2004 (so say the D's), and the fact that we had the next election "stolen" by the D's in 2008 (so say the R's), should be proof, at least, that there is no ultimate ability to steal on either groups part - otherwise, once you have power, why ever let the other side win?

It would also imply the following:

If we have an illegitimate vote in 2004, then it is nonsensical for "them" to not have taken advantage of their power in 2006 and 2008. If that is true, then the belief that Diebold or some other group hacking the results is unfounded.

BTW - "a few minutes of access" is a bit of a misnomer. It's one thing for James Bond to break into a secure area and do some pinpoint damage, but breaking in and influencing millions of machines across America is unrealistic. I have been a poll worker, and there are few opportunities to hack the machines as would be needed. The system I used did an electronic read of paper ballots. While this could have been hacked, it would be unlikely to stand up to the manual count we did at the end of the day to cross-tabulate against the electronic count. If I'm not mistaken, this already had the benefits of speed and tamper-prevention requested by an earlier poster.

Re:Still not fair. (3, Informative)

fuzzyfuzzyfungus (1223518) | about 5 years ago | (#29028077)

I make no claim, one way or the other, about the presence or absence of American electoral fraud; but your point doesn't really follow. Fraud isn't a binary condition(well, in the strictest sense it is; but in a practical sense it isn't). A perfect fraudster could dictate the outcome of every vote cast, without outcry. A wholly impotent fraudster could dictate the outcome of zero votes cast. Actual frauds are somewhere in the middle. If, say, you can manage a 5% nudge without drawing excessive attention, your party will win more than it deserves(probably substantially so, given the fairly low margins by which elections are often won); but a really bad electoral cycle would be beyond your power to change.

The absence of perfect fraud does not indicate the absence of fraud.

Re:Still not fair. (1)

fataugie (89032) | about 5 years ago | (#29027471)

Riiiight.

Because no one could stuff a ballotbox, eh?

Ask Mayor Daily in Chicago how secure they are.

Re:Still not fair. (0)

Anonymous Coward | about 5 years ago | (#29026549)

I don't like shiny shiny. It has to be blinky shiny or shiny blinky.

I believe all of that, except for one thing. (1)

EWAdams (953502) | about 5 years ago | (#29026721)

Where's my damn kitten?

Re:Still not fair. (0)

Anonymous Coward | about 5 years ago | (#29027001)

"" Thanks for using that tag, otherwise I might have missed it. ;)

Re:Still not fair. (3, Funny)

Runaway1956 (1322357) | about 5 years ago | (#29027481)

There's a kitten on every lap?

That damned kitten clawed my balls, you insensitive clod!

Re:Still not fair. (1)

thewils (463314) | about 5 years ago | (#29028007)

Hey, you must have read "Wildcat's revenge" by "Claude Balls" then?

Re:Still not fair. (0)

Anonymous Coward | about 5 years ago | (#29027659)

Have a cotton candy, drink your beer and turn on the TV. The shiny shiny is on again, you like that. You have always liked that.

What? shiny shiny, says who!? Only yesterday we were being told bling bling was in and we were at war with shiny shiny.

You're too late: (0)

Anonymous Coward | about 5 years ago | (#29026491)

to do anything.

Yours In Crime,
President-VICE Richard B. Cheney [whitehouse.org]

OWNED! (1)

OrangeMonkey11 (1553753) | about 5 years ago | (#29026499)

It goes to show people should listen to computer nerds(no disrespect by any means)warning a lot more often rather then brushed them off.

Old News (4, Informative)

megamerican (1073936) | about 5 years ago | (#29026803)

Or people can listen to a whistleblower [wikipedia.org] who programmed voting machines that easily allowed fraud [youtube.com] without a trace.

Easy way to fix this (0)

Anonymous Coward | about 5 years ago | (#29026509)

Each voter will be accompanied by a "voter sanctity" representative who will supervise the voting process to ensure no one powns a machine.

To ensure the sanctity of the "voter sanctity" reps, a Voter Sanctity Workers Union should be established to ensure the highest standards in voter sanctity.

If we were meant to vote, we'd get candidates (4, Funny)

David Gerard (12369) | about 5 years ago | (#29026527)

Americans today committed egregious acts of democracy [today.com] to elect the next failed administration and the next failed Congress.

In a fabulous upset, almost no-one could bring themselves to vote directly for either of the official candidates, instead opting for a write-in vote. Popular write-ins included "the black guy", "the old guy", "McCain from 2000" and "Tina Fey." The seventeen votes for "The Invisible Man" were tallied for Joe Biden. Several tons of Liquid Paper needed to be scraped off voting machines.

The winning candidate turned out to be Noneof Theabove, 46, of Dogshit, Nebraska. Apart from the Presidency, Mr Theabove won 72% of Congressional seats and all Senate seats up for election this year.

Mr Theabove's policies include drinking, shouting abuse at the television and inchoate existential despair. "He completely embodies the national mood," said Nate Silver of FiveThirtyEight.com, just before applying for a new job flipping burgers.

A majority of US soldiers in Afghanistan stated the place was "just fine, really" and they were learning to speak Pashto rather than returning. Canada looked south and snickered, though not very much as they still had Stephen Harper to cope with. The Kingdom of Mexico stated its "regret" today that it has had to close its borders to American refugees.

Show me the source, damnit. (1)

BlueKitties (1541613) | about 5 years ago | (#29026531)

If you want to prove how secure your systems are, then show us the damn source. Either they're afraid we'll see crap code that's obviously hard to maintain (see: crappy coders cost time, time costs money.) That, or they know it's not secure. Linux has completely open source, and it does fine with security.

Not a Bug (3, Funny)

the_macman (874383) | about 5 years ago | (#29026533)

deliver a complete working attack in a plug-in cartridge that could be used by anyone with a few private minutes with the machine.

It's not a bug! It's a feature!

Re:Not a Bug (0)

Anonymous Coward | about 5 years ago | (#29026973)

I can see the marketing meeting, "That kind of feature has to be worth a few million to some customer"

Re:Not a Bug (3, Informative)

Shakrai (717556) | about 5 years ago | (#29027123)

The only problem with this is that you aren't going to get a few "private minutes" with the machine and that any competent election authority is going to seal the machine with tamper-evident seals.

I've worked as an elections inspector (poll worker) in the state of New York for the last five years. Every aspect of the machine (both the old style lever machines and the new optical scanning machines) that could be tampered with is sealed with numbered tamper evident devices. If the numbers on the seals don't match up with the records retained by the Board of Elections then you know the machine has been tampered with. This isn't rocket science people.

Our new machines go even further than that. They both retain the actual ballots themselves in a locked ballot box and retain a scanned image of those ballots on a memory card. The memory card is removed from the machine at the end of the election and hand delivered to the Board of Elections. It is designed to serve as a backup in the event that the machine is destroyed (i.e: building burns down) and the ballots are lost. The ballots themselves are only scanned by the machine and not marked in any way. In the event of an issue with the machine there is nothing stopping you from counting each ballot by hand with the Mark I human eyeball.

If you can find a way to rig an election in the State of New York then I'd be real interested in knowing about it. I've worked behind the scenes here for a long time and I haven't seen any vulnerabilities in the system. The only voting technology that I'd be concerned about is DRE (direct electronic record) -- but thankfully my state wasn't stupid enough to go that route.

Re:Not a Bug (5, Informative)

Anonymous Coward | about 5 years ago | (#29027665)

From TFA:

"The attacker does not need to remove any tamper-evident seals; in particular, he does not need to remove the circuit-board cover."

(CAPTCHA: counted)

Re:Not a Bug (1, Insightful)

radtea (464814) | about 5 years ago | (#29027671)

It is designed to serve as a backup in the event that the machine is destroyed (i.e: building burns down) and the ballots are lost.

How often has that happened in the history of American elections?

That is exactly the kind of dramatic detail that puts my fraud-detector on alert. "Look, it's so secure that it's even secure against problems you don't have!" Typical distraction. It makes me wonder what you're hiding.

As it happens, if you google "ballots lost in fire" you get a bunch of hits on the first page about fraud and failure related to electronic voting machines.

Given the complete lack of transparency at all levels of any electronic voting system I am extremely suspicious of all of them. As we've seen in recent years, even machines that are secure at the local level do not necessarily produce accurate aggregate vote counts when the results are summed.

Re:Not a Bug (3, Interesting)

Shakrai (717556) | about 5 years ago | (#29028231)

It makes me wonder what you're hiding.

I have no incentive to hide anything as I'm not an employee of the Elections Board nor an office holder with a stake in the system. I became a poll worker because of the controversy surrounding this issue. I wanted to see for myself how the system worked. I came to it as a skeptic and after learning the procedures and seeing them in action have been convinced that the system is as secure as it can be expected to be.

How often has that happened in the history of American elections?

That is exactly the kind of dramatic detail that puts my fraud-detector on alert. "Look, it's so secure that it's even secure against problems you don't have!" Typical distraction.

So now you are complaining that the system is protected against disasters just because they rarely happen? Would you be happier with a system that left less of a paper trail?

As it happens, if you google "ballots lost in fire" you get a bunch of hits on the first page about fraud and failure related to electronic voting machines.

As I said, my experience is limited to the State of New York. In NYS we don't use direct electronic recording machines. You fill out a paper ballot that is then tabulated by an optical scanner. In the event of a disputed election the paper ballot is still around and any idiot can count it with the Mark I human eyeball.

The only part of our voting process that is "electronic" is the so-called "ballot marking device" that handicapped voters use. This is a machine that prints a paper ballot for those voters who are unable to write and have to rely on another interface (audio, sip and puff, foot pedals, etc.) The printed paper ballot is in the same format as the one that you would fill out as a non-handicapped voter and can be read by any human being.

Given the complete lack of transparency at all levels of any electronic voting system I am extremely suspicious of all of them

Evidently that's not all you are suspicious of, since you seem to think that I'm trying to hide something :)

Re:Not a Bug (5, Insightful)

HTH NE1 (675604) | about 5 years ago | (#29027733)

The only problem with this is that you aren't going to get a few "private minutes" with the machine

Surely that depends on the standards of voting privacy in your district, like whether you get a three-sided screen block or a complete booth with ceiling-to-floor curtains.

And an election can be thwarted by leaving evidence of tampering in a district you want to disenfranchise.

Re:Not a Bug (2, Informative)

Shakrai (717556) | about 5 years ago | (#29028377)

Surely that depends on the standards of voting privacy in your district, like whether you get a three-sided screen block or a complete booth with ceiling-to-floor curtains.

The voting booth is separate from the machine. The "voting booth" itself is nothing more than a plastic stand with a privacy screen and a supply of felt-tipped markers. The machine itself is in plain view of the election inspectors and everybody else who happens to be in the polling place. Trust me, you aren't going to be able to tamper with it without being caught during the election. After the election is another matter but that's why they have the backup memory card and myriad of seals on the machine.

And an election can be thwarted by leaving evidence of tampering in a district you want to disenfranchise.

If tampering is evident than the voting machine is going to receive closer scrutiny. The votes aren't automatically going to be discarded. If the "tampering" consists of removing the seals around the memory interface but not the ballot box and the number of ballots therein equals the number of signatures in the pool book then they are simply going to hand count the ballots (or scan them in a different machine). If the tampering consists of removing the seals around the ballot box then they will fall back on the aforementioned memory card that was removed after the election and returned to the Elections Board.

It's really not as easy to rig an election as people around here seem to think it is. I would encourage everybody who cares about this issue to volunteer to be a poll worker. The Election Boards are always looking for help and you'll get a chance to see the system from the inside. All it's going to cost you is a vacation day or two and some time. In some states you even get paid for doing it.

Re:Not a Bug (1)

UdoKeir (239957) | about 5 years ago | (#29028273)

If you can find a way to rig an election in the State of New York then I'd be real interested in knowing about it.

Put lots of voting machines in the rich, white neighbourhoods, and very few in the poor, black neighbourhoods. That's how they did it, at least, in Ohio in 2004.

Anyone got a mirror? (1)

Benanov (583592) | about 5 years ago | (#29026559)

Site is nearly unresponsive.

And it's just hosting a 3.1MB PDF...

Re:Anyone got a mirror? (0)

Anonymous Coward | about 5 years ago | (#29027129)

No, but I've got a hard drive here which I took the cover off, and the platter is really shiny, so...

Oh. Nevermind.

Re:Anyone got a mirror? (1)

amicusNYCL (1538833) | about 5 years ago | (#29027803)

I have the PDF. I hesitate to ask this, but, where can I put it?

Things like this will never change (5, Insightful)

Bandman (86149) | about 5 years ago | (#29026581)

Electronic bits do not have the quality of being static. Electronic votes can be changed without obvious physical evidence, and as long as they're purely electronic, it will always be like that.

Even an optical disk is more static than electronic bits that live in a database.

People need to demand paper ballots until electronic voting machines are all enhanced with built-in paper trails.

Re:Things like this will never change (1)

Andr T. (1006215) | about 5 years ago | (#29026687)

I think the most reasonable solution is an eletronic device that prints the vote so the user can cast it on a ballot. You can still count the votes in a fast way, but when any doubt is risen, you can double-check it with the paper votes.

Re:Things like this will never change (0)

Anonymous Coward | about 5 years ago | (#29027823)

But you do not need that many vote counters to get the result done within an hour of closing time. Do the math. You need around 0.1% of the voting population to be counters. It sounds like a lot, but retired folks are usually happy to do the training and the work in exchange for coffee and company, and for the feeling of doing something civic.

Re:Things like this will never change (1)

Andr T. (1006215) | about 5 years ago | (#29026701)

I just noticed I said the exact same thing you already said. Damn, sorry.

Re:Things like this will never change (1)

natehoy (1608657) | about 5 years ago | (#29026873)

Every voting machine SHOULD put out a paper trail, that the voter is able to see. Once you confirm your vote on-screen, it can spit out a paper receipt (punched card? Printout? Whatever) with your vote on it, and you go and put that vote into a locked box.

Ideally that receipt would have a serial number on it that matches the vote in the database, and the user gets an extra copy with their serial number and their vote, and can go look up their vote on the interwebs later using that serial number (the serial number is NOT associated with the voter, but gives a unique identification for each ballot cast). That way, voters get anonymity but can also confirm that their personal vote was accurately counted.

Then, if the electronic votes are tabulated and fraud is suspected, count the receipts.

And if a user sees that their registered vote is different, they have their own paper receipt to back up their personal claim of voter fraud or mistabulation. A sufficient number of proven user reports of fraud could trigger a paper-record recount.

Re:Things like this will never change (0, Offtopic)

rev_g33k_101 (886348) | about 5 years ago | (#29027261)

Your ideas intrigue me and I wish to subscribe to your newsletter.

Seriously

Re:Things like this will never change (0)

Anonymous Coward | about 5 years ago | (#29027345)

Not being able to prove that you cast a certain vote is an essential design requirement. Otherwise it becomes possible to coerce voters, because the "man with the gun" can request proof from his victim.

Re:Things like this will never change (3, Insightful)

omnichad (1198475) | about 5 years ago | (#29027407)

The printout should be made BEFORE you confirm the vote for the final time on-screen. You need to be able to confirm that the paper actually shows your correct vote.

Re:Things like this will never change (1)

natehoy (1608657) | about 5 years ago | (#29027597)

Yeah, that could work. I'm just thinking if you vote wrong and see it on-screen before hitting COMMIT, then you don't have to have a voting officer come over and destroy the printout in a verifiable manner (so you don't hit REPRINT 100 times and get multiple votes).

Then if the receipt is wrong, you can still go up to a voting officer and demand the right for a re-vote before you put your ballot into the confirmed box, and the officer can destroy the original, delete the vote from the database, give you a receipt that the vote has been deleted (that you sign), and give you a new vote on the machine.

Re:Things like this will never change (1)

HTH NE1 (675604) | about 5 years ago | (#29027965)

and the user gets an extra copy with their serial number and their vote, and can go

to the bar and get a free drink for voting a particular way.

If the user gets a receipt that includes the way they voted, the user can sell his vote.

If the way he voted is encoded in a way that is only evident through encryption, the user has to trust the encryption method to accurately record his vote. And then the system is exposed to false discredit if enough voters presenting their receipts lie about how they voted claiming the receipt is wrong.

Re:Things like this will never change (1)

natehoy (1608657) | about 5 years ago | (#29028475)

Hmmmm... good point. D'OH!

Re:Things like this will never change (1)

Seakip18 (1106315) | about 5 years ago | (#29027177)

There is a paper trail actually, if the damned county uses them. The problem though is that old folks running the precients barely understand the devices, so they don't bother with the additional hassle of a vote-by-vote trail and just settle for a total count printout.

Read one of my journals for when I worked for Dieb-errr....Premier Election Solutions last year. The best thing I like is a electronic tabulator which can deliver results fast as can be but still has a paper ballot. Touchscreen's should not be for anyone to use but the handicapped.

Re:Things like this will never change (1)

CastrTroy (595695) | about 5 years ago | (#29027613)

I very much agree. There's no point in having a paper trail if you can't get them to count it. They should be hand counting paper votes as the first and only option. If we've established any kind of doubt against the machine (and it seems we have) then there's no reason we should trust that number to begin with. You shouldn't have to order a recount to get a count you can trust. Recounts should be for extreme circumstances.

Re:Things like this will never change (3, Interesting)

Sandbags (964742) | about 5 years ago | (#29028365)

Yup. That's a good start.

I'd also love to see some kind of basic voter assessment to substantiate the vote as well. We all have a right to vote, but if yopur vote is based on fallicy or a complete lack of knowledge, you should not be allowed to register that vote.

My grandfather is a prime example of this. He's voted republican his entire life, nearly 70 years of going to the polls. I pointed out to him just before Obama's election that he couldn't, other than Right to Life and anti gun restriction, name a single Republican platform stance. Then i further asked him what his personal beliefs were on the top 25 debated items between the 2 parties. Of the 25 things, he chose the side the DEMOCRATS voiced support for. he didn't believe me, so i showed him the republican national website, and ran down the list (which took a while, it's not well organized). He voted straight democratic ticket. You see, the current Democratic platform is actually closer to what the Republicans had for a platform 50-60 years ago. He started voting replublican as a youth and then allways did, not paying ANY attention to the actual politics at stake. He figured about half his retired friends were doing the same thing...

If you can't name the candidate you're voting for, and at least 1 major platform stance out any 1 issue that candidate supports out of that candidates top 10 supported initiatives, you are not informed enough to effect MY future by registering your invalid votes. If you want to vote straight ticket, that's fine, name 3 platform stances of your party instead. If you can do that, you can vote, if not, either stay home, or only vote for the candidates you know something about. If uninformed people continue to vote, we'll need to bring voter certification back into play... (yes, I know it was used to discriminate in the past, but it would be VERY easy to ensure that did not happen in the future).

Green Screens (1)

realsilly (186931) | about 5 years ago | (#29026657)

So it if is so easy to hack a voter machine, why not make them all Dummy terminals?

Re:Green Screens (1)

natehoy (1608657) | about 5 years ago | (#29026951)

I think the terminals themselves are pretty hard to hack. There's not a lot going on at the individual voting stations. It's once you have access to the vote collection/tabulation machine that things get ugly. "A few minutes alone" with the machine should ideally be impossible - the machine should be put up on a pedestal in the middle of the floor with a barricade around it so anyone can see someone approaching the machine, and should not be touched by anyone until it's finished transmitting the votes to the central server.

In reality, it's usually tucked into a back room somewhere with a guard (or guards) around it, if that, but "who guards the guards?"

Honestly, once you have access to the hardware, it's pretty much all over. Even an IBM i can be hacked if you have access to the machine itself, and that's a pretty secure piece of technology.

Re:Green Screens (1)

Volante3192 (953645) | about 5 years ago | (#29027015)

We're one step ahead of you, we have dummy users.

Prediction: (2, Funny)

chickenrob (696532) | about 5 years ago | (#29026685)

The nations new electronic voting system helps Obama secure a landslide victory on his historic third term.

Re:Prediction: (1)

Lostlander (1219708) | about 5 years ago | (#29027667)

Well that would be illegal but /shrug that never stopped them before. The presidents these days think they can sign an executive order even if it is in conflict with the constitution.

Anyone else notice.. (0, Offtopic)

DigitalEntropy (146564) | about 5 years ago | (#29026703)

That "USENIX EVT" is an anagram for "UNISEX VET"?

Security through obscurity does not work! (1)

WiglyWorm (1139035) | about 5 years ago | (#29026775)

I really hope a politician of some sort with some tech savvy (mod funny lol) gets a hold of this and realizes that opensource is the way to go for voting machines.

With open source, diebold (or whomever) is still making money because someone needs to build the machines, and someone needs to manage the opensource project, but all those who are concerned about the integrety of the vote can contribute and find/fix exploits like this.

Re:Security through obscurity does not work! (1)

Attila Dimedici (1036002) | about 5 years ago | (#29026979)

I really hope a politician of some sort with some tech savvy (mod funny lol) gets a hold of this and realizes that opensource is the way to go for voting machines. With open source, diebold (or whomever) is still making money because someone needs to build the machines, and someone needs to manage the opensource project, but all those who are concerned about the integrety of the vote who can understand the programming language being used can contribute and find/fix exploits like this.

And everyone else will just have to take their word that it is OK.
Oh yeah, how will those people know that the "open source" code they contributed to is actually the code running on any voting machine other than the one nearest them (or even on that one)?

Re:Security through obscurity does not work! (1)

CastrTroy (595695) | about 5 years ago | (#29027715)

Exactly the point everyone seems to miss out on. It doesn't matter if the code is open source, because there is no way of verifying that the code running on all the machines is actually the code that's been vetted for. Sure you could probably get a team of computer scientists together to rip apart a single machine, and test all the components to ensure it's doing what it's supposed to, but it would be impossible to verify that all the machines were running the correct code on election day.

.PDF text (3, Informative)

guido1 (108876) | about 5 years ago | (#29026807)

Copy/paste, some formatting, no tables. Extra carriage returns (sorry)... "Implementing the gadgets" section stripped off...

Abstract
A secure voting machine design must withstand new attacks
devised throughout its multi-decade service lifetime.
In this paper, we give a case study of the longterm
security of a voting machine, the Sequoia AVC
Advantage, whose design dates back to the early 80s.
The AVC Advantage was designed with promising security
features: its software is stored entirely in read-only
memory and the hardware refuses to execute instructions
fetched from RAM. Nevertheless, we demonstrate that an
attacker can induce the AVC Advantage to misbehave
in arbitrary ways--including changing the outcome of
an election--by means of a memory cartridge containing
a specially-formatted payload. Our attack makes essential
use of a recently-invented exploitation technique
called return-oriented programming, adapted here to the
Z80 processor. In return-oriented programming, short
snippets of benign code already present in the system
are combined to yield malicious behavior. Our results
demonstrate the relevance of recent ideas from systems
security to voting machine research, and vice versa. We
had no access either to source code or documentation beyond
that available on Sequoia's web site. We have created
a complete vote-stealing demonstration exploit and
verified that it works correctly on the actual hardware.

1 Introduction
A secure voting machine design must withstand not only
the attacks known when it is created but also those invented
through the design's service lifetime. Because
the development, certification, and procurement cycle for
voting machines is unusually slow, the service lifetime
can be twenty or thirty years. It is unrealistic to hope
that any design, however good, will remain secure for so
long.1
In this paper, we give a case study of the long-term
security of a voting machine, the Sequoia AVC Advantage.
The hardware design of the AVC Advantage dates
back to the early 80s; recent variants, whose hardware
differs mainly in featuring a daughterboard enabling audio
voting for the blind [3], are still used in New Jersey,
Louisiana, and elsewhere. We study the 5.00D version
The AVC Advantage voting machine we studied.
(which does not include the daughterboard) in machines
decommissioned by Buncombe County, North Carolina,
and purchased by Andrew Appel through a government
auction site [2].
The AVC Advantage appears, in some respects, to offer
better security features than many of the other directrecording
electronic (DRE) voting machines that have
been studied in recent years. The hardware and software
were custom-designed and are specialized for use in a
DRE. The entire machine firmware (for version 5.00D)
fits on three 64kB EPROMs. The interface to voters
lacks the touchscreen and memory card reader common
in more recent designs. The software appears to contain
fewer memory errors, such as buffer overflows, than
some competing systems. Most interestingly, the AVC
Advantage motherboard contains circuitry disallowing
instruction fetches from RAM, making the AVC Advantage
a true Harvard-architecture machine.2
Nevertheless, we demonstrate that the AVC Advantage
can be induced to undertake arbitrary, attackerchosen
behavior by means of a memory cartridge containing
a specially-formatted payload. An attacker who
has access to the machine the night before an election can
use our techniques to affect the outcome of an election by
replacing the election program with another whose visible
behavior is nearly indistinguishable from the legitimate
program but that adds, removes, or changes votes
as the attacker wishes. Unlike those attacks described
1
in the (contemporaneous, independent) study by Appel
et al. [3, 4] that allow arbitrary computation to be induced,
our attack does not require replacing the system
ROMs or processor and does not rely on the presence of
the daughterboard added in later revisions.
Our attack makes essential use of return-oriented programming
[24, 8], an exploitation technique that allows
an attacker who controls the stack to combine short instruction
sequences already present in the system ROM
into a Turing-complete set of combinators (called "gadgets"),
from which he can synthesize any desired behavior.
(Our exploit gains control of the stack by means of
a buffer overflow in the AVC Advantage's processing of
a type of auxiliary cartridge; see Section 5.) Defenses
that prevent code injection, such as the AVC Advantage's
instruction-fetch hardware, are ineffective against
return-oriented programming, since it allows an attacker
to induce malicious behavior using only preëxisting, benign
code. Return-oriented programming was introduced
by Shacham at CCS 2007 [24], a full two decades after
the AVC Advantage was designed. Originally believed
to apply only to the x86, return-oriented programming
was generalized to the SPARC, a RISC architecture, by
Buchanan et al. [8]. In Section 4 we show that returnoriented
programming is feasible on the Z80 as well,
which may be of independent interest. In addition, we
show that it is possible starting with a corpus of code an
order of magnitude smaller than previous work.
Using return-oriented programming, we have developed
a full demonstration exploit for the AVC Advantage,
by which an attacker can divert any desired fraction
of votes from one candidate to another. We have
tested that this exploit works on the actual hardware; but
in developing our exploit we used a simulator for the machine.
See Sections 5 and 6 for more on the exploit and
Section 2 for more on the simulator.
Our results demonstrate the relevance of recent ideas
from systems security to voting machine research, and
vice versa. Our attack on the AVC Advantage would
have been impossible without return-oriented programming.
Conversely, the AVC Advantage provides an ideal
test case for return-oriented programming. In contrast to
Linux, Windows, and other desktop operating systems,
in which the classification of a process' memory into
executable and nonexecutable regions can be changed
through system calls, the AVC Advantage is a true Harvard
architecture: ROM is executable, RAM is nonexecutable.
3 The corpus of benign instruction on which we
draw is just 16kB, an order of magnitude smaller than in
previous attacks.
In designing our attack, we had access neither to
source code nor to usage documentation; through reverse
engineering of the hardware and software, we have reconstructed
the functioning of the device. This is in contrast
to the Appel et al. report, whose authors did have
this access, as well as to most of the previous studies of
voting machines (discussed in Section 1.1 below). We
had access to an AVC Advantage legitimately purchased
from a government surplus site by Andrew Appel [2]
and a memory cartridge similarly obtained by Daniel Lopresti.
Since voting machines are frequently left unattended
(as Ed Felten has documented, e.g., at [12]), we
believe that ours represents a realistic attack scenario.
We hope that our results go some way towards answering
the objection, frequently raised by vendors, that voting
security researchers enjoy unrealistic access to the systems
they study.4
1.1 Related work
Much of the prior research on voting machine security
has relied on access to source code. The first such work
by Kohno et al. [18] analyzed the Diebold5 AccuVote-
TS voting machine and found numerous problems. The
authors had no access to the voting machine itself but the
source code had appeared on the Internet. Many of the
issues identified were independently confirmed with real
voting machines [9, 21, 22].
Follow up work by Hursti examined the AccuVote-
TS6 and AccuVote-TSx voting machines using "source
code excerpts" and by testing the actual machines. Backdoors
were found that allowed the system to be extensively
modified [17]. Hursti's attacks were confirmed
and additional security flaws were discovered by Wagner
et al. [27].
In 2006, building on the previous work, Feldman et al.
examined an AccuVote-TS they obtained. The authors
did not have the source code, but they note that "the behavior
of [the] machine conformed almost exactly to the
behavior specified by the source code to BallotStation
version 4.3.1" which was examined by Kohno et al. In
addition to confirming some of the security flaws found
in the previous works, they demonstrated vote stealing
software and a voting machine virus that spreads via the
memory cards used to load the ballot definition files and
collect election results [11].
In 2007, California Secretary of State Debra Bowen
decertified and then conditionally recertified the direct
recording electronic voting machines used in California
as part of a top-to-bottom review. As part of the recertification,
voting machine vendors were required to
make available to independent reviewers documentation,
source code, and several voting machines. In all cases,
significant problems were reported with the procedures,
code, and hardware reviewed [6].
Also in 2007, Ohio Secretary of State Jennifer Brunner
ordered project EVEREST--Evaluation and Validation
of Election Related Equipment, Standards and Testing--
as a comprehensive review of Ohio's electronic voting
2
machines. Similar to California's top-to-bottom review,
the reviewers had access to voting machines and source
code. Again, critical security flaws were discovered [7].
2 The road to exploitation
In 1997, Buncombe County, North Carolina, purchased
a number of AVC Advantage electronic voting machines
for $5200 each. In January 2007, they retired these machines
and auctioned them off through a governmentsurplus
web site. Andrew Appel purchased one lot of
five machines for $82 in total [2].
Reverse-engineering the voting machine. Two members
of our team immediately began reverse engineering
the hardware and software. The machine we examined
is an AVC Advantage revision D. It contains ten circuit
boards, including the motherboard shown in Figure
1, with an eleventh inside the removable memory
cartridge--see below. Each is an ordinary two-sided
epoxy-glass type. Since these are somewhat translucent,
with the use of a bright light, magnifying glass, lowvoltage
continuity tester, and data sheets for the components,
we were able to trace and reconstruct the circuit
schematic diagram, and from that deduce how the unit
worked. We filled in remaining details by partially disassembling
the machine's software using IDA Pro.
After approximately six man-weeks of labor, we produced
a functional specification [14] describing the operation
of the hardware from the perspective of software
running on the machine. We documented 47 I/O functions
that the processor can execute to control hardware
functions, such as mapping areas of ROM into the address
space, interfacing with the voter panel and operator controls,
and reading or writing to the memory cartridge.
Reverse-engineering the results cartridge. The AVC
results cartridge is a plastic box about the dimensions of
a paperback book with a common "ribbon-style" connector
on one end that mates to the voting machine. Inside,
there is an ordinary circuit board containing static RAM
chips--backed by two type AA batteries--and common
TTL 74-series integrated circuits. There is no microcontroller;
instead all control signals come directly from the
voting machine. Much of the internal circuitry appears
to have been designed to withstand hot-plugging and to
prevent accidental glitching of the memory contents.
There is an additional 8bit of nonmemory data that
can be read from the unit corresponding to the type and
revision of the memory cartridge. This data is set by etch
jumpers on the circuit board. We were able to change
the type and revision of the cartridge by cutting the associated
trace on the circuit card and wiring alternate
jumpers.
The contents of memory can be read or written by
powering the device and toggling the appropriate input
signals. We constructed a simple microcontroller circuit
to interface with the cartridge to perform reads and
writes. The microcontroller simply controls the appropriate
signals on the cartridge connector to perform the
operation indicated by a controlling program communicating
with the microcontroller via a serial port. No access
to the inside circuitry was necessary.
By disassembling the software and looking at the contents
of a valid results cartridge, we were able to understand
the format of the file system used on the memory
cartridges (and also the internal file system of the 128kB
SRAM described below) and many of the files used by
the voting machine.
Crafting the exploit. Joshua Herbach used the hardware
functional specifications to develop a simulator for
the machine [15], which another member of our team
subsequently improved.6 Our simulator now provides
cycle-accurate emulation of the Z80, and it executes the
AVC election software without any apparent flaws.
We developed our exploit almost entirely in the simulator,
only returning to the actual voting machine hardware
at the end to validate it. Remarkably, the exploit
worked the first time we tried it on the real hardware.
Total cost. Starting with no source code or schematics,
we reverse engineered the AVC Advantage and developed
a working vote-stealing attack with less than 16
man-months of labor. We estimate the cost of duplicating
our effort to be about $100,000, on the private market.
3 Description of the AVC Advantage
In this section, we give a description of the hardware and
software that makes up the AVC Advantage in some detail.
Readers not interested in such low-level details are
encouraged to skip ahead to Section 4, referring back to
this section for details as needed.
3.1 Software
The core of the version-5.00D AVC Advantage is a
Z80 CPU and three 64kB erasable, programmable ROMs
(EPROMs) which contain both code and data for the Advantage.
Each EPROM is divided into four 16kB segments:
BIOS, System Toolkit, Toolkit 2, Toolkit 3, Election
Program, Election Toolkit, Reports Program, Consolidation
Program, Ballot Verify Program, Define Ballot
Program, Maintenance Utilities, and Setup Diagnostics;
see Figure 2.
When the Advantage is powered on, execution begins
in the BIOS at address 0x0000. The BIOS contains a
mixture of hand-coded assembly and compiler generated
code for interrupt handling, remapping parts of the address
space (see Section 3.2), function call prologues and
epilogues, thunks for calling code in other segments, and
code for interacting with the peripherals.
3
Figure 1: We reverse engineered the AVC Advantage hardware. The motherboard, shown here, is composed mostly of
discrete logic and measures 14in14in. Election software is stored in removable ROM chips (white labels). The results and
auxiliary memory cartridges are plugged directly into the motherboard (upper right).
Apart from the BIOS, each EPROM segment contains a
16B header followed by a mixture of (mostly) compilergenerated
code and data. The segments with "Toolkit"
in their name7 in addition to the Reports Program consist
of the header followed immediately by a sequence of
jp addr instructions, each of which jumps to a global
function in the segment. For the entries in this sequence
corresponding to global functions, there is a corresponding
thunk in the BIOS which causes the segment to be
mapped into the address space before transferring control
to the function. Functions in one segment can call global
functions in another segment by way of the thunks.
Each of the remaining segments is a self-contained
program with just a single entry point immediately after
the segment header. When a program is run, much of
the state of the previous program--including the stack
and the heap--is reset. In particular, any data written to
the stack during one program's execution are lost during
a second program's execution.
A typical sequence of events for an election would
include the following. The machine is powered on and
begins executing in the BIOS. The BIOS performs some
initialization and tests before transitioning to a menu in
Maintenance Utilities awaiting operator input. The operator
selects the Setup Diagnostics choice and the corresponding
Setup Diagnostics program is run. This performs
various software and hardware tests before transitioning
to the Define Ballot Program. This program
checks the memory cartridge inserted into the machine
and upon finding a ballot definition transitions to the Ballot
Verify Program. The Ballot Verify Program checks
that the format of the ballot is correct and ensures that
the files which hold the vote counts are empty. After
this, it illuminates the races and candidates so that the
technician can verify that they are correct. Assuming everything
is correct, control transfers to the Election Program
for the pre-election logic and accuracy testing. The
voting machine is powered off at this point and shipped
to the polling places. After it has been powered back on,
control again passes to the Election Program, this time
for the official election.
The ZiLOG Z80 CPU is an 8bit accumulator machine.
All 8bit arithmetic and logical operations use the accumulator
register a as a source register and the destination
register. Apart from the accumulator register, there are
six general purpose 8bit registers b, c, d, e, h, and l
which can be paired to form three 16bit registers bc, de,
and hl. These registers along with an 8bit flags regis-
ter f and 16bit stack pointer sp and program counter pc
registers are compatible with the Intel 8080. In addition,
there are two 16bit index registers ix and iy, an interrupt
vector register i, a DRAM refresh counter register r,
and four shadow registers af', bc', de', and hl' which
can be swapped with the corresponding nonshadow registers.
The Advantage uses the shadow registers for the
interrupt handler which obviates the need to save and restore
state in the interrupt handler. See [28] for more
details.
Due to the limited ROM space for code and data,
compiler-generated functions which take arguments or
have local variables use additional functions to implement
the function prologue and epilogue. The prologue
pushes the iy and ix registers and decrements the stack
pointer to reserve room for local variables. It then sets
iy to point to the first argument and ix-80h to point
to the bottom of the local stack space. Finally, it pushes
the stack-address of the two saved index registers and the
address of the epilogue function before jumping back to
the function that called the prologue. See Figure 3. The
epilogue function pops the saved pointer to the index registers
and loads sp with it. Then ix and iy are popped
and the epilogue returns to the original saved pc. It is the
caller's responsibility to pop the arguments off the stack
once the callee has returned.
3.2 Address space layout
The AVC Advantage has a 16bit flat address space divided
into four distinct regions. The bottom 16kB
is mapped to the BIOS. The 16kB-32kB range can
be mapped to one of the 12 16kB aligned segments
on the three program EPROMs. This mapping is controlled
by the software using the Z80's out instruction.
The 32kB-63kB range addresses the bottom 31kB of a
32kB, battery-backed SRAM. Finally, the top 1kB of the
address space can be mapped to either the top 1kB of
the 32kB SRAM or it can be mapped to any 1kB aligned
region of a 128kB, battery-backed SRAM. This mapping
can be changed by the software using the Z80's out instruction.
For more detail, see [14].
The AVC Advantage's stack starts at address 0x8FFE
and grows down toward smaller addresses. The heap occupies
a region of memory starting from an address specified
by the currently active program to 0xEBFF. Scattered
throughout the rest of 32kB main memory, there
are various global variables and space for the string table
of the active program. In addition, starting at 0x934E
and growing down, there is space for a module call stack
which allows modules to make calls to functions in other
modules, such as printf or strcpy. See Figure 4.
As the lower 32kB of the address space corresponds
to EPROMs, data cannot be written to those addresses
and attempts to do so are silently ignored by the hard-
ware.8 Similarly, as the upper 32kB of the address space
is for writable memory, not program code, any attempt
to fetch an instruction from those addresses raises a nonmaskable
interrupt (NMI). The NMI causes the processor
to load a known constant into the pc register and execution
resumes in the BIOS where the processor will be
halted after displaying an error message on the operator
LCD. This design makes the AVC Advantage a Harvardarchitecture
computer.
4 Return-oriented programming
Since the AVC Advantage is a Harvard architecture computer,
traditional code injection attacks cannot succeed
because any attempt to read an instruction from data
memory causes an NMI which will halt the machine. In
practice, given a large enough corpus of code, this is
not a barrier to executing arbitrary code using returnoriented
programming--an extension of return-to-libc
attacks where the attacker supplies a malicious stack containing
pointers to short instruction sequences ending
with a ret [24, 8].
The Z80 instruction set is very dense. Every byte is
either a valid opcode or is a prefix byte. As there are no
invalid or privileged instructions, instruction decoding of
any sequence of data always succeeds. This density facilitates
return-oriented programming since we can exploit
unintended instruction sequences to build gadgets--a
sequence of pointers to instruction sequences ending
with a ret. For a concrete example, the BIOS contains
the code fragment ld bc,2; ret--a potentially useful
instruction sequence in its own right--which is 01
02 00 c9 in hex where the first three bytes are the
load and the last is the return. If we set the program
counter one byte into the load instruction, then we get the
instruction sequence 02 00 c9 corresponding to the
three instructions ld (bc),a; nop; ret which stores
the value of the accumulator into memory at the address
pointed to by the register bc.
Shacham [24] and later Buchanan et al. [8] had code
corpora on the order of a megabyte from which to construct
gadgets. In contrast, Francillon and Castelluccia
[13] had only 1978B of code with which to craft gadgets;
however, they did not construct a Turing-complete
set of gadgets. This prompts the question: What is the
minimal amount of code required to construct a Turingcomplete
set of gadgets? By constructing a Turingcomplete
set of gadgets using only the AVC Advantage's
BIOS--which consists of 16kB of code and data--we
make progress toward answering that question.
Following Shacham, we wrote a small program to
find sequences of instructions ending in ret. We ran
this program on the AVC Advantage's BIOS. We then
manually devised a Turing-complete set of gadgets from
the instruction sequences found by our program, including
gadgets to control the peripherals like the LCDs
and memory cartridges. We build a collection of gadgets
that implement a 16bit memory-to-memory pseudoassembly
language. See Table 1 for a description of the
pseudo-assembly language and Appendix A for the implementation
of many of the gadgets and a precise explanation
of the notation that will be used in the remainder
of the paper.
(We stress that demonstrating return-oriented programming
on the Z80 is a major contribution of this paper
and of independent interest; we have moved the details to
an appendix to improve the paper's flow.)
Some of the gadgets in Table 1 are straightforward to
construct; others require more finesse due to tricky interactions
among the registers used in the instruction sequences.
For ease of implementation, no state is presumed
to be preserved between gadgets. That is, all arguments
are loaded from memory into registers, operated
upon, and then stored back into memory.9 In this way,
each gadget can be reasoned about independently. The
operands to the gadgets are either global variables--declared
with the .var directive--or immediate values;
labels are resolved to offsets and thus are immediate values.
Some of the instruction sequences described in Appendix
A contain NUL bytes which make them unsuitable
for use in stack smashing attacks using a string copy. An
early implementation of the gadgets took great pains to
avoid all zero bytes. However, using the multi-stage exploit
described below, avoiding zero bytes was unnecessary
except for in the first stage of the exploit which did
not use the gadgets presented in this section. As such,
the simpler form of the gadgets is presented.
It has become traditional in papers on return-oriented
programming to show a sorting algorithm implemented
as a return-oriented program [8, 16]. In Appendix B, we
give the listing for a return-oriented Quicksort. We have
verified that this sorting algorithm works on the actual
AVC Advantage as part of a larger program that prints a
list of numbers on the printer, sorts them, and prints the
sorted list.
5 A multi-stage exploit for the AVC Advantage
Even though many parts of the code we reverse engineered
appear to handle data from memory cartridges
safely, we have been able to find a stack buffer overflow
vulnerability. In this section, we describe this vulnerability
and discuss how an attacker can exploit it to overwrite
the AVC Advantage's stack and reliably induce the execution
of a return-oriented payload of his choice.
We stress that the buffer overflow that we have identified
appears to be unrelated to the one identified by Appel
et al. in their report [3, Section II.26]. Our buffer overflow
occurs in cartridge processing whereas Appel et al.'s
occurs in interaction with the daughterboard (which the
machine we studied lacks); our overflow requires manual
action, whereas Appel et al.'s is triggered on boot; our
overflow is exploitable for diverting the machine's control
flow, whereas Appel et al.'s appears to allow only a
denial of service. We do not know whether the overflow
that we found persists in the more recent AVC Advantage
version that Appel et al. examined.
One of the programs not normally used in an election,
but accessible from the main menu, contains a buffer
overflow while reading from an auxiliary cartridge of a
certain type. (As described in Section 2, we physically
modified a results cartridge so that the AVC Advantage
would recognize it as a cartridge of the type for which the
appropriate menu item is enabled.) A maliciously crafted
field in one of the files allows roughly a dozen bytes to
be written at the location of the saved stack pointer. In
the first stage of the exploit, the hl register is set and
the stack pointer is modified using the sp hl instruction
sequence, inducing a return-oriented jump to
an attacker-controlled location in memory.
For stage two, a section of memory under attacker control
needs to contain gadgets. Fortunately (for the attacker),
a file of fixed size but with several dozen unused
bytes is read from the memory cartridge into a buffer allocated
by malloc. By the time of the overflow in stage
7
Figure 5: The machine has slots for two memory cartridges.
The first cartridge stores ballots and votes. An
attacker could install vote sealing code by inserting a prepared
cartridge into the second slot.
one, this buffer has been deallocated but most of its contents
remain in memory at a known location. This unused
space can be changed to contain gadgets that make up
the second stage of the exploit. The first thing that stage
two does is reallocate memory for the buffer so that additional
allocations will not overlap and thus write over
the gadgets. At the same time, enough memory is allocated
to hold the contents of an additional file from the
memory cartridge. The data from this file--stage three
of the exploit--is read into the allocated buffer. Control
then transfers to stage three which can perform arbitrary
code execution using the gadgets described in Section 4.
We have tested on an AVC Advantage that the exploit
procedure described in this section works, using it both to
run the sorting program described in the previous section
and the vote-stealing exploit described in the next.
6 Using the exploit to steal votes
We have designed and implemented a demonstration
vote-stealing exploit for the AVC Advantage, using the
vulnerability described in the previous section to take
over the machine's control flow. We have tested that our
exploit works on the actual AVC Advantage. (Although
it was designed and debugged exclusively in our simulator,
the exploit worked on the real hardware on the first
try.) In this section, we describe both the actions that an
attacker will undertake to introduce the exploit payload
to the machine and the behavior of the payload itself.
We also note several ways in which the exploit could be
made more resistant to detection by means of forensic
investigation.
Our attacker accesses the AVC Advantage when it is
left unattended the night before the election. Ed Felten
has described how such access is often possible (see, e.g.,
[12]). At this point, the machine has been loaded with
an election definition and has passed pre-LAT.10 The attacker
picks the locks for the back cabinet, the voter
panel, and (later) the open/close polls switch. Appel et al.
have shown that these locks are of a low-security kind
that is easily bypassed [3, Section I.9]. The attacker does
not need to remove any tamper-evident seals; in particular,
he does not need to remove the circuit-board cover.
Having gained access to the back cabinet of the AVC
Advantage, the attacker uses the normal functions to
open the polls, cast a single vote, and close the polls.
(The polls cannot be closed with no votes cast.11) Once
the polls are closed, the attacker unseats the results cartridge.
The cartridge cannot be removed completely because
of the tamper-evident seal; however, the seal is
small enough compared to the holes through which it
is inserted that the cartridge can be disconnected from
the machine. With the polls closed and the cartridge
removed, the attacker uses the two-key reset gesture
("print-more" and "test") to gain access to the machine's
post-election menu. From this menu, he can reset the machine;
after the reset, the machine's main menu is accessible.
(Were the results cartridge not removed, the data
on it would be erased by the reset. The attacker might
be able to recreate this data and rewrite it to the results
cartridge, but unseating the cartridge before the reset obviates
this.)
To this point, the attacker is simply following the same
procedures poll workers and election officials use in running
an election and resetting the AVC Advantage for
the next election. His goal is to gain access to the main
menu, from which he can direct the machine toward the
vulnerability described in Section 5.
The system reset appears to clear the audit logs on the
machine. Our demonstration vote-stealing exploit does
not undo this log-clearing, though a more stealthy attack
might wish to; otherwise, a post-election audit might discover
that log entries are missing. (Although, as Davtyan
et al. have found in their audit of the AccuVote AV-OS
system [10], discrepancies in logs are not uncommon and
may not be perceived as signs of an attack.) Even if
the attack is detected, the original voter intent will not
be recoverable. The attacker can use the post-election
menu to dump the contents of the logs either to a trans-

fer cartridge or to the printer and cause his exploit payload
to restore them once the system is compromised.
In addition, since a vote was cast, the protective counter
has been incremented; however, the protective counter
is subject to software manipulation and could easily be
rolled back if the attacker desires. Traces of the phantom
vote might also remain in the machine or operator logs; if
so, a stealthy exploit would have to remove these traces.
The attacker now reinserts the results cartridge and a
cartridge of the appropriate type into the auxiliary port
and navigates the menus to trigger the vulnerability described
in Section 5. Using a three-stage exploit as described
in Section 5, he takes control of the AVC Advantage
and can execute arbitrary (return-oriented) code.
Note that hardware miniaturization since the design
of the AVC Advantage makes possible the creation of
cartridges much smaller than legitimate cartridges with
orders of magnitude more storage. (Different parts of
memory could be paged in using a "secret knock" protocol.)
A smaller cartridge may allow the attacker to bypass
tamper-evident loops placed on the auxiliary port
guide rails that would prevent the insertion of a legitimate
cartridge (although we are not aware of a jurisdiction
that attempts to limit access to the auxiliary port in
this way); it may also allow him to leave an auxiliary
cartridge in place during voting while avoiding detection,
which would be useful for exploit payloads larger
than can fit in main memory and unused portions of the
results cartridge. (As noted below, our exploit payload
easily fits in main memory.)
The exploit first restores those parts of the machine's
state necessary to allow the election to begin again.
It copies the results cartridge's post-LAT voting files
(which are in their empty state) over the results cartridge's
election files so that the single ballot that was
cast in order to close the polls is erased. It then copies
(most of) the contents of the results cartridge into the internal
memory. At this point, a message is displayed on
the operator LCD instructing the attacker to remove the
auxiliary cartridge and turn off the power.
In order to convincingly simulate power off, we need
the power switch to be in the off position. Luckily, the
AVC Advantage has a soft power switch, so turning the
power knob just sets a flag that can be polled by the processor
at interrupt time to detect power off. So long as the
exploit code disables interrupts (while petting the watchdog
timer to keep it from firing) it can keep the machine
running; it can also detect when, later, the power switch
is turned to the on position. (By contrast, were the machine
actually to power down, the stack would be reset on
a subsequent power up and the attacker would lose control.)
The AVC Advantage features a large 110V battery
designed for 16 hours of operation that we believe will
allow it to remain overnight in this state [23]. Of all the
steps in our exploit, this is the one that most intimately
relies on the details of the AVC Advantage's hardware
implementation. We emphasize that we have tested on
the actual machine that our exploit code is able to survive
a power-down/power-up cycle in this way on battery
power alone.
When the exploit code detects that the power switch
has been turned to the off position, it simulates power
down. It turns off the LEDs in the voter panel, clears the
LCD displays, and turns off any status LEDs. In testing
on an AVC Advantage, we have been able to disable (via
return-oriented code) all indicators of power except the
LCD backlight on the operator panel. This is the most
visible sign of our attack; we are currently studying how
the backlight might be disabled.
The attacker now closes and locks the operator and
voter panels, removes the auxiliary cartridge, and leaves.
The next morning, poll workers open the machine and
use the power switch to turn it on. The exploit code
detects the change and simulates the machine's powerup
behavior, followed by the official election mode messages.
The exploit must now simulate the machine's normal
behavior when poll workers open and close the polls and
when voters cast votes. While it would be possible to
reimplement this behavior entirely using return-oriented
code, the design of the AVC Advantage's voting program
makes it possible for us to reuse large portions of the legitimate
code, making the exploit smaller, simpler, and
more robust. This would be more difficult to do if the
exploit modified votes as they were cast, but we have
instead chosen to wait until polls are closed and only
then change the cast votes retroactively. The absence of
a paper audit trail means that the vote modification will
not be detected. Other possible designs for vote-stealing
software are described by Appel et al. [3, Section I.5-6].
The main voting function is structured as a series
of function calls that can be separated into three main
groups, each called a single time in order in the normal
case. The first group of functions waits for the "open/-
close polls" switch to be set to open and prints the zero
tape. The second group of functions handles all of the
voting, including waiting for the activate button to be
pressed and handling all voter input. Once the polls are
closed, the third group of functions handles printing the
final results tape and all post-election tasks.
Our demonstration exploit uses the high-level functions
in the AVC Advantage's legitimate voting program
to handle all voting until the polls are closed. Then the
exploit reads the vote totals, moves half of the votes for
the second candidate to the first candidate, and changes
the cast vote records (CVRs) to match the vote totals.
(Obviously, any fraction of the votes could be modified.
Furthermore, while our exploit processes the CVR log in
order, changing every CVR cast for the disfavored candidate
until the desired shift has been effected, more sophisticated
strategies are possible.) The exploit now relinquishes
control for good, handing control over to the
legitimate AVC Advantage program to handle all postelection
behavior. When the "Official Election Results
Report" is printed it will reflect the results as modified
by the exploit.
The AVC Advantage contains routines to check the
consistency of its internal data structures. When the data
is inconsistent, e.g., the vote totals do not match the CVR
totals, this is noted in the Results Report. The exploit ensures
that all data structures in memory and on the results
cartridge that are checked by these routines are consistent
whenever the routines are executed.
Even after it has relinquished control, our exploit remains
in main memory until the machine is shut down.
Forensic analysis of the contents of the AVC Advantage's
RAM would be a nontrivial task; nevertheless, a stealthier
exploit would wipe itself from memory before returning
control to the legitimate program. If any portion of the
exploit code is stored on a cartridge, this must be wiped
as well. Because suspicious poll workers might remove
the cartridge before it can be wiped, anything stored on a
cartridge should be kept encrypted, and the exploit code
should scrub the key from RAM if it detects that the cartridge
has been removed.
Our vote-stealing demonstration exploit is just over
3:2kB in size, including all of the code to copy the files
and the memory cart. It fits entirely in RAM, as would
even a substantially more sophisticated exploit: There is
roughly an additional 10kB of unused heap space that
could be used. In addition, any code that is executed
only while the attacker is present need not actually stay
in the heap once it is finished and could be replaced with
additional code for modifying the election outcome.
7 Conclusions
A secure voting machine design must withstand attacks
devised throughout the machine's service lifetime. Can
real designs, even ones with promising security features,
provide such long-term security? In this paper, we have
answered this question in the negative in the case of
the Sequoia AVC Advantage (version 5.00D). We have
demonstrated that an attacker can exploit vulnerabilities
in the AVC Advantage software to install vote-stealing
malware by using a maliciously-formatted memory cartridge,
without replacing the system ROMs. Starting with
no source code, schematics, or nonpublic documentation,
we reverse engineered the AVC Advantage and developed
a working vote-stealing attack with less than 16
man-months of labor. Our exploit relies in a fundamental
way on return-oriented programming, a technique introduced
some two decades after the AVC Advantage
was designed. In mounting the attack, we have extended
return-oriented programming to the Z80 processor.

Re:.PDF text (4, Informative)

Anonymous Coward | about 5 years ago | (#29027641)

Here it is without the IDIOTIC carriage returns. Yes, you are an IDIOT, guido-cock.
 
  Abstract
  A secure voting machine design must withstand new attacks devised throughout its multi-decade service lifetime. In this paper, we give a case study of the longterm security of a voting machine, the Sequoia AVC Advantage, whose design dates back to the early 80s. The AVC Advantage was designed with promising security features: its software is stored entirely in read-only memory and the hardware refuses to execute instructions fetched from RAM. Nevertheless, we demonstrate that an attacker can induce the AVC Advantage to misbehave in arbitrary ways--including changing the outcome of an election--by means of a memory cartridge containing a specially-formatted payload. Our attack makes essential use of a recently-invented exploitation technique called return-oriented programming, adapted here to the Z80 processor. In return-oriented programming, short snippets of benign code already present in the system are combined to yield malicious behavior. Our results demonstrate the relevance of recent ideas from systems security to voting machine research, and vice versa. We had no access either to source code or documentation beyond that available on Sequoia's web site. We have created a complete vote-stealing demonstration exploit and verified that it works correctly on the actual hardware.
 
  1 Introduction
  A secure voting machine design must withstand not only the attacks known when it is created but also those invented through the design's service lifetime. Because the development, certification, and procurement cycle for voting machines is unusually slow, the service lifetime can be twenty or thirty years. It is unrealistic to hope that any design, however good, will remain secure for so long.1 In this paper, we give a case study of the long-term security of a voting machine, the Sequoia AVC Advantage. The hardware design of the AVC Advantage dates back to the early 80s; recent variants, whose hardware differs mainly in featuring a daughterboard enabling audio voting for the blind [3], are still used in New Jersey, Louisiana, and elsewhere. We study the 5.00D version The AVC Advantage voting machine we studied. (which does not include the daughterboard) in machines decommissioned by Buncombe County, North Carolina, and purchased by Andrew Appel through a government auction site [2]. The AVC Advantage appears, in some respects, to offer better security features than many of the other directrecording electronic (DRE) voting machines that have been studied in recent years. The hardware and software were custom-designed and are specialized for use in a DRE. The entire machine firmware (for version 5.00D) fits on three 64kB EPROMs. The interface to voters lacks the touchscreen and memory card reader common in more recent designs. The software appears to contain fewer memory errors, such as buffer overflows, than some competing systems. Most interestingly, the AVC Advantage motherboard contains circuitry disallowing instruction fetches from RAM, making the AVC Advantage a true Harvard-architecture machine.2 Nevertheless, we demonstrate that the AVC Advantage can be induced to undertake arbitrary, attackerchosen behavior by means of a memory cartridge containing a specially-formatted payload. An attacker who has access to the machine the night before an election can use our techniques to affect the outcome of an election by replacing the election program with another whose visible behavior is nearly indistinguishable from the legitimate program but that adds, removes, or changes votes as the attacker wishes. Unlike those attacks described 1 in the (contemporaneous, independent) study by Appel et al. [3, 4] that allow arbitrary computation to be induced, our attack does not require replacing the system ROMs or processor and does not rely on the presence of the daughterboard added in later revisions. Our attack makes essential use of return-oriented programming [24, 8], an exploitation technique that allows an attacker who controls the stack to combine short instruction sequences already present in the system ROM into a Turing-complete set of combinators (called "gadgets"), from which he can synthesize any desired behavior. (Our exploit gains control of the stack by means of a buffer overflow in the AVC Advantage's processing of a type of auxiliary cartridge; see Section 5.) Defenses that prevent code injection, such as the AVC Advantage's instruction-fetch hardware, are ineffective against return-oriented programming, since it allows an attacker to induce malicious behavior using only preëxisting, benign code. Return-oriented programming was introduced by Shacham at CCS 2007 [24], a full two decades after the AVC Advantage was designed. Originally believed to apply only to the x86, return-oriented programming was generalized to the SPARC, a RISC architecture, by Buchanan et al. [8]. In Section 4 we show that returnoriented programming is feasible on the Z80 as well, which may be of independent interest. In addition, we show that it is possible starting with a corpus of code an order of magnitude smaller than previous work. Using return-oriented programming, we have developed a full demonstration exploit for the AVC Advantage, by which an attacker can divert any desired fraction of votes from one candidate to another. We have tested that this exploit works on the actual hardware; but in developing our exploit we used a simulator for the machine. See Sections 5 and 6 for more on the exploit and Section 2 for more on the simulator. Our results demonstrate the relevance of recent ideas from systems security to voting machine research, and vice versa. Our attack on the AVC Advantage would have been impossible without return-oriented programming. Conversely, the AVC Advantage provides an ideal test case for return-oriented programming. In contrast to Linux, Windows, and other desktop operating systems, in which the classification of a process' memory into executable and nonexecutable regions can be changed through system calls, the AVC Advantage is a true Harvard architecture: ROM is executable, RAM is nonexecutable. 3 The corpus of benign instruction on which we draw is just 16kB, an order of magnitude smaller than in previous attacks. In designing our attack, we had access neither to source code nor to usage documentation; through reverse engineering of the hardware and software, we have reconstructed the functioning of the device. This is in contrast to the Appel et al. report, whose authors did have this access, as well as to most of the previous studies of voting machines (discussed in Section 1.1 below). We had access to an AVC Advantage legitimately purchased from a government surplus site by Andrew Appel [2] and a memory cartridge similarly obtained by Daniel Lopresti. Since voting machines are frequently left unattended (as Ed Felten has documented, e.g., at [12]), we believe that ours represents a realistic attack scenario. We hope that our results go some way towards answering the objection, frequently raised by vendors, that voting security researchers enjoy unrealistic access to the systems they study.4
 
  1.1 Related work
  Much of the prior research on voting machine security has relied on access to source code. The first such work by Kohno et al. [18] analyzed the Diebold5 AccuVote- TS voting machine and found numerous problems. The authors had no access to the voting machine itself but the source code had appeared on the Internet. Many of the issues identified were independently confirmed with real voting machines [9, 21, 22]. Follow up work by Hursti examined the AccuVote- TS6 and AccuVote-TSx voting machines using "source code excerpts" and by testing the actual machines. Backdoors were found that allowed the system to be extensively modified [17]. Hursti's attacks were confirmed and additional security flaws were discovered by Wagner et al. [27]. In 2006, building on the previous work, Feldman et al. examined an AccuVote-TS they obtained. The authors did not have the source code, but they note that "the behavior of [the] machine conformed almost exactly to the behavior specified by the source code to BallotStation version 4.3.1" which was examined by Kohno et al. In addition to confirming some of the security flaws found in the previous works, they demonstrated vote stealing software and a voting machine virus that spreads via the memory cards used to load the ballot definition files and collect election results [11]. In 2007, California Secretary of State Debra Bowen decertified and then conditionally recertified the direct recording electronic voting machines used in California as part of a top-to-bottom review. As part of the recertification, voting machine vendors were required to make available to independent reviewers documentation, source code, and several voting machines. In all cases, significant problems were reported with the procedures, code, and hardware reviewed [6]. Also in 2007, Ohio Secretary of State Jennifer Brunner ordered project EVEREST--Evaluation and Validation of Election Related Equipment, Standards and Testing-- as a comprehensive review of Ohio's electronic voting 2 machines. Similar to California's top-to-bottom review, the reviewers had access to voting machines and source code. Again, critical security flaws were discovered [7]. 2 The road to exploitation In 1997, Buncombe County, North Carolina, purchased a number of AVC Advantage electronic voting machines for $5200 each. In January 2007, they retired these machines and auctioned them off through a governmentsurplus web site. Andrew Appel purchased one lot of five machines for $82 in total [2]. Reverse-engineering the voting machine. Two members of our team immediately began reverse engineering the hardware and software. The machine we examined is an AVC Advantage revision D. It contains ten circuit boards, including the motherboard shown in Figure 1, with an eleventh inside the removable memory cartridge--see below. Each is an ordinary two-sided epoxy-glass type. Since these are somewhat translucent, with the use of a bright light, magnifying glass, lowvoltage continuity tester, and data sheets for the components, we were able to trace and reconstruct the circuit schematic diagram, and from that deduce how the unit worked. We filled in remaining details by partially disassembling the machine's software using IDA Pro. After approximately six man-weeks of labor, we produced a functional specification [14] describing the operation of the hardware from the perspective of software running on the machine. We documented 47 I/O functions that the processor can execute to control hardware functions, such as mapping areas of ROM into the address space, interfacing with the voter panel and operator controls, and reading or writing to the memory cartridge. Reverse-engineering the results cartridge. The AVC results cartridge is a plastic box about the dimensions of a paperback book with a common "ribbon-style" connector on one end that mates to the voting machine. Inside, there is an ordinary circuit board containing static RAM chips--backed by two type AA batteries--and common TTL 74-series integrated circuits. There is no microcontroller; instead all control signals come directly from the voting machine. Much of the internal circuitry appears to have been designed to withstand hot-plugging and to prevent accidental glitching of the memory contents. There is an additional 8bit of nonmemory data that can be read from the unit corresponding to the type and revision of the memory cartridge. This data is set by etch jumpers on the circuit board. We were able to change the type and revision of the cartridge by cutting the associated trace on the circuit card and wiring alternate jumpers. The contents of memory can be read or written by powering the device and toggling the appropriate input signals. We constructed a simple microcontroller circuit to interface with the cartridge to perform reads and writes. The microcontroller simply controls the appropriate signals on the cartridge connector to perform the operation indicated by a controlling program communicating with the microcontroller via a serial port. No access to the inside circuitry was necessary. By disassembling the software and looking at the contents of a valid results cartridge, we were able to understand the format of the file system used on the memory cartridges (and also the internal file system of the 128kB SRAM described below) and many of the files used by the voting machine. Crafting the exploit. Joshua Herbach used the hardware functional specifications to develop a simulator for the machine [15], which another member of our team subsequently improved.6 Our simulator now provides cycle-accurate emulation of the Z80, and it executes the AVC election software without any apparent flaws. We developed our exploit almost entirely in the simulator, only returning to the actual voting machine hardware at the end to validate it. Remarkably, the exploit worked the first time we tried it on the real hardware. Total cost. Starting with no source code or schematics, we reverse engineered the AVC Advantage and developed a working vote-stealing attack with less than 16 man-months of labor. We estimate the cost of duplicating our effort to be about $100,000, on the private market.
 
  3 Description of the AVC Advantage
  In this section, we give a description of the hardware and software that makes up the AVC Advantage in some detail. Readers not interested in such low-level details are encouraged to skip ahead to Section 4, referring back to this section for details as needed.
 
  3.1 Software
  The core of the version-5.00D AVC Advantage is a Z80 CPU and three 64kB erasable, programmable ROMs (EPROMs) which contain both code and data for the Advantage. Each EPROM is divided into four 16kB segments: BIOS, System Toolkit, Toolkit 2, Toolkit 3, Election Program, Election Toolkit, Reports Program, Consolidation Program, Ballot Verify Program, Define Ballot Program, Maintenance Utilities, and Setup Diagnostics; see Figure 2. When the Advantage is powered on, execution begins in the BIOS at address 0x0000. The BIOS contains a mixture of hand-coded assembly and compiler generated code for interrupt handling, remapping parts of the address space (see Section 3.2), function call prologues and epilogues, thunks for calling code in other segments, and code for interacting with the peripherals. 3 Figure 1: We reverse engineered the AVC Advantage hardware. The motherboard, shown here, is composed mostly of discrete logic and measures 14in14in. Election software is stored in removable ROM chips (white labels). The results and auxiliary memory cartridges are plugged directly into the motherboard (upper right). Apart from the BIOS, each EPROM segment contains a 16B header followed by a mixture of (mostly) compilergenerated code and data. The segments with "Toolkit" in their name7 in addition to the Reports Program consist of the header followed immediately by a sequence of jp addr instructions, each of which jumps to a global function in the segment. For the entries in this sequence corresponding to global functions, there is a corresponding thunk in the BIOS which causes the segment to be mapped into the address space before transferring control to the function. Functions in one segment can call global functions in another segment by way of the thunks. Each of the remaining segments is a self-contained program with just a single entry point immediately after the segment header. When a program is run, much of the state of the previous program--including the stack and the heap--is reset. In particular, any data written to the stack during one program's execution are lost during a second program's execution. A typical sequence of events for an election would include the following. The machine is powered on and begins executing in the BIOS. The BIOS performs some initialization and tests before transitioning to a menu in Maintenance Utilities awaiting operator input. The operator selects the Setup Diagnostics choice and the corresponding Setup Diagnostics program is run. This performs various software and hardware tests before transitioning to the Define Ballot Program. This program checks the memory cartridge inserted into the machine and upon finding a ballot definition transitions to the Ballot Verify Program. The Ballot Verify Program checks that the format of the ballot is correct and ensures that the files which hold the vote counts are empty. After this, it illuminates the races and candidates so that the technician can verify that they are correct. Assuming everything is correct, control transfers to the Election Program for the pre-election logic and accuracy testing. The voting machine is powered off at this point and shipped to the polling places. After it has been powered back on, control again passes to the Election Program, this time for the official election. The ZiLOG Z80 CPU is an 8bit accumulator machine. All 8bit arithmetic and logical operations use the accumulator register a as a source register and the destination register. Apart from the accumulator register, there are six general purpose 8bit registers b, c, d, e, h, and l which can be paired to form three 16bit registers bc, de, and hl. These registers along with an 8bit flags regis- ter f and 16bit stack pointer sp and program counter pc registers are compatible with the Intel 8080. In addition, there are two 16bit index registers ix and iy, an interrupt vector register i, a DRAM refresh counter register r, and four shadow registers af', bc', de', and hl' which can be swapped with the corresponding nonshadow registers. The Advantage uses the shadow registers for the interrupt handler which obviates the need to save and restore state in the interrupt handler. See [28] for more details. Due to the limited ROM space for code and data, compiler-generated functions which take arguments or have local variables use additional functions to implement the function prologue and epilogue. The prologue pushes the iy and ix registers and decrements the stack pointer to reserve room for local variables. It then sets iy to point to the first argument and ix-80h to point to the bottom of the local stack space. Finally, it pushes the stack-address of the two saved index registers and the address of the epilogue function before jumping back to the function that called the prologue. See Figure 3. The epilogue function pops the saved pointer to the index registers and loads sp with it. Then ix and iy are popped and the epilogue returns to the original saved pc. It is the caller's responsibility to pop the arguments off the stack once the callee has returned. 3.2 Address space layout The AVC Advantage has a 16bit flat address space divided into four distinct regions. The bottom 16kB is mapped to the BIOS. The 16kB-32kB range can be mapped to one of the 12 16kB aligned segments on the three program EPROMs. This mapping is controlled by the software using the Z80's out instruction. The 32kB-63kB range addresses the bottom 31kB of a 32kB, battery-backed SRAM. Finally, the top 1kB of the address space can be mapped to either the top 1kB of the 32kB SRAM or it can be mapped to any 1kB aligned region of a 128kB, battery-backed SRAM. This mapping can be changed by the software using the Z80's out instruction. For more detail, see [14]. The AVC Advantage's stack starts at address 0x8FFE and grows down toward smaller addresses. The heap occupies a region of memory starting from an address specified by the currently active program to 0xEBFF. Scattered throughout the rest of 32kB main memory, there are various global variables and space for the string table of the active program. In addition, starting at 0x934E and growing down, there is space for a module call stack which allows modules to make calls to functions in other modules, such as printf or strcpy. See Figure 4. As the lower 32kB of the address space corresponds to EPROMs, data cannot be written to those addresses and attempts to do so are silently ignored by the hard- ware.8 Similarly, as the upper 32kB of the address space is for writable memory, not program code, any attempt to fetch an instruction from those addresses raises a nonmaskable interrupt (NMI). The NMI causes the processor to load a known constant into the pc register and execution resumes in the BIOS where the processor will be halted after displaying an error message on the operator LCD. This design makes the AVC Advantage a Harvardarchitecture computer.
 
  4 Return-oriented programming
  Since the AVC Advantage is a Harvard architecture computer, traditional code injection attacks cannot succeed because any attempt to read an instruction from data memory causes an NMI which will halt the machine. In practice, given a large enough corpus of code, this is not a barrier to executing arbitrary code using returnoriented programming--an extension of return-to-libc attacks where the attacker supplies a malicious stack containing pointers to short instruction sequences ending with a ret [24, 8]. The Z80 instruction set is very dense. Every byte is either a valid opcode or is a prefix byte. As there are no invalid or privileged instructions, instruction decoding of any sequence of data always succeeds. This density facilitates return-oriented programming since we can exploit unintended instruction sequences to build gadgets--a sequence of pointers to instruction sequences ending with a ret. For a concrete example, the BIOS contains the code fragment ld bc,2; ret--a potentially useful instruction sequence in its own right--which is 01 02 00 c9 in hex where the first three bytes are the load and the last is the return. If we set the program counter one byte into the load instruction, then we get the instruction sequence 02 00 c9 corresponding to the three instructions ld (bc),a; nop; ret which stores the value of the accumulator into memory at the address pointed to by the register bc. Shacham [24] and later Buchanan et al. [8] had code corpora on the order of a megabyte from which to construct gadgets. In contrast, Francillon and Castelluccia [13] had only 1978B of code with which to craft gadgets; however, they did not construct a Turing-complete set of gadgets. This prompts the question: What is the minimal amount of code required to construct a Turingcomplete set of gadgets? By constructing a Turingcomplete set of gadgets using only the AVC Advantage's BIOS--which consists of 16kB of code and data--we make progress toward answering that question. Following Shacham, we wrote a small program to find sequences of instructions ending in ret. We ran this program on the AVC Advantage's BIOS. We then manually devised a Turing-complete set of gadgets from the instruction sequences found by our program, including gadgets to control the peripherals like the LCDs and memory cartridges. We build a collection of gadgets that implement a 16bit memory-to-memory pseudoassembly language. See Table 1 for a description of the pseudo-assembly language and Appendix A for the implementation of many of the gadgets and a precise explanation of the notation that will be used in the remainder of the paper. (We stress that demonstrating return-oriented programming on the Z80 is a major contribution of this paper and of independent interest; we have moved the details to an appendix to improve the paper's flow.) Some of the gadgets in Table 1 are straightforward to construct; others require more finesse due to tricky interactions among the registers used in the instruction sequences. For ease of implementation, no state is presumed to be preserved between gadgets. That is, all arguments are loaded from memory into registers, operated upon, and then stored back into memory.9 In this way, each gadget can be reasoned about independently. The operands to the gadgets are either global variables--declared with the .var directive--or immediate values; labels are resolved to offsets and thus are immediate values. Some of the instruction sequences described in Appendix A contain NUL bytes which make them unsuitable for use in stack smashing attacks using a string copy. An early implementation of the gadgets took great pains to avoid all zero bytes. However, using the multi-stage exploit described below, avoiding zero bytes was unnecessary except for in the first stage of the exploit which did not use the gadgets presented in this section. As such, the simpler form of the gadgets is presented. It has become traditional in papers on return-oriented programming to show a sorting algorithm implemented as a return-oriented program [8, 16]. In Appendix B, we give the listing for a return-oriented Quicksort. We have verified that this sorting algorithm works on the actual AVC Advantage as part of a larger program that prints a list of numbers on the printer, sorts them, and prints the sorted list.
 
  5 A multi-stage exploit for the AVC Advantage
  Even though many parts of the code we reverse engineered appear to handle data from memory cartridges safely, we have been able to find a stack buffer overflow vulnerability. In this section, we describe this vulnerability and discuss how an attacker can exploit it to overwrite the AVC Advantage's stack and reliably induce the execution of a return-oriented payload of his choice. We stress that the buffer overflow that we have identified appears to be unrelated to the one identified by Appel et al. in their report [3, Section II.26]. Our buffer overflow occurs in cartridge processing whereas Appel et al.'s occurs in interaction with the daughterboard (which the machine we studied lacks); our overflow requires manual action, whereas Appel et al.'s is triggered on boot; our overflow is exploitable for diverting the machine's control flow, whereas Appel et al.'s appears to allow only a denial of service. We do not know whether the overflow that we found persists in the more recent AVC Advantage version that Appel et al. examined. One of the programs not normally used in an election, but accessible from the main menu, contains a buffer overflow while reading from an auxiliary cartridge of a certain type. (As described in Section 2, we physically modified a results cartridge so that the AVC Advantage would recognize it as a cartridge of the type for which the appropriate menu item is enabled.) A maliciously crafted field in one of the files allows roughly a dozen bytes to be written at the location of the saved stack pointer. In the first stage of the exploit, the hl register is set and the stack pointer is modified using the sp hl instruction sequence, inducing a return-oriented jump to an attacker-controlled location in memory. For stage two, a section of memory under attacker control needs to contain gadgets. Fortunately (for the attacker), a file of fixed size but with several dozen unused bytes is read from the memory cartridge into a buffer allocated by malloc. By the time of the overflow in stage 7 Figure 5: The machine has slots for two memory cartridges. The first cartridge stores ballots and votes. An attacker could install vote sealing code by inserting a prepared cartridge into the second slot. one, this buffer has been deallocated but most of its contents remain in memory at a known location. This unused space can be changed to contain gadgets that make up the second stage of the exploit. The first thing that stage two does is reallocate memory for the buffer so that additional allocations will not overlap and thus write over the gadgets. At the same time, enough memory is allocated to hold the contents of an additional file from the memory cartridge. The data from this file--stage three of the exploit--is read into the allocated buffer. Control then transfers to stage three which can perform arbitrary code execution using the gadgets described in Section 4. We have tested on an AVC Advantage that the exploit procedure described in this section works, using it both to run the sorting program described in the previous section and the vote-stealing exploit described in the next. 6 Using the exploit to steal votes We have designed and implemented a demonstration vote-stealing exploit for the AVC Advantage, using the vulnerability described in the previous section to take over the machine's control flow. We have tested that our exploit works on the actual AVC Advantage. (Although it was designed and debugged exclusively in our simulator, the exploit worked on the real hardware on the first try.) In this section, we describe both the actions that an attacker will undertake to introduce the exploit payload to the machine and the behavior of the payload itself. We also note several ways in which the exploit could be made more resistant to detection by means of forensic investigation. Our attacker accesses the AVC Advantage when it is left unattended the night before the election. Ed Felten has described how such access is often possible (see, e.g., [12]). At this point, the machine has been loaded with an election definition and has passed pre-LAT.10 The attacker picks the locks for the back cabinet, the voter panel, and (later) the open/close polls switch. Appel et al. have shown that these locks are of a low-security kind that is easily bypassed [3, Section I.9]. The attacker does not need to remove any tamper-evident seals; in particular, he does not need to remove the circuit-board cover. Having gained access to the back cabinet of the AVC Advantage, the attacker uses the normal functions to open the polls, cast a single vote, and close the polls. (The polls cannot be closed with no votes cast.11) Once the polls are closed, the attacker unseats the results cartridge. The cartridge cannot be removed completely because of the tamper-evident seal; however, the seal is small enough compared to the holes through which it is inserted that the cartridge can be disconnected from the machine. With the polls closed and the cartridge removed, the attacker uses the two-key reset gesture ("print-more" and "test") to gain access to the machine's post-election menu. From this menu, he can reset the machine; after the reset, the machine's main menu is accessible. (Were the results cartridge not removed, the data on it would be erased by the reset. The attacker might be able to recreate this data and rewrite it to the results cartridge, but unseating the cartridge before the reset obviates this.) To this point, the attacker is simply following the same procedures poll workers and election officials use in running an election and resetting the AVC Advantage for the next election. His goal is to gain access to the main menu, from which he can direct the machine toward the vulnerability described in Section 5. The system reset appears to clear the audit logs on the machine. Our demonstration vote-stealing exploit does not undo this log-clearing, though a more stealthy attack might wish to; otherwise, a post-election audit might discover that log entries are missing. (Although, as Davtyan et al. have found in their audit of the AccuVote AV-OS system [10], discrepancies in logs are not uncommon and may not be perceived as signs of an attack.) Even if the attack is detected, the original voter intent will not be recoverable. The attacker can use the post-election menu to dump the contents of the logs either to a trans-fer cartridge or to the printer and cause his exploit payload to restore them once the system is compromised. In addition, since a vote was cast, the protective counter has been incremented; however, the protective counter is subject to software manipulation and could easily be rolled back if the attacker desires. Traces of the phantom vote might also remain in the machine or operator logs; if so, a stealthy exploit would have to remove these traces. The attacker now reinserts the results cartridge and a cartridge of the appropriate type into the auxiliary port and navigates the menus to trigger the vulnerability described in Section 5. Using a three-stage exploit as described in Section 5, he takes control of the AVC Advantage and can execute arbitrary (return-oriented) code. Note that hardware miniaturization since the design of the AVC Advantage makes possible the creation of cartridges much smaller than legitimate cartridges with orders of magnitude more storage. (Different parts of memory could be paged in using a "secret knock" protocol.) A smaller cartridge may allow the attacker to bypass tamper-evident loops placed on the auxiliary port guide rails that would prevent the insertion of a legitimate cartridge (although we are not aware of a jurisdiction that attempts to limit access to the auxiliary port in this way); it may also allow him to leave an auxiliary cartridge in place during voting while avoiding detection, which would be useful for exploit payloads larger than can fit in main memory and unused portions of the results cartridge. (As noted below, our exploit payload easily fits in main memory.) The exploit first restores those parts of the machine's state necessary to allow the election to begin again. It copies the results cartridge's post-LAT voting files (which are in their empty state) over the results cartridge's election files so that the single ballot that was cast in order to close the polls is erased. It then copies (most of) the contents of the results cartridge into the internal memory. At this point, a message is displayed on the operator LCD instructing the attacker to remove the auxiliary cartridge and turn off the power. In order to convincingly simulate power off, we need the power switch to be in the off position. Luckily, the AVC Advantage has a soft power switch, so turning the power knob just sets a flag that can be polled by the processor at interrupt time to detect power off. So long as the exploit code disables interrupts (while petting the watchdog timer to keep it from firing) it can keep the machine running; it can also detect when, later, the power switch is turned to the on position. (By contrast, were the machine actually to power down, the stack would be reset on a subsequent power up and the attacker would lose control.) The AVC Advantage features a large 110V battery designed for 16 hours of operation that we believe will allow it to remain overnight in this state [23]. Of all the steps in our exploit, this is the one that most intimately relies on the details of the AVC Advantage's hardware implementation. We emphasize that we have tested on the actual machine that our exploit code is able to survive a power-down/power-up cycle in this way on battery power alone. When the exploit code detects that the power switch has been turned to the off position, it simulates power down. It turns off the LEDs in the voter panel, clears the LCD displays, and turns off any status LEDs. In testing on an AVC Advantage, we have been able to disable (via return-oriented code) all indicators of power except the LCD backlight on the operator panel. This is the most visible sign of our attack; we are currently studying how the backlight might be disabled. The attacker now closes and locks the operator and voter panels, removes the auxiliary cartridge, and leaves. The next morning, poll workers open the machine and use the power switch to turn it on. The exploit code detects the change and simulates the machine's powerup behavior, followed by the official election mode messages. The exploit must now simulate the machine's normal behavior when poll workers open and close the polls and when voters cast votes. While it would be possible to reimplement this behavior entirely using return-oriented code, the design of the AVC Advantage's voting program makes it possible for us to reuse large portions of the legitimate code, making the exploit smaller, simpler, and more robust. This would be more difficult to do if the exploit modified votes as they were cast, but we have instead chosen to wait until polls are closed and only then change the cast votes retroactively. The absence of a paper audit trail means that the vote modification will not be detected. Other possible designs for vote-stealing software are described by Appel et al. [3, Section I.5-6]. The main voting function is structured as a series of function calls that can be separated into three main groups, each called a single time in order in the normal case. The first group of functions waits for the "open/- close polls" switch to be set to open and prints the zero tape. The second group of functions handles all of the voting, including waiting for the activate button to be pressed and handling all voter input. Once the polls are closed, the third group of functions handles printing the final results tape and all post-election tasks. Our demonstration exploit uses the high-level functions in the AVC Advantage's legitimate voting program to handle all voting until the polls are closed. Then the exploit reads the vote totals, moves half of the votes for the second candidate to the first candidate, and changes the cast vote records (CVRs) to match the vote totals. (Obviously, any fraction of the votes could be modified. Furthermore, while our exploit processes the CVR log in order, changing every CVR cast for the disfavored candidate until the desired shift has been effected, more sophisticated strategies are possible.) The exploit now relinquishes control for good, handing control over to the legitimate AVC Advantage program to handle all postelection behavior. When the "Official Election Results Report" is printed it will reflect the results as modified by the exploit. The AVC Advantage contains routines to check the consistency of its internal data structures. When the data is inconsistent, e.g., the vote totals do not match the CVR totals, this is noted in the Results Report. The exploit ensures that all data structures in memory and on the results cartridge that are checked by these routines are consistent whenever the routines are executed. Even after it has relinquished control, our exploit remains in main memory until the machine is shut down. Forensic analysis of the contents of the AVC Advantage's RAM would be a nontrivial task; nevertheless, a stealthier exploit would wipe itself from memory before returning control to the legitimate program. If any portion of the exploit code is stored on a cartridge, this must be wiped as well. Because suspicious poll workers might remove the cartridge before it can be wiped, anything stored on a cartridge should be kept encrypted, and the exploit code should scrub the key from RAM if it detects that the cartridge has been removed. Our vote-stealing demonstration exploit is just over 3:2kB in size, including all of the code to copy the files and the memory cart. It fits entirely in RAM, as would even a substantially more sophisticated exploit: There is roughly an additional 10kB of unused heap space that could be used. In addition, any code that is executed only while the attacker is present need not actually stay in the heap once it is finished and could be replaced with additional code for modifying the election outcome.
 
  7 Conclusions
  A secure voting machine design must withstand attacks devised throughout the machine's service lifetime. Can real designs, even ones with promising security features, provide such long-term security? In this paper, we have answered this question in the negative in the case of the Sequoia AVC Advantage (version 5.00D). We have demonstrated that an attacker can exploit vulnerabilities in the AVC Advantage software to install vote-stealing malware by using a maliciously-formatted memory cartridge, without replacing the system ROMs. Starting with no source code, schematics, or nonpublic documentation, we reverse engineered the AVC Advantage and developed a working vote-stealing attack with less than 16 man-months of labor. Our exploit relies in a fundamental way on return-oriented programming, a technique introduced some two decades after the AVC Advantage was designed. In mounting the attack, we have extended return-oriented programming to the Z80 processor.

Questions for the savvy reader (3, Insightful)

hessian (467078) | about 5 years ago | (#29026911)

1. What form of electronic voting could not be compromised?
2. What form of paper voting could not be compromised?

It may be that we must accept that no form of voting is "secure" in the sense of cannot be gamed.

At least, people have been gaming votes for as long as democracy has existed, so I don't know if they're going to stop just because we make it slightly less convenient.

Re:Questions for the savvy reader (1)

Attila Dimedici (1036002) | about 5 years ago | (#29027117)

1. What form of electronic voting could not be compromised? 2. What form of paper voting could not be compromised?

It may be that we must accept that no form of voting is "secure" in the sense of cannot be gamed.

At least, people have been gaming votes for as long as democracy has existed, so I don't know if they're going to stop just because we make it slightly less convenient.

They aren't going to stop because we make it less convenient, but why should we make it more convenient?
Every form of electronic voting I have seen makes it easier and more convenient to commit massive election fraud and easier and more convenient to hide such fraud. Actually, I can't think of any "voting reform" that has occurred in my life that doesn't make election fraud easier and more convenient.

Re:Questions for the savvy reader (1)

db32 (862117) | about 5 years ago | (#29027131)

The real danger is that people believe paper ballots can be easily subject to problems and that electronic voting is somehow impervious to these problems.

Re:Questions for the savvy reader (1)

Zontar_Thing_From_Ve (949321) | about 5 years ago | (#29027325)

The real danger is that people believe paper ballots can be easily subject to problems and that electronic voting is somehow impervious to these problems.

Actually, I find it troubling that many people seem to believe that paper ballots cannot be compromised at all. I'm not more in favor of electronic voting and I'm not against paper ballots, but I get the sense that quite a few people here seem to think "paper ballots = 100% assurance of honesty" and I don't agree with that. Then again, I was in Ukraine in November of 2004 during the Orange Revolution (long story, but I had long standing plans to go there right after the election and those plans had nothing to do with the election at all) and I've seen how paper ballots can be compromised.

Re:Questions for the savvy reader (1)

gclef (96311) | about 5 years ago | (#29027165)

It's all about managing risk...sure, you can stuff ballot boxes, but it's difficult to do that on an enormous scale without being noticed (note: I didn't say impossible, just difficult). On the other hand, if you can simply edit a database to change votes, the barrier to entry for vote fraud drops dramatically.

We probably do have to accept that every voting system can be gamed...what we do *not* have to accept is that this means they're all equally good/bad.

Re:Questions for the savvy reader (1)

nextekcarl (1402899) | about 5 years ago | (#29027265)

It isn't about making it impossible, just really, really hard. And to do that we have to understand the possibilities well enough that we can decide what is good enough. If we mistakenly think electric voting is perfect when it really has these big gaping holes in it, then we have a lot more work to do. That's what these guys are trying to point out. You do reach a point of diminishing returns, but that doesn't mean it isn't worth trying.

Re:Questions for the savvy reader (1)

Chirs (87576) | about 5 years ago | (#29027317)

I'm in Canada. We use paper ballots. It would be fairly hard to compromise this in any significant way.

You walk into a room, validate your identity, they give you a ballot from a book of ballots. The ballot has a tear-off part with a serial number that matches the stub in the book.

You go behind a screen, mark an X for the candidate of your choice, fold over the ballot, then come back out. You hand the ballot to an official who verifies that the serial number matches what was given to you, then rips off the serial number and gives you the ballot. You put it into a locked box in full view.

Representatives from all candidates are entitled to be present for the vote counting.

Re:Questions for the savvy reader (1)

Tacvek (948259) | about 5 years ago | (#29028331)

Harder than electronic voting, yes, but common exploits such as multiple voting (being on the voter list in multiple polling locations), "losing" ballot boxes during transportation after voting but before counting, would still apply. The later issue could be eliminated by counting all the votes in public at the polling location. At the end the results are recorded and certified on an election results card. Then these cards are accumulated from all voting stations in an area, and the contents of the cards being made publicly available (such as online).

The area chosen should be small enough that there are only 20 or so election results cards. Thus one missing would be very noticeable. Members of the public who saw the card filled out at the polling place would notice if the publicly posted figures differed from what they saw, so any funny business there would be detected.

The vote counters would sum up the values from the 20 or so cards, and write out a new 2nd level voting results card, which is certified.

Like the first level cards, these would be collected up in groups of say 20, and publicly posted.
Those who independently verified the results of the first level election by adding them themselves would notice any discrepancy in the posted second level cards.

After ceil(log(pollingplaces)/log(20)) iterations, (which will of course be a reasonably small number) there will only be one voting result card, with the final election results.

If even 10 or so members of the public form each polling station watched the counting, verifying the results seen with the posted first level card for their area, verified the values on the posted second level card for their area, etc the result would be complete confidence in the final count matching the values actually cast.

Now we would still have the issues of coercion preventing people from voting, or forcing them to vote differently, and the issues of multiply registered voters, etc, but those issues could not possibly be corrected by electronic voting either.

tfa slashdotted? (0)

Anonymous Coward | about 5 years ago | (#29027025)

can't access pdf. can anyone who has it (and blasphemed /. by rtfa) post some text?

How hard can it be??? (0)

Anonymous Coward | about 5 years ago | (#29027113)

O. M. G.

How fucking hard can it be to create a simple, secure voting machine?

Start with this: http://www.staples.com/Amplivox-Aluminum-Truss-Lectern/product_683093?cmArea=SEARCH [staples.com]

Weld a steel box under it, lock one of these in it: http://www.logicsupply.com/categories/mainboards/nano_itx [logicsupply.com]

A simple touchscreen on the top: http://www.newegg.com/Product/Product.aspx?Item=N82E16824103028 [newegg.com]

A 2-ply receipt printer: http://www.posmicro.com/RECPRINTERS/SAMSUNG_PRINTERS/samsung_srp_270_receipt_printers.htm [posmicro.com] (Also locked in a box, with an extra-large roll of paper)

Then, have a secure server in a cage in the corner of the room. Have the voting terminals boot over network from the server. All they need to run is a simple interface that shows the names of the candidates and allows you to touch to select them. Then it prints a receipt for you, keeping the other copy internally.

Sure, there are details to iron out, but come on, it can't be that hard.

You want to prove it to the critics? (1)

lalena (1221394) | about 5 years ago | (#29027147)

critics complain that the attacks aren't realistic

Step 1) Create tool to hack machine.
Step 2) Next election, reprogram the voting machine to play PacMan.
Step 3) Watch Cable News Networks spend weeks talking about the issue.
Step 4) Watch politicians scramble to pass something/anything to prove they care about this issue.
This will all work as long as you don't care about step 5.
Step 5) Go to jail. You do have to show ID to vote and if there is someone in line behind you at the booth, they will know real quick you hacked the machine.

Re:You want to prove it to the critics? (1)

Firemouth (1360899) | about 5 years ago | (#29027475)

If you can program PacMan into a voting machine, I'm sure you could come up with a method to divert the blame... such as a delay so the 73rd voter after you get's to play PacMan instead of "Who Wants To Be A President"

Re:You want to prove it to the critics? (1)

HTH NE1 (675604) | about 5 years ago | (#29028151)

If you can program PacMan into a voting machine, I'm sure you could come up with a method to divert the blame... such as a delay so the 73rd voter after you get's to play PacMan instead of "Who Wants To Be A President"

As well as change the value of the delay after it expires to say it delayed until the 37th voter so they can't count backwards to find you. It can optionally also delete the code that changed the delay, but you don't really need to unless you're trying to frame a particular person. And yes, it is possible to create secure self-erasing code.

Re:You want to prove it to the critics? (1)

Zordak (123132) | about 5 years ago | (#29028435)

Or just blame the guy in front of you. "Hey, I came here to vote, and all this machine will let me do is play Pac Man."

Why doesn't Public Key crypto figure in to this? (4, Interesting)

Abalamahalamatandra (639919) | about 5 years ago | (#29027423)

Here's what I'm trying to understand.

We have this great thing called Public Key Crypto and the PKI to go along with it.

If you presume a custom processor that will only execute code signed by an election commission, that would be a first step - the system won't run anything that hasn't been specifically approved for installation on the machine. There would be no more "last minute fixes" as we've seen in the past, where code was installed without being vetted by an election authority.

For that matter, require the software developers to store their code on a state or federal election repository, and only sign code that's been compiled on those systems, from that repository. Require that anyone who makes changes sign them with their private key and state the reason for the change.

For the results, take each ballot, strip off the identifying information, and encrypt it to the election commission, and sign it with a pre-deployed per-machine private key that's known. It would of course also be important to have a reliable time source for the device, to include that in the result file.

I would even envision that this would be a good purpose for a federal election agency - hosting the code for all certified voting systems, and being the "root of trust" that signs certificates for the state election commissions, which can then sign local and county commissions, which can then issue keys to individual election machines.

Some patches to an open-source OS, say Linux, a PKI infrastructure (along with some HSM modules to store keys) and a processor with an integrated crypto engine and TPM module would take care of all of this.

Banks do this kind of stuff all the time - what's so hard about it?

Re:Why doesn't Public Key crypto figure in to this (1, Funny)

Anonymous Coward | about 5 years ago | (#29027903)

> Banks do this kind of stuff all the time - what's so hard about it?

Banks have money at stake... that's too important to be left unguarded... if, however, you have a shiny suit and some friends at the bank you can rob the place blind with dodgy loans (see recent wikipedia material related to iceland)... no hard hack required.

Elections are too important to allow the people to decide, enough holes have to be left so that it appears as if democracy is in action when in reality no such thing is happening... how does it go? "I will deliver Ohio to GWB" or some such.

Bama's recent victory is no doubt due to the fact that a 'steal' on that one would have been too blatant... the most effective vote tampering is when the race is close.

You miss the point. (1)

Dorkmaster Flek (1013045) | about 5 years ago | (#29027923)

It's not that it's hard to do it. It's that they don't want to do it.

Re:Why doesn't Public Key crypto figure in to this (1)

six (1673) | about 5 years ago | (#29028343)

If you presume a custom processor that will only execute code signed by an election commission, that would be a first step - the system won't run anything that hasn't been specifically approved for installation on the machine.

If you had RTFPDF, you would have noticed they actually used a clever technique called return based programming, to reuse small parts of trusted code and implement their hack using them.

voting machine attacks (1)

amoeba1911 (978485) | about 5 years ago | (#29027513)

I was just walking down the street, out of nowhere voting machines came and attacked me and stole my wallet.

Still misses an important point (3, Insightful)

lseltzer (311306) | about 5 years ago | (#29027737)

Give me a few private minutes with a paper ballot box and I can stuff it full of ballots for my candidate. That's an old-school hack.

Design Documents? (1)

pseudorand (603231) | about 5 years ago | (#29028045)

What do Design Documents have to do with anything. Considering that most developers put them straight in the circular file, I fail to see how that would help you hack the system.

There IS an answer, and it;s an easy one... (1)

Sandbags (964742) | about 5 years ago | (#29028089)

look, it's simple.... Digital voting machine swith 2 way paper validation. 1 copie prints out of the back of the voting machine with a unique "voter number" (identifies the ticket itself as a receipt number, and has NOTHING to do with the person voting). A second copy prints out on a large tape at central voting table from a seperate central machine and feeds into a scanner on a 3rd machine. Your voting record is also stored electronically indexed by the voting receipt number in the central machine that printed the second copy. An additional step validating the 2 printed copies match completes the cycle and certifies the vote in a 3rd system that has no network connection to the others.

Upon entering a booth, you vote electronically. It presents your vote summary on the screen and has you confirm. Once confirmed your machine and the central machine print a voting record. You take the paper tape, walk over to a second machine, and insert the paper tape. The 3rd machine already scanned the output from the central machine, and now scans your to ensure they match, based on the voting receipt ID as an index. This extra step validates that 2 machines received the same data, and that you verified this data visually, and that data was successfully recorded using no electronic connections. This also guarantees that we have not only 2 electronic records, but a complete validatable paper trail should anyone raise a stink about the voting accuracy.

This system is basically impossible to hack as even if the 3rd machine, that actually is the voting authority, was hacked, the paper trail from machine 2 and your voting machine would not match that record, and the paper trail would become the official vote. Because you have the ability to visually verify your individual vote both electronically and on paper, this is an unhackable system. It;s also relatively cheap to get printers to output this record, and also cheap to have a simple OCR scan for the known names on the voting paper (aka it's using a really small word list and thus would have amazing accuracy).

Slashdot restricting me! ARGH! (1)

Tolkien (664315) | about 5 years ago | (#29028095)

Quick question, I don't know what I did, but why the hell is slashdot restricting the number of posts I can initially see to 5? I have to press "More" to load more posts and it's irritating as hell. For big discussions (eg. 200+) I have to click AT LEAST 40 times, waiting each time for the next 5 posts to completely load. ARGH! How do I fix this?

Internet Voting From Home... (0)

Anonymous Coward | about 5 years ago | (#29028533)

Why not just use internet voting from home? A secure web site directly tied to the election board's servers. Vote file gets some ridiculously large checksum before transmitting and you get a confirmation email with a confirmation code if successfully transmitted. You print out a copy and mail it in for backup.

I bank online without issue, and the vast majority of Americans are far more concerned about their money than their vote, so why not? I mean, what good is the Supreme Court if they aren't deciding elections, you know, like in Iran?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>