April 19, 2014

avatar

Google Glass vuln in QR codes and ballot marking applications

Reading recently about a vulnerability in Google Glass that can be exploited if a victim takes a picture of a malicious QR code made me think about one of the current trends in absentee balloting. A number of localities in the US are trying out absentee ballot schemes where a voter goes to a website and makes his/her choices through a web form, then prints out a ballot that contains his/her choices as a marked ballot plus a barcode (typically a 2D QR code). The ballot is then mailed back to the locality with whatever signature forms are required. When the ballot arrives at the locality, election officials scan the QR code to duplicate the ballot showing the voter’s choices, (hopefully) compare that the voter selections actually match the marks, and then the ballot goes forward. (Commercial products with this feature include Everyone Counts and Scytl.)
[Read more...]

avatar

“E-Voting: Risk and Opportunity” Live Stream Tomorrow at 1:30pm Eastern

Despite the challenges due to Hurricane Sandy earlier this week, the Center for Information Technology Policy at Princeton is still hosting “E-Voting: Risk and Opportunity,” a live streamed symposium on the state and future of voting technology. At 1:30pm (Eastern) on November 1, 2012, electronic voting experts from across the United States will discuss what to expect on Election Day, how we might build a secure, convenient, high-tech voting system of the future, and what policymakers should be doing. The current U.S. e-voting system is a patchwork of locally implemented technologies and procedures — with varying degrees of reliability, usability, and security. Different groups have advocated for improved systems, better standards, and new approaches like internet-based voting. Panelists will discuss these issues and more, with a keynote by Professor Ron Rivest. You can watch the event streamed live at https://citp.princeton.edu.

Date: Thursday, November 1, 2012
Time: 1:30 PM – 5:00 PM (Eastern)
Location: streaming online at https://citp.princeton.edu
Hashtag: ask questions and add comments via Twitter at #PrincetonEvoting

Archived video now available:

avatar

Which States have the Highest Risk of an E-Voting Meltdown?

This post is joint work by Joshua Kroll, Ian Davey, Alex Halderman, and Ed Felten.

Computer scientists, including us, have long been skeptical of electronic voting systems. E-voting systems are computers, with all of the attendant problems. If something goes wrong, can the problem be detected? Can it be fixed? Some e-voting systems are much riskier than others.

As the 2012 Presidential election approaches, we decided to evaluate the risk of a “meltdown scenario” in which problems with electronic voting equipment cause a state to cast the deciding electoral college vote that would flip the election winner from one candidate to the other. We’re interested in the risk of these technological problems, weighted by the relative voting power of each voter. So for example, here in New Jersey we use direct-recording electronic voting machines that have been found by a court to be inadequate, but with Obama polling at +14% it’s not likely that a snafu with these machines could change the entire state’s outcome. But in swing states that poll closer to even, like Virginia (where your voting machines can be modified to play Pac-Man), an electronic voting mix-up could have a much bigger impact. So, which states have the greatest risk of an e-voting meltdown affecting the result of the 2012 Presidential election?

[Read more...]

avatar

Hacking the D.C. Internet Voting Pilot

Editor’s Note: On November 1, 2012, Alex Halderman and several other experts participated in a live streaming symposium on the state of electronic voting in Election 2012: E-Voting: Risk and Opportunity (archived video now available). The event was hosted by the Center for Information Technology Policy at Princeton.

The current U.S. e-voting system is a patchwork of locally implemented technologies and procedures — with varying degrees of reliability, usability, and security. Different groups have advocated for improved systems, better standards, and new approaches like internet-based voting. Panelists will discuss these issues and more, with a keynote by Professor Ron Rivest, one of the pioneers of modern cryptography.

[Update (6/2012): We've published a detailed technical paper about the D.C. hack.]

The District of Columbia is conducting a pilot project to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they’ve invited the public to evaluate the system’s security and usability.

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. I assembled a team from the University of Michigan, including my PhD students, Eric Wustrow and Scott Wolchok, and Dawn Isabel, a member of the University of Michigan technical staff.

Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots. In this post, I’ll describe what we did, how we did it, and what it means for Internet voting.

D.C.’s pilot system

The D.C. system is built around an open source server-side application developed in partnership with the TrustTheVote project. Under the hood, it looks like a typical web application. It’s written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database.

Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site, http://www.dcboee.us/DVM/, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots.

A small vulnerability, big consequences

We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database.

The problem, which geeks classify as a “shell-injection vulnerability,” has to do with the ballot upload procedure. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG. Internally, the server executes the command gpg with the name of this temporary file as a parameter: gpg […] /tmp/stream,28957,0.pdf.

We realized that although the server replaces the filename with an automatically generated name (“stream,28957,0” in this example), it keeps whatever file extension the voter provided. Instead of a file ending in “.pdf,” we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename “ballot.$(sleep 10)pdf” would cause the server to pause for ten seconds (executing the “sleep 10” command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user.

Our demonstration attacks

D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks:

  • We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots.
  • We modified all the ballots that had already been cast to contain write-in votes for candidates we selected. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way.
  • We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy.
  • To show that we had control of the server, we left a “calling card” on the system’s confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here’s a demonstration.

Stealthiness wasn’t our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes — an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song.

Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky.

D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8.

What this means for Internet voting

The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We’ve found a number of other problems in the system, and everything we’ve seen suggests that the design is brittle: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I’m confident that we would have found another way to attack the system.

None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. 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.

We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper.


Professor J. Alex Halderman is a computer scientist at the University of Michigan.

avatar

Tinkering with Disclosed Source Voting Systems

As Ed pointed out in October, Sequoia Voting Systems, Inc. (“Sequoia”) announced then that it intended to publish the source code of their voting system software, called “Frontier”, currently under development. (Also see EKR‘s post: “Contrarianism on Sequoia’s Disclosed Source Voting System”.)

Yesterday, Sequoia made good on this promise and you can now pull the source code they’ve made available from their Subversion repository here:
http://sequoiadev.svn.beanstalkapp.com/projects/

Sequoia refers to this move in it’s release as “the first public disclosure of source code from a voting systems manufacturer”. Carefully parsed, that’s probably correct: there have been unintentional disclosures of source code (e.g., Diebold in 2003) and I know of two other voting industry companies that have disclosed source code (VoteHere, now out of business, and Everyone Counts), but these were either not “voting systems manufacturers” or the disclosures were not available publicly. Of course, almost all of the research systems (like VoteBox and Helios) have been truly open source. Groups like OSDV and OVC have released or will soon release voting system source code under open source licenses.

I wrote a paper ages ago (2006) on the use of open and disclosed source code for voting systems and I’m surprised at how well that analysis and set of recommendations has held up (the original paper is here, an updated version is in pages 11–41 of my PhD thesis).

The purpose of my post here is to highlight one point of that paper in a bit of detail: disclosed source software licenses need to have a few specific features to be useful to potential voting system evaluators. I’ll start by describing three examples of disclosed source software licenses and then talk about what I’d like to see, as a tinkerer, in these agreements.

The definition of an open source software product is relatively simple: for all practical purposes, anything released under an OSI-approved software license is open source, especially in the sense that one who downloads the source code will have wide latitude to copy, distribute, modify, perform, etc. the source code. What we refer to as disclosed source software is publicly released under a more restrictive license.

Three Disclosed Source Licenses

We have at least three examples of these kinds of licenses from voting systems applications:

  • Sequoia: Sequoia’s license is a good place to start, due to its relative simplicity. It grants the user a limited copyright and patent license for “reference use”, which is defined as (emphasis added):

    “Reference use” means use of the software within your company as a reference, in read only form, for the sole purposes of reviewing and inspecting the code. In addition, this license allows inspection of the code to enhance, or develop ancillary software or hardware products to enhance interoperability of your products with the software. Distribution of this source is allowed provided that this license, and all copyright notices remain in-tact.

    (If you’re a developer and you suspect that you’ve seen this license before, you might have. It’s appears identical to Microsoft’s Reference Source License (Ms-RSL) which is used to distribute things like the .NET Framework under their shared source program. That makes a good deal of sense since Frontier is written in .NET!)

  • Everyone Counts1: Everyone Counts’ (E1C) license is curious. (Unfortunately, I don’t see a copy of this license posted publicly, so I’ll just quote from it.) I say curious mostly because of the flowery language it includes, such as (emphasis added):

    The sources are provided for scrutiny in the same spirit as any member of the public may apply and obtain escorted access to a public election, and is entitled free and open access to election processes to satisfy his or herself of the veracity of the claims of electoral officers and that the process upholds democratic principles. In the same way, the elections observer is not permitted to capture and publish or otherwise make public the processes of the physical count at an election, the same applies for these sources.

    I’m not sure what that last part is about; it’s pretty well accepted—in the U.S.—that “making public the processes of the physical count” is a basic requirement of democratic elections.

    Anyway, on to the substance: It’s a pretty simple license, although more complex than the Sequoia license. The core of this license allows the user to “examine, compile and execute the resulting bytecodes” from the Java source code. It specifies that the user is allowed these rights for the purpose of “analysis forming electoral scrutiny”, which is a difficult phrase to parse. The license suffers from a lot of such wording problems, which make it pretty hard to understand.

  • VoteHere2: The VoteHere license agreement is considerably more complex and looks more like a commercial software license agreement. My favorite part, of course, is:

    TO AVOID ANY DOUBT, THIS SOFTWARE IS NOT BEING LICENSED ON AN OPEN SOURCE BASIS.

    The central component is that VoteHere restricts all your rights, other than copying and modifying the source code for evaluation purposes, and owns any derivative works you create from the source code. It has some other quirks; for example, the license, despite being a click-wrap license, has a hard term of 60 days after which all copies and such must be destroyed. (Presumably, you could click through again after 60 days, and restart the term.)

What Does an Evaluator Need in a License?

Each of these licenses has its strengths and weaknesses. The Sequoia license doesn’t seem to permit modification of the source code but is relatively simple and allows distribution of Sequoia’s unmodified code. The VoteHere and E1C licenses, however, understand that modification may be necessary to evaluate the software (VoteHere even includes a license to the system’s documentation, an essential but often overlooked part of evaluating source code.). The VoteHere license is extremely onerous in that it is very strict and places heavy burdens on the evaluator. The E1C license is flowery and hard to understand, but seems simple at the core and seems to understand what evaluators might need in terms of modifying the code during evaluation.

This raises a good question: What rights, exactly, do evaluators need to examine source code? Practically, it depends on what they want to do. If all they want to do is human line-by-line source code analysis, than a “read-only” license like Sequoia’s is probably fine. However, what about compiling the source code with debugging flags set? What about modifying the software to see how another piece of it performs?

Listed (sort of) in terms of the rights granted by U.S. copyright law, here are some thoughts:

  • Examining: If it doesn’t require making a copy, simply looking at the source code with your eyeballs is not covered by copyright law. So licenses that allow you to “examine” the source code aren’t really granting much, unless they define “examine” to mean something that implicates exclusive rights (which are listed in 17 USC 106).

  • Copying: Of course, downloading and loading source code in an IDE or text editor will make a number of copies, so at the most basic level, evaluators will need to be able to do this. Backup copies are also a necessity these days and VoteHere’s license contemplates this by allowing “reproduc[tion] for temporary archive purposes”.

  • Modification: Evaluators will need some ability to modify the code. Either simply in compiling it to execute it or the next logical step which involves special types of compilation such that “debugging flags” are set (this includes special flags and metadata in the compiled code which allows debugging tools to step through the program, set break points, etc.). Some types of evaluation require minor modifications to integrate the code into an analysis method; a simple example is just changing pieces of the code to see how other pieces will respond or inserting code that prints to the screen (which is a very primitive but useful form of debugging!). Each of these actions creates a derivative work, so that should be explicitly allowed in these licenses.

  • Distribution: At first, you might not think that evaluators would need much in the way of rights to distribute the source code. However, distributing modified works, such as a patch that fixes a bug, could be very useful. Also, being able to share the code if the official means of getting the code goes dark is often useful; for example, having a portal of voting system source code would provide this “mirroring” capability and could also allow creating a “one-stop shop” for tinkerers and researchers who would point research tools at these code repositories for analysis.

  • Performance: Both reading the source code out loud or showing it publicly are also implicated by copyright law. Why would an evaluator want to do this? Well, imagine that you’ve completed an analysis of a disclosed source code product and you want to write up your findings. It’s often useful to include snippets of code. Small snippets would likely be covered by fair use, but it’s always nice to not have to worry about that and have explicit permission to at least “display” and possibly “read aloud” source code in these contexts (think accessible or podcast versions of a report!).

  • Executing: There are a line of legal cases that say that “executing” a program is protected by copyright law due to a copy of the object code being loaded into memory at run time. Hopefully, there’s no reason to believe that permission to make copies, the first and most basic need of evaluators highlighted above, wouldn’t also include this interpretation of “executing” the code.

Outside of these types of exclusive rights, there’s also something to be said for simplicity. The simplicity of the BSD license is a great example: it’s widely used and understood to be very generous and easy to understand. The Sequoia license (being the Ms-RSL license) is very simple and easy to understand. The E1C license is not particularly complex, but it’s substance is hard to understand (again, apologies that I cannot post the text of that license). The VoteHere license is easy to understand but very complex and extremely onerous in terms of the burden it places on evaluators.

As I finally finish writing this, I’m told Sequoia might be interested in modifying their license. That would be a wonderful idea and I hope these thoughts are useful for modifying it. I do wonder how they’ll be able to modify the license and still distribute parts of the .NET Framework under a new license. Perhaps they’ll specify that the .NET parts are under the Ms-RSL and any Sequoia-sourced source code is under Sequoia’s new license. We’ll see!

1 Everyone Counts sells internet voting solutions, which are scary as hell to a lot of us.

2 VoteHere was a company, now seemingly out of business, that made a number of products including a cryptographic add-on module, Sentinel, for the Diebold/Premier AccuVote-TS voting system and a absentee ballot tracking system.