Want to know how to fix an election without resorting to bribery and corruption? Ever thought about throwing some Return Oriented Programming into the voting equation?

Ordinarily, the hacking into of an electronic voting machine might spark a little bit of interest if there were an election looming perhaps. That said, the potential insecurity of such machines can happily be filed under old news.

However, my attention was grabbed by the paper (Can DREs Provide Long-Lasting Security?) from a bunch of security researchers based at the Universities of California, Michigan and also Princeton. Not least because while it did, I admit, involve revealing how a Direct Recording Electronic voting machine had been hacked it also described something called Return Oriented Programming. Also, much of the research that has gone before when it comes to the security of voting machines tends to rely greatly upon having access to source code. The researchers say that they hope their results "go some way towards answering the objection, frequently raised by vendors, that voting security researchers enjoy unrealistic access to the systems they study."

The DRE voting machine in question, a Sequoia AVC Advantage, dates back to the 80's so maybe it is not that surprising that it can be hacked today. However, that does not make it an easy target: the thing employs numerous safeguards such as separating data and code, and throwing up a non-maskable interrupt error if someone were to try and execute injected code in RAM (the actual executable code for this machine is held in ROM). Nor does it make the research irrelevant, as the team states in its paper "because the development, certification, and procurement cycle for voting machines is unusually slow, the service lifetime can be twenty or thirty years."

Yet the research team are insistent, courtesy of Return Oriented Programming techniques, that if someone used the same techniques as they describe it would be possible, assuming they had access to the machine in the first place, to replace the installed election application with one of their own which could manipulate the voting in any way the attacker wished.

"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" the researchers explain in their paper, adding "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." By using a stack that is made up of code snippet addresses the researchers were able to show how they can recreate what are, for all intents and purposes, arbitrary programs. It's clever stuff, using a bog standard buffer overflow within the program code to create the stack and having a ret instruction triggering one ret after another in order to execute the vote rigging code itself.

The team have managed to demonstrate that an attacker could exploit vulnerabilities in one particular voting machine in order to install vote-stealing malware using a maliciously formatted memory cartridge. The important thing being that they have done this without replacing the system ROMs and starting out with "no source code, schematics, or nonpublic documentation." The whole attack-stealing code was produced in less than 16 man-months of labour and at a cost, if replicated in the private sector of around $100,000.

Kudos to Stephen Checkoway, J. Alex Halderman, Ariel J. Feldman, Edward W. Felten, Brian Kantor and Hovav Shacham for their innovative research.

Edited 7 Years Ago by happygeek: n/a

As Editorial Director and Managing Analyst with IT Security Thing I am putting more than two decades of consulting experience into providing opinionated insight regarding the security threat landscape for IT security professionals. As an Editorial Fellow with Dennis Publishing, I bring more than two decades of writing experience across the technology industry into publications such as Alphr, IT Pro and (in good old fashioned print) PC Pro. I also write for SC Magazine UK and Infosecurity, as well as The Times and Sunday Times newspapers. Along the way I have been honoured with a Technology Journalist of the Year award, and three Information Security Journalist of the Year awards. Most humbling, though, was the Enigma Award for 'lifetime contribution to IT security journalism' bestowed on me in 2011.

Hi dear,
We are know the mother language of computer.And we can generate system as well as application programming.OOPs is a big concept language of orinted program.C language is used for hacking program by hackers.

Talking about buffer overflow exploit on x86, Mac OS X is the most easy and hacker friendly target compare to Linux or Windows. OS X always loads /usr/lib/dyld at a fixed location and it contains a lot of helper stubs to launch the exploit.

We are know the mother language of computer.And we can generate system as well as application programming.OOPs is a big concept language of orinted program.C language is used for hacking program by hackers.

I'm still trying to decipher this paragraph. You or no collective can be a "know" or a "mother language".

The article starter has earned a lot of community kudos, and such articles offer a bounty for quality replies.