Page 35
There are also good arguments for eliminating AccuBasic interpreted code entirely from voting system software. The FEC 2002 Voluntary Voting System Standards expressly forbid interpreted code in section 4.2.2. Perhaps the standard writers had in mind forbidding only powerful, interpreted programming languages, such as Visual Basic, and not relatively benign and limited rendering languages such as HTML. AccuBasic falls somewhere in the middle on the more benign side (assuming the interpreter bugs are xed). But the text of the standard is pretty clear, and the same language from the 2002 standards has been preserved in the EAC's new successor standard, the Voluntary Voting Systems Guidelines, as section 5.2.2. To be in compliance it would seem that AccuBasic would have to be eliminated, or the standard would have to be changed.
Thanks, Gary.
It seems the VSTAAB didn't completely ignore it.
But I want to point out this out from the opening summary:
The questions we addressed are these:
What kinds of damage can a malicious person do to undermine an election if he can arbitrarily modify the contents of a memory card?
How can the possibility of such attacks be neutralized or ameliorated?
The scope of our investigation was basically limited to the above questions. We did not do a comprehensive code review of the whole codebase, nor look at a very broad range of potential security issues. Instead, we concentrated attention to the AccuBasic scripting language, its compiler, its interpreter, and other code related to potential security vulnerabilities associated with the memory cards.
Similarly, the CIBER report says this on page 4:
OVERVIEW AND APPROACH
The CIBER Huntsville and CIBER Global Security teams were tasked with performing a combination of testing and analysis of the Diebold Election System’s Source Code to identify security and functionality vulnerabilities. The testing was structured to identify and evaluate as much potential vulnerability as possible within a reasonable/controlled level of effort.