Thursday, August 02, 2007

California source code study results

The source code team reports for the California Top to Bottom review of Diebold, Hart and Sequoia's voting systems are now online. These reports are comprehensive and detailed and should mark the end of the use of these voting machines in public elections. From the executive summaries:

Our analysis shows that the technological controls in the Diebold software do not provide sufficient security to guarantee a trustworthy election. The software contains serious design flaws that have led directly to specific vulnerabilities that attackers could exploit to affect election outcomes.

Many of these attacks can be mounted in a manner that makes them extremely hard to detect and correct. We expect that many of them could be carried out in the field by a single individual, without extensive effort, and without long-term access to the equipment.

We found significant security weaknesses throughout the Sequoia system. The nature of these weaknesses raises serious questions as to whether the Sequoia software can be relied upon to protect the integrity of elections. Every software mechanism for transmitting election results and every software mechanism for updating software lacks reliable measures to detect or prevent tampering.

I am most familiar with the Diebold system, and one thing that stands out is how every time there is another study of the Diebold code, more security problems come to light. Here are a few issues that this report identified:

  • The audit log does not adequately detect malicious tampering.
  • Buffer overflows in unchecked string operations allow arbitrary code execution.
  • Integer overflows in the vote counters are unchecked.
  • Multiple buffer overflows in .ins file handling allow arbitrary code execution on startup.
  • Setting a jumper on the motherboard enables a bootloader menu that allows the user to extract
    or tamper with the contents of the internal flash memory.
  • Keys used to secure smart cards and election data are not adequately protected.
  • The machine does not adequately protect the supervisor PIN. (This same problem was identified in this week's Florida report)
  • Votes can be swapped or neutralized by modifying the defined candidate voting coordinates
    stored on the memory card.
  • OpenSSL is not initialized with adequate entropy
  • ...

    And the list goes on. Dozens of such vulnerabilities are identified; I just picked a few at random from the list. This is the code that Diebold produced after they claimed to have fixed the vulnerabilities we found in 2003 and that Ed Felten's group identified last year. The backend GEMS system has its own serious problems as well. It is clear that they are simply not qualified to build these kinds of machines.

    As I read the three new reports, I could not help but marvel at the fact that so many places in the US are using these machines. When it comes to perscription medications, we perform extensive tests before drugs hit the market. When it comes to aviation, planes are held to standards and tested before people fly on them. But, it seems that the voting machines we are using are even more poorly designed and poorly implemented than I had realized.

    The more these machines are studied, the worse they look.