This may be stating the obvious, but I can log in to my online bank and presumably transfer money without any dollars ending up unaccounted. I (hopefully) can't go in and tamper with my balance. Are banks that much better at software, or have their flaws just not been discovered yet?
Why is it even necessary to upload a PDF file? Wouldn't an https: form be much better? Not to mention, the latter wouldn't get stored on the local filesystem or browser cache.
Are e-voting systems (including Diebold terminals) flawed by nature because they are built by non-techie organizations?
Major credit to the administration in this case for encouraging a public pilot/evaluation period.
It's pretty clear that the voting machine manufacturers are doing an awful job, and not even the basic security they need, but there are some particular difficulties to voting.
The major benefit of financial systems is that you can keep detailed logs and then audit them after-the-fact to figure out exactly what happened that is a problem. By the nature of secret ballots you can't have detailed logs for auditing, so the best you can hope for is printing something out on paper for the voter to verify.
Even if you have a paper ballot printed out you have the issue of most people not bothering to read what's printed on it (which, given the number of people on a US election ballot, I don't blame them for). You also have the issue of how to handle the case where the voter either made a mistake or there was a computer error and they need to change their vote from what is on their paper ballot. All of these issues can be solved, but there are a lot of them and each one you have to account for makes the human and computer protocols for voting more complicated, which is a serious issue.
"...but I can log in to my online bank and presumably transfer money without any dollars ending up unaccounted..."
This sort of example gets thrown around a lot and it's totally bogus. Banks are solving a much easier problem. To keep track of all the money they just need to make sure that every dollar is always tied to an account. Every transaction is logged.
A key requirement of a voting system is that it must be impossible to tie a vote to a person. This complicates things by at least an order of magnitude.
This kind of thing really irritates me. Why are we piloting anything? Brazil has this solved! They have a system with much harder restrictions than what the US currently has [1] and their system has been working fine for years. Don't write a new one, just buy theirs!
[1] You must be able to prove that everyone has voted because those who haven't receive a fine. You must not be able to tie a vote to the person who cast it because if that can be done it could lead to serious consequences for voters.
I learned about it from a Brazilian who used to work with these machines. I'll have to ask him for something online (thought it may mostly be in Portuguese).
Hrm, I've never tried to look it up before. I know about it from someone who used to work with it, but he told me other countries (including the US) had looked at it before with an eye toward purchasing.
The Brazilian election machines produce no paper receipt for the voter, nor any paper trail for a recount. There's no good way to audit an election result. Already this is a nonstarter for most election reform advocates.
I don't think a paper receipt is necessary if the system is trusted (the system gives feedback if it accepted your input). Recount paper trail is also a trust issue. The audit is a real issue, but I question how accurate the statement "There's no good way to audit an election result" is given the requirements to prove that everyone voted, etc.
In any case, at present it's up against something thrown together with Ruby on rails.
> I don't think a paper receipt is necessary if the system is trusted (the system gives feedback if it accepted your input).
Front-end: "vote counted!"
Back-end: vote redirected to /dev/null!
It's not immediately obvious to me how to make such a system transparent enough to convince the losers that they lost honestly. Cryptographic schemes may be able to solve it, but I think it's an open question whether they'll be convincing and secure in practice.
Yes, that could well be. My friend said the US did invest it, so they know about it. Personally I would rather have a system like Brazil has today as a place to at least start from rather than the horrible way votes are done in the US today.
This sort of security article rubs me the wrong way. It's obviously written for the layman; someone who doesn't know what a "shell injection attack" is or what it enables. Thus it goes into great detail about the things that are possible if you can run arbitrary code as root (or the app user, just as bad).
You can delete/alter the records! You can make fake records! You can record future activity without being noticed!
Of course for most of us here reading it, we already knew that as soon as you said "shell injection." They left something unvalidated, and you got shell access. Don't get me wrong, that's a huge problem. It's also a tiny fix. Your job isn't over. I want to know, say they fix that hole, which should take all of two seconds. How secure is the system now?
You say that you're "confident" you could have found another attack— do you mean you're sure there's another way to run unescaped shell commands? You're guessing. There's no evidence that there is unless you found one. You just don't know.
A much, much bigger problem with the system is tossed out in a single sentence: the attack went unnoticed for two days. Wholesale alteration and interception of data passed by completely unmonitored. That's not a problem with the app, that's a problem with the system, and the human processes behind it. And as long as the people who run it aren't secure, even the most watertight app is only going to last as long as it takes someone to pick up a phone.
You say that you're "confident" you could have found another attack-- do you mean...
What I read into that is that the prevention of shell injection attacks is so basic that it's likely that there are other vulnerabilities as well. For example, they're probably saving the name of the stored encrypted file into the database. Since they have a record of not checking the file extension, I'd look for the analogous SQL injection vulnerability when they do the DB insert.
Or conversely, the shell injection vulnerability is fairly obscure — forgetting to validate the extension, not something you'd usually think of as user-provided input. This indicates that there was a modicum of concern for validation, they just weren't approaching it rigorously.
It's a cause for suspicion of further vulnerabilities, but not confidence. One vulnerability is not two vulnerabilities.
"Although we may not all agree with some choices made in how overseas voters are digitally empowered to participate in elections (and the OSDV Foundation for one, remains against widespread application of remote online voting services), I believe that when the efforts of the District are fairly examined, there will be consensus that Rokey Suleman and his team are making a decent effort to do the right thing."
Now the original post indicates security concerns spread throughout the system, not just the remote ballot return portion, so it could be there are wider architectural problems. It sounds as if there was significant concerns about this remote return piece, from a key component maker, even before the test started.
To be honest, I wasn't surprised at all as soon as I saw "It's written using (...) Ruby on Rails (...) and (...) MySQL (...)" - seriously, for a project where pretty much the only requirement is security, why go with such a complicated stack?
Just run a couple hundred lines of code on a high-security processor (or a custom-made hardened chip); if you really must allow internet voting, you could at least take a highly-secure OS and wire up a trusted HTTP server to a well-audited hundred-line CGI program.
Security surely isn't the only requirement. There was a relatively modest budget and a firm deadline.
But moreover, it's silly to blame the platform. CGI scripts were getting exploited through shell injection vulnerabilities before most of the people here were born.
Possibly a good project, but seems odd to come from FTT. This seems like more than just freedom to tinker with devices you own and extend into outright security vulnerability scanning.
I'm not sure that there is an exact overlap between the people who believe in freedom to tinker with devices you own, and who believe in security testing in this manner.
Why is it even necessary to upload a PDF file? Wouldn't an https: form be much better? Not to mention, the latter wouldn't get stored on the local filesystem or browser cache.
Are e-voting systems (including Diebold terminals) flawed by nature because they are built by non-techie organizations?
Major credit to the administration in this case for encouraging a public pilot/evaluation period.