More on DC Voting Test

October 6, 2010

Earlier this week, I posted a note about the test of an Internet absentee-voting system, conducted by the Washington DC Board of Elections and Ethics.  The test was suspended after a few days, because the system’s integrity had been compromised by a group of security researchers at the University of Michigan.   The leader of the Michigan group, computer science Professor J. Alex Halderman, has now posted a report on the test, at the Freedom to Tinker blog, sponsored by Princeton’s Center for Information Technology Policy.  His post gives a more in-depth look at the test than the reports I have seen in the mainstream press.

Prof. Halderman starts by saying that running a test of this kind is a good thing, something security experts have urged for new voting systems, although this particular test might have been slightly better organized.

This is exactly the kind of open, public testing that many of us in the e-voting security community — including me — have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days’ notice.

He also provides some information about the system being tested.  It is a Web application, developed as an open-source package by the TrustTheVote project.   It uses the Ruby on Rails framework, running on an Apache / MySQL platform.  The use of open source for voting systems is also an approach that has been strongly recommended by folks in the security community — closed-source voting systems are suspect, for the same reasons that closed-source cryptography is.

So, as I suggested in my earlier post, DC election officials did many things right in putting together a system and setting up the test.  The team was able to compromise the system’s integrity within about 36 hours, but that should be taken as an indication of how tricky the problem is.  As Prof. Halderman writes,

It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today’s security technology.

The particular flaw that the Michigan team exploited is of a fairly common type: failure to “sanitize” input data that are provided by the user.  I won’t repeat the details, which are outlined in Prof. Halderman’s post, but essentially they involved providing a maliciously-formed file identifier, which was in turn used as an argument in a shell command used by the server.  One specific technique, for example, embedded the construct $(command) in a file identifier. As bash(1) hackers will know, this runs command and substitutes its standard output for the source expression.  Experience suggests that, when there is one basic flaw like this, there are likely to be others.

Still, it is important to remember that we run tests because we know that software development is a far from perfect process.  It is enormously better that problems like this be discovered in testing, rather than after an actual election has been conducted.

Prof. Halderman says, in conclusion, that the team is preparing a paper describing their work in more detail.

%d bloggers like this: