Sequoia Source Review - Notes by Jerry Berkman
Since we use Sequoia equipment in Alameda County, CA, I decided to read the Sequoia source code review: http://www.sos.ca.gov/elections/voting_systems/ttbr/sequoia-source-public-jul26.pdf It is very long; I quit after the main text and skipped the Appendices. I thought I'd summarize some of the findings. Many are unbelievable. Sequoia must have been isolated from good programming practices and modern security practices for 10 years. For most of the below, I did cut and paste. A few places, I summarized instead. - Jerry Executive Summary 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. Many of the most significant vulnerabilities we found - those likely to be especially useful to an attacker seeking to alter election results - arise from four pervasive structural weaknesses: - Data Integrity. The Sequoia system lacks effective safeguards against corrupted or malicious data injected onto removable media, especially for devices entrusted to poll workers and other temporary staff with limited authority. - Cryptography. Many of the security features of the Sequoia system, particularly those that protect the integrity of precinct results, employ cryptography. Unfortunately, in every case we examined the cryptography is easily circumvented. - Access Control. The access control and other computer security mechanisms that protect against unauthorized use of central vote counting computers and polling place equipment are easily circumvented. - Software Engineering. The software suffers from numerous programming errors, many of which have a high potential to introduce or exacerbate security weaknesses. In general, the software does not reflect defensive software engineering practices normally associated with high-assurance critical systems. Ch. 3 Systemic and Architectural Issues 3.1 Data Integrity much of the data that determines the outcome of an election - precinct results, voting machine configuration files, ballot definitions, and so on - reside on removable media that may pass through several sets of hands. Unfortunately, the software mechanisms that safeguard these critical election components are largely ineffective or absent from the Sequoia system, making the system completely dependent on the physical security of its components The standard audit mechanisms used in California (such as 1% recounts and parallel testing) may be only marginally effective in detecting and recovering from the attacks against data integrity we discuss in this section. 3.1.1 Integrity of Precinct Results, Edge Results Cartridges Besides altering the results for the precinct, additional attacks are also possible. Counterfeit extra returns for precincts other than the one from which a cartridge originated can be added to a Results Cartridge. These extra results are added to the other precincts' totals when read into WinEDS but are not listed in several of the tally audit reports that WinEDS generates, making the attack difficult to detect and isolate. See Section 4.1.23. Finally, there are potential avenues for corrupt Results Cartridges to attack the WinEDS system itself. 3.1.1 Integrity of Precinct Results, Insight The behavior of Insight optical ballot scanners is controlled by firmware and ballot definition data stored on the same removable MemoryPacks that hold the machines vote tallies. 3.1.2 Integrity of Precinct Voting Firmware and Software, Edge Edge touchscreen DREs are controlled by firmware and ballot definition files contained on (or loaded through) removable PCMCIA cartridges Several aspects of the VVPAT behavior, including the speed at which it scrolls, the density of the print, and so on, are under the control of the Edge firmware and thus reduce the value of the VVPAT record in the presence of malicious Edge firmware. Corrupted firmware could be configured in a way that prints misleading information on the VVPAT printoutorthatpreventsthe voter from clearly seeing how their vote is recorded on the VVPAT printout 3.1.2 Integrity of Precinct Voting Firmware and Software, HAAT and Card Activator The USB- and PCMCIA-based configuration mechanisms used on the HAAT and Card Activator provide a rich vector for viral propagation of malicious firmware, and potentially for corruption of the Edge and WinEDS. 3.1.3 Detection and Auditing of Corrupted Firmware Two audit protocols are routinely employed in California elections to detect corrupted voting machine firmware: Parallel Testing and 1% Recount Audits. Unfortunately, neither protocol is likely to detect the precinct-based firmware corruption attacks against Edge DREs discussed in this report. 3.1.3 Detection and Auditing of Corrupted Firmware, 1% Recount Audits It may be possible to construct Edge firmware that prints incorrect VVPAT records (matching the incorrectly recorded electronic records) but in a way that escapes the notice of voters when they cast their ballots. 3.1.3 Detection and Auditing of Corrupted Firmware, Parallel Testing While this procedure may detect certain kinds of unreliable or corrupt firmware delivered from the vendor, it will not detect the precinct-based firmware corruption attacks discussed in this chapter. In these attacks, the corrupt firmware is loaded after the machines have been delivered to the precincts, and so escape the possibility of being subject to parallel tests. 3.2 Cryptography Many of the security features of the Sequoia software, particularly those that verify the integrity of precinct results and that safeguard against the introduction of malicious software and firmware, employ cryptography. Unfortunately, in every case we examined the cryptography provides only ineffective protection. This is a pervasive failure, with fundamental cryptographic errors throughout the software. We could not find a single instance of correctly used cryptography that successfully accomplished the security purposes for which it was apparently intended. The cryptographic protection in the Sequoia system was effectively neutralized by several poor design decisions compounded by a range of implementation errors. 3.2.1 Hardcoded Keys Virtually all cryptographic key material in the Sequoia system is permanently hardcoded into the software source code (and is apparently identical in all hardware shipped to different jurisdictions). ` 3.2.2 Poor Algorithms and Protocols every one of the cryptographic algorithms used in the Sequoia system is either obsolete and known to be weak, is an ad hoc design with obvious flaws, or is used in a manner that does not provide the stated or required security properties. 3.3.1 Access Control in Central Elections Software Because the Sequoia design enforces access control only in the client, the extensive access control system in WinEDS can be completely circumvented by communicating directly with the database. 3.3.1 Data Wizard Any WinEDS user, even a user with all 615 access rights turned off, can use the Data Wizard. The Data Wizard is incorrectly implemented; it fails to import data. However, it can erase entire tables. 3.3.1 Platform Access Control The Optech 400C system was set up with only one user account, WinETP, with administrator access and no password. On the laptop running the WinEDS client and the SQL server, the user Tally running WinEDS had sufficient permissions to install additional software. These privileges allow any WinEDS or WinETP user logged on to the respective system to have full control over these machines, regardless of their privileges in WinEDS or WinETP. My Summary: Optech 400C as provided by Sequoia had lots of extra software including "Windows Movie Maker, MSN Gaming Zone, NetMeeting, Outlook Express, Minesweeper, and 3-D Pinball"; it really should have minimal software. 3.3.2 Access Control in Polling Station Equipment software on the HAAT or Card Activator will not prevent someone with minimal access from replacing the firmware of the device. Such replacement can be performed without any need to physically access its internals. In other words, tamper-evident seals are insufficient to protect the integrity of these devices. 3.4 Defensive Software Engineering 3.4.1 Complexity, Code Size The Sequoia system consists of approximately 800,000 lines of code in 10 different languages, including 4 different assembly languages. In addition, the system makes use of at least 6 interpreted languages. The sheer size of the Sequoia code base and the breadth of languages make understanding and analysis difficult in any time frame. 3.4.2 Interpreted Code none of this interpreted code is reviewed as part of the normal certification process. My Summary: they did not review the six interpreters/compilers. 3.4.3 Input Validation My Summary: Input validation is weak or missing. The code often doesn't check for buffer overflows, integer overflows, and format string errors. 3.4.4 Implicit Assumptions 3.4.5 Error and Exception Handling the weak input validation (as described in Section 3.4.3) is often insufficient in preventing errors produced in one component from cascading to another. 3.4.6 System Unreliability We found using WinEDS, even in a normal context, unreliable. If users have an expectation of unreliability, an attacker does not need to be concerned about writing exploit code with sophisticated cleanup routines. 3.4.7 Documentation Inconsistency Insufficient Documentation Inconsistency Across Systems Examples of Substantive Inaccuracy: the WinEDS Software Specification claims that the system uses Triple DES encryption for the early vote collection process, when in fact the implementation in source is only single DES. 3.4.8 Unused Code My Summary: dangerous from a security point of view. 3.4.9 Software Testing The test specifications we were provided seem to focus on getting the overall correct result given correct input. However, exploiting the behavior of a system when given incorrect or malicious input is the primary attack vector used by malicious users. Thus, testing with incorrect input is essential. My Summary: there should be independent tests of each modules, but these were not given to the team, and probably don't exist as there are many routines that do not work, e.g. "Change Password" for administrator, import function of Data Wizard tool in WinEDS, etc. The prevalence and severity of problems present in the Sequoia system suggest that the independent testing process failed to detect or address these issues as well. Chapter 4 - Specific Weaknesses and their Implications 4.4.11 Provisional voting mode is poorly indicated. When voting provisionally on an Edge using a provisional Voter Card, the only indication to the voter that the vote is being cast provisionally is the string - Provisional Voter - on the VVPAT receipt. Combined with weaknesses in Section 4.4.7 and Section 4.5.4, official votes may be recorded provisionally without detection by the voter or poll worker. This effectively removes the votes from the official tally. Election officials will be unable to resolve these votes since no voter identification will be associated with the provisional voter ID. This provides an avenue for attackers to both add and remove votes from the official tally. Section 5.2.2 discusses possible attack scenarios using provisional voting mode. 4.4.12 Malformed font files allow loading of arbitrary files. Using a malformed font file on a Results Cartridge, it is possible to copy arbitrary files outside of the root directory. 4.4.16 Memory allocation may cause integer overflows. My Summary: Edge uses customized versions of calloc() and malloc() with bugs in them. Customized versions are a bad idea. 4.4.17 Bar codes on VVPAT receipt are problematic. If enabled, the voter-verified paper audit trail includes bar codes which have a numeric representation of voter information and votes cast. 4.6.3 Integrity checking of the HPX and APX is performed by the HPX and APX themselves, respectively. A modified HPX chip or a MemoryPack with a modified APX could skip their own integrity checks and proceed to take control of the Insight (see Section 4.6.2). 4.9.1 Windows will execute autorun files on U3 USB smart drives. The Windows laptop provided to the Red Team executes autorun files from U3 USB start drives automatically. If U3 USB smart drives are used and reused to prepare HAATs for an election, a compromised HAAT can take control over WinEDS. 4.9.2 WinEDS Windows version and configuration unspecified. The precise version of Windows over which WinEDS runs is not specified, nor are the elements that should be included in or excluded from its configuration. Because the precise platform and configuration is not specified, there is no way to assure that potential security vulnerabilities introduced by interactions between WinEDS and various Windows bugs and features do not occur.