“If you’re wondering about my opinion, I think we should stick to paper ballots.” ~ DEFCON 25 “Voting Village” hacker
Voting machine software security needs to be improved dramatically, and as soon as possible. U.S. voting machines are frighteningly easy targets for hackers. At this year’s DEF CON 25 convention it took only a few hours for white hat hackers to break into five different voting machines. One researcher cracked an Express Pollbook system within two minutes via CVE-2011-4109, a vulnerability in OpenSSL, an open source project contained in hundreds of thousands of applications to secure communications.
Yet another voter registration machine was found to use an unencrypted SQLite3 database (SQLite is one of the world’s most popular open source database engines) containing literally all the information that had been captured by the system. A real attacker could have easily obtained the machine’s entire voter database including names, addresses, and the last four digits of the voter’s social security number, as well as an electronic facsimile of each voter’s signature. The mind boggles at the havoc that could have been wreaked in the real world with that information in a hacker’s hands.
The examples I use center on open source software for a reason. There have been calls, including a recent editorial in the New York Times by National Association of Voting Officials executives, to replace voting systems running proprietary software with open source. But while there are good reasons why the public should have open access to the software recording our votes, open source will never be a magic bullet cure-all for voting security.
The problem—and the solution—goes far deeper than simply replacing proprietary software with open source
Open source software is not more secure than proprietary software. Nor is it less secure, as yet another example from DEF CON 25 proved when a hacker used a 14-year-old exploit in the Microsoft operating system to gain access to an unpatched voting machine. But the argument could be made that open source vulnerabilities are more prone to attack since those vulnerabilities are often widely reported. Open source exploits are also often published simultaneously with the announcement of a vulnerability. With open source components making up as much as 90 percent of the average commercial application, open source is a rich target for hackers; a single exploit could compromise multiple software and applications, giving attackers the biggest bang for their hacking chops.
Whether open source or proprietary code, most known vulnerabilities also have patches available on the date of their disclosure. Both the OpenSSL and Microsoft vulnerabilities had patches available for years that could have prevented the respective DEF CON voting machine attacks. The open source community generally does a good job in discovering and reporting vulnerabilities (over 3,600 of them were reported in 2016 alone), as well as issuing patches. But an alarming number of companies and individuals simply do not apply patches, sometimes due to lack of time, money, and resources or concerns that the patch might break a currently-working system.
In other cases, it’s a lack of insight—people or organizations are simply unaware of a critical vulnerability or its patch until they’re under attack. Another reason of concern for use of open source in voting machines is, that unlike most proprietary software, open source has a “pull” support model. That is, you are responsible for keeping track of the open source you use, as well as monitoring for vulnerabilities and installing fixes and updates for the open source your voting machine might use. Unless an organization is aware that a vulnerable open source component is in its voting machine software, it’s highly probable that that component will remain unpatched and open to exploit.
When it comes to open source the key to security is insight and control over the code in use
What's the solution? In the first DEFCON hacking example I cited, policies should have been in place to ensure that all open source components in use were up-to-date, all patches applied, and that the entity responsible for the system’s maintenance was monitoring for new vulnerabilities on a regular basis. In the second DEFCON hacking, a voting registration machine was easily compromised due to an unencrypted SQLite database. With open source policies to mitigate risks, that database would likely have been required to be encrypted when first placed on the machine.
Open source systems are already playing a role in some elections. New Hampshire has used them to allow disabled voters to fill out ballots online or on their phones. If the open source model for voting systems gains traction, effective management of open source security will become extremely important. Only with secure systems in place will election officials be able to maximize the benefits of open source while effectively managing its risks.