Computer scientists have figured out to how trick a widely used electronic voting machine into altering tallies with a technique that bypasses measures that are supposed to prevent unauthorized code from running on the device. The method, known as return-oriented programming, has already been used to defeat security measures …
The voiting process needs to be transperent.
How can you have a democracy if you are not legally allowed to inspect the voting process.
Voting machines should have a paper trail to verify the digital tally and hardware and software should use an open design that anyone can inspect.
What's more important to them?
1 A system (I presume the sell a lot of other stuff linked to this machine as well) that looks secure.
2 A system that is either currently secure or which they are actively making more secure.
The response of a company like this to a situation like this says a great deal about how really trustworthy they are.
To be fair. This tactic seems to successful acros a range of platforms and is almost a generic (along with timing out a packet response in a challenge/response comms protoocol). I think we may be hearing about this approach for some time.
Now write out 100x "Security by obscurity does not work. Only MBA types think it does."
"Yes Mr President these voting machines are completely hack proof"
Protecting "paperless" voting systems
How many exploits like this will it take before the people who give contracts to these snake-oil dispensers realise that a paperless voting system is as useful in real terms as a paperless toilet?
Note to govtards - not all problems are mitigated by adding computers!
Tried and Tested
Pencil + Paper. X in box.
No Chuds, no inherently insecure and abusable electronics just graphite and parchment.
Thumbs up for the Boffins getting there first on the exploit, good work.
Who watches the watchman?
``Sequoia and manufacturers of other brands of e-voting machines frequently discount vulnerability research into their products by pointing out that the underlying source code is closely guarded."
How many employees do Sequoia have?
(If you're a Sequoia spokesperson and require me to elaborate further then you clearly do not understand the problem!)
first take amerika then steal the universe
Surely the universe consists of more than "New Jersey and in parts of Louisiana, Pennsylvania, Wisconsin, Colorado and Virginia" or is it that having taken the continent the yanks now own the universe?
This is news?
What is being documented here is a simple reverse-engineering hack. Not exactly novel - I've done the same thing with my C64's ROMs - getting it to print my name on the startup screen when the machine is powered up, changing some of the BASIC commands and screen colours, etc. The availability of cheap, blank EEPROMs and burning hardware makes this sort of exploit embarrasingly easy.
Anyone with basic knowledge of assembler can reverse-engineer a ROM, and stick a new one in place. Soldering the ROMs in would increase the buggerment factor, sure, but that did not stop me (see above.) Soldering in a new ROM socket requires two people, a solder sucker and a soldering iron. It can be done in roughly 15-20 minutes, if done reasonably carefully. Not even a challenge - especially if you can pick the lock in 7 seconds...
To be honest, the best security in this sort of situation is human security: Armed guards, always patrolling in pairs - who have been vetted by the military. If a hacker can't access the machine without getting shot to death, then it is secure - no matter how crap the firmware is.
Hackers have the right to vote too.
You appear to have a rather naive view: ``If a hacker can't access the machine without getting shot to death, then it is secure - no matter how crap the firmware is." Hackers must be able to vote!
@Hackers have the right to vote too.
I think you missed my point by quite a large margin - no, that's being kind; you weren't even close.
Of course hackers have the right to vote! Nobody was contesting that. However, what I thought was pretty obvious to everyone (but, evidently, I was wrong), was that hackers do not have the right to walk to up the machine, pry open the cover and fit their own firmware. Especially not out-of-hours.
Just because an ATM is alarmed, secured and valuable, does not mean you cannot walk up to it and use it to withdraw funds from your own bank account. Or, by your reasoning, should I now be bleating about "the right to access my money" if I can't have access to its operating system, hardware or comms?
Adding a paper trail doesn't change a blind thing.
You can press button A on the machine, have it print A on the till roll, and still record a vote for B. This is an inherent problem with any system that relies on counting a hidden *copy* of the votes, as opposed to the actual votes themselves.
Making the design open doesn't change much, either.
For a start, only a minority of the population at large can make sense of it. And for another thing, you can't be sure the machine on which you cast your vote is the same one you've examined, nor that it hasn't been altered in the meantime.
I have designed a direct-recording mechanical vote counter which is as close as you can get to universally comprehensible. Almost every part of the mechanism is visible through the transparent polycarbonate housing, only the number wheels of the individual candidate counters are obscured by distorting lenses, and you can see your counter and the total counter -- and no others -- increment as you press the button for your candidate. (No copy is made here: pressing the button directly increments the candidate's counter and the total counter together.) You can't vote multiple times, because the machine has to be primed (remotely, using a Bowden cable) by the presiding officer for each vote. At the close of polling, the machine can be locked unprimeable. Counting is then a matter of subtracting the "after" figures from the "before" figures, which were recorded before the polls opened and left in plain sight throughout.
But to be honest, you may as well just use pencil and paper, which *is* universally comprehensible and is not limited to first-past-the-post. Also, as long as the candidates themselves do the counting, there is a built-in system of checks and balances: none of the counters trust any of the others, so the only way they can agree on a result is if it is the correct result.
If you can directly program the i-cache over the allowed ROM area, you win. Maybe a hack program that uses return addresses (from an external buffer overflow exploit) calling the ROM code you want executed e.g. in libc.
Re: This is news?
Did you even read the article? This is much more than a mere reverse engineering hack. This hack employs a technique just recently discovered (described originally on x86 processors in a presentation for CCS 2007, and later adapted for any processor last year). This technique is dubbed "Return-Oriented Programming", alluding with tongue in cheek to the Object Oriented Programming paradigm.
The technique does not involve changing the ROM nor modifying its code in any way--as a matter of fact, the notable thing about this hack is that the ROM is designed precisely to prevent modifications or execution of arbitrary data.
The basic explanation of this technique is that it works by building chains of individual instructions (or sequences of instructions), called "gadgets", *already* in the executable code, and modifying the stack to cause the instruction pointer to execute those chains in sequence. Thus, you do not modify the code, but the control flow itself. It is called "return-oriented" (half-jokingly) because you depend on each gadget ending with a "ret" instruction in order to go back to the stack and redirect the instruction pointer.
I have more than a "basic knowledge of assembler", and even I found most of the explanation going over my head. If you're adventurous, check out the original white-paper which describes the technique:
It is indeed fascinating as it is clever.
Re: Other ways
It is a bit more subtle than that: They used that same technique, but instead of calling libc functions, they used the code within the ROM itself.
You appear to be playing on the wrong field
It's great to see you slander me ``I think you missed my point by quite a large margin - no, that's being kind; you weren't even close" when clearly you do not understand the problem!
``what I thought was pretty obvious to everyone (but, evidently, I was wrong), was that hackers do not have the right to walk to up the machine, pry open the cover and fit their own firmware. Especially not out-of-hours."
Yes, I respect this point. But you appear to be playing on the wrong field. Maybe the following example will help.
``Just because an ATM is alarmed, secured and valuable, does not mean you cannot walk up to it and use it to withdraw funds from your own bank account."
Again, you seem to be missing the point. The real attack is if I can walk up to an ATM machine and withdraw your money!
Relating back to e-voting. If I can use a voting machine to: cast your vote; cast multiple votes; erase the memory; .... and do so without ``prying open the cover and fit my own firmware" then I have won. Attacks against voting machines are real (read the literature).