User: Password:
|
|
Subscribe / Log in / New account

Security

Securing our votes

By Jake Edge
August 8, 2007

This has been a bad few weeks to be a voting machine vendor. Three separate governments, California, Florida and the UK looked at the devices and have come to remarkably similar conclusions. The machines they looked at are poorly designed, poorly implemented and subject to a wide variety of security threats. None of the studies mentioned it, but it is likely that the machines looked great.

The most comprehensive study was done by California Secretary of State Debra Bowen's office. That study looked at three electronic voting systems, each from a different manufacturer. Each system had three separate teams investigating, one looking at the source code, a "red team" that had physical access to the device and an accessibility team. Their conclusions were not surprising to anyone who has paid attention to this issue over the years.

All three of the voting machine systems were found to be sorely deficient by all three teams. Even accessibility, which is one of the major benefits touted by electronic voting advocates, was found lacking:

Although each of the tested voting systems included some accessibility accommodations, none met the accessibility requirements of current law and none performed satisfactorily in test voting by persons with a range of disabilities and alternate language needs.

Though it is certainly terrible not to meet the needs of some individual voters, safeguarding the election process and accurately reporting the vote totals need to be higher priorities. Since they obviously had not successfully completed the accessibility task, one would hope they were able to secure the voting process. Unfortunately, they could not get the primary job done right either.

The red team reports were released first and the conclusions were devastating:

The red teams demonstrated that the security mechanisms provided for all systems analyzed were inadequate to ensure accuracy and integrity of the election results and of the systems that provide those results.

The teams were able to defeat the physical security of the voting machines, modify or overwrite the software in the machines as well as subvert the tabulation machines in order to provide incorrect vote counts. All of this just by having access to the machines themselves; the same access that election officials, poll workers and, to a lesser extent, voters, have.

Several days later, the source code teams' reports were released and, at that point, were almost anti-climactic. Unsurprisingly, they found numerous, hideous source code flaws in all three systems. Buffer overflows, hard coded passwords ('diebold' being a particularly difficult one to guess), misuse of encryption, integer overflows (wrapping vote counts to negative or zero perhaps); the list goes on an on. It is as if the voting machine vendors are completely unaware of the last twenty (or thirty or forty) years of software security flaws.

In reality, they are most likely not unaware, they are just arrogant. Diebold, Hart and Sequoia (the companies whose machines were studied) do not depend solely on their technical "prowess" to win bids for providing voting machines, politics plays a huge role. These are well connected companies. It also helps that they are all uniformly bad, there are literally no secure choices for a government agency to make.

Florida's study only covered Diebold equipment, but it echoed the findings in the California study. Avi Rubin of Johns Hopkins University, who participated in a 2003 study of Diebold's voting machine, notes:

So, Diebold is doing some things better than they did before when they had absolutely no security, but they have yet to do them right. Anyone taking any of our cryptography classes at Johns Hopkins, for example, would do a better job applying cryptography.

One of the bigger problems found was that Diebold assigned cryptographic keys to each voting machine that is derived from an MD5 hash of the machine's serial number. Rubin again:

This is arguably worse than having a fixed static key in all of the machines. Because with knowledge of the machine's serial number, anyone can calculate all of the secret keys. Whereas before, someone would have needed access to the source code or the binary in the machine.

The UK also released reports on the outcome of electronic voting trials held in May. The overall summary of the trial, was, once again, not very favorable:

The level of implementation and security risk involved was significant and unacceptable. There remain issues with the security and transparency of the solutions and the capacity of the local authorities to maintain control over the elections.

This was not the result of security professionals analyzing the systems for flaws, but was instead noted in actual trials of the equipment in an election.

The California study was quite well done and well thought out, except for one thing: it was done long after the equipment was bought and used in elections. This is the kind of study that needs to be done before buying the equipment. Due to the conclusions of the study, Bowen revoked the certification of the equipment from all three vendors, but immediately had to conditionally re-certify them as a practical matter. Even with a six month lead time, replacement systems (either electronic or of some other kind) could not be deployed before the 2008 California presidential primary voting.

The reaction to the California study by the manufacturers was typical. It is the same reaction they have had to each and every study done of the security of their devices: trivialize it. Each released a statement in reaction to the study conclusions, essentially admitting the flaws, but claiming that any "laboratory study" would find vulnerabilities. According to these vendors, it is impossible to make a secure voting system.

As they certainly know, no one is asking these vendors to break the laws of physics or to produce perfectly secure code. It would appear that they expend far more effort in deflecting criticism and lobbying various legislative bodies than they spend trying to secure their code and equipment. It is not necessary that the equipment be tamper-proof, merely that tampering can be detected. At least minimal precautions, perhaps to the level taught to computer science undergraduates, should be taken with the software.

This is not anywhere near as hard a problem as the vendors make it out to be. Many of the techniques needed to secure voting machinery are well known and well understood, at least outside of the vendors' labs. This is an area where open source methods could be and should be applied. Organizations like BlackBoxVoting.org and the NSF Accurate project should be working on solutions. Private companies have shown themselves to be completely incompetent at producing secure voting equipment, it is time for another solution to be tried.

Comments (37 posted)

New vulnerabilities

gd: multiple vulnerabilities

Package(s):gd CVE #(s):CVE-2007-3472 CVE-2007-3473 CVE-2007-3474 CVE-2007-3475 CVE-2007-3476 CVE-2007-3477 CVE-2007-3478
Created:August 6, 2007 Updated:November 6, 2009
Description: Integer overflow in gdImageCreateTrueColor function in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to have unspecified remote attack vectors and impact. (CVE-2007-3472)

The gdImageCreateXbm function in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via unspecified vectors involving a gdImageCreate failure. (CVE-2007-3473)

Multiple unspecified vulnerabilities in the GIF reader in the GD Graphics Library (libgd) before 2.0.35 allow user-assisted remote attackers to have unspecified attack vectors and impact. (CVE-2007-3474)

The GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via a GIF image that has no global color map. (CVE-2007-3475)

Array index error in gd_gif_in.c in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash and heap corruption) via large color index values in crafted image data, which results in a segmentation fault. (CVE-2007-3476)

The (a) imagearc and (b) imagefilledarc functions in GD Graphics Library (libgd) before 2.0.35 allows attackers to cause a denial of service (CPU consumption) via a large (1) start or (2) end angle degree value. (CVE-2007-3477)

Race condition in gdImageStringFTEx (gdft_draw_bitmap) in gdft.c in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via unspecified vectors, possibly involving truetype font (TTF) support. (CVE-2007-3478)

Alerts:
Ubuntu USN-854-1 libgd2 2009-11-05
Debian DSA-1613-1 libgd2 2008-07-22
Red Hat RHSA-2008:0146-01 gd 2008-02-28
SuSE SUSE-SR:2007:015 PHP, moodle, tomcat5, lighttpd, asterisk, libarchive, xpdf, evolution, kvirc, wireshark, gd, opera, clamav, gimp 2007-08-03
Fedora FEDORA-2007-692 gd 2007-09-18
Fedora FEDORA-2007-2055 gd 2007-09-07
Foresight FLEA-2007-0052-1 gd 2007-09-06
rPath rPSA-2007-0176-1 gd php php-mysql php-pgsql php5 php5-cgi php5-mysql php5-pear php5-pgsql php5-soap php5-xsl 2007-09-05
Trustix TSLSA-2007-0024 file, gd, mutt 2007-08-10
Gentoo 200708-05 gd 2007-08-09
Mandriva MDKSA-2007:153 gd 2007-08-03
Arch Linux ASA-201701-1 libwmf 2017-01-01

Comments (none posted)

gimp: integer overflows

Package(s):gimp CVE #(s):CVE-2006-4519
Created:August 2, 2007 Updated:August 8, 2007
Description: The Gimp has multiple integer overflow vulnerabilities. If a user can be tricked into opening specially crafted DICOM, PNM, PSD, PSP, RAS, XBM, or XWD images, integer overflows can occur and arbitrary code can be executed with the user's privileges.
Alerts:
Ubuntu USN-494-1 gimp 2007-08-02

Comments (1 posted)

java-1.5.0-sun: multiple vulnerabilities

Package(s):java-1.5.0-sun CVE #(s):CVE-2007-3503 CVE-2007-3655 CVE-2007-3698 CVE-2007-3922
Created:August 6, 2007 Updated:June 24, 2008
Description: The Javadoc tool was able to generate HTML documentation pages that contained cross-site scripting (XSS) vulnerabilities. A remote attacker could use this to inject arbitrary web script or HTML. (CVE-2007-3503)

The Java Web Start URL parsing component contained a buffer overflow vulnerability within the parsing code for JNLP files. A remote attacker could create a malicious JNLP file that could trigger this flaw and execute arbitrary code when opened. (CVE-2007-3655)

The JSSE component did not correctly process SSL/TLS handshake requests. A remote attacker who is able to connect to a JSSE-based service could trigger this flaw leading to a denial-of-service. (CVE-2007-3698)

A flaw was found in the applet class loader. An untrusted applet could use this flaw to circumvent network access restrictions, possibly connecting to services hosted on the machine that executed the applet. (CVE-2007-3922)

Alerts:
Red Hat RHSA-2008:0133-01 IBM Java 2008-06-24
SuSE SUSE-SA:2008:025 IBMJava2,IBMJava5,java-1_4_2-ibm,java-1_5_0-ibm 2008-04-25
Gentoo 200804-20 sun-jre, sun-jdk 2008-04-17
Red Hat RHSA-2008:0132-01 java-1.4.2-ibm 2008-02-14
Red Hat RHSA-2007:1086-01 java-1.4.2-bea 2007-12-12
SuSE SUSE-SA:2007:056 IBM 2007-10-18
Red Hat RHSA-2007:0956-01 java-1.5.0-bea 2007-10-16
Slackware SSA:2007-243-01 java 2007-08-31
Red Hat RHSA-2007:0829-01 java-1.5.0-ibm 2007-08-07
Red Hat RHSA-2007:0818-01 java-1.5.0-sun 2007-08-06

Comments (none posted)

mediawiki: cross-site scripting

Package(s):mediawiki CVE #(s):CVE-2007-1054
Created:August 7, 2007 Updated:August 8, 2007
Description: A cross-site scripting (XSS) vulnerability in the AJAX features in index.php in MediaWiki 1.6.x through 1.9.2, when $wgUseAjax is enabled, allows remote attackers to inject arbitrary web script or HTML via a UTF-7 encoded value of the rs parameter, which is processed by Internet Explorer.
Alerts:
Fedora FEDORA-2007-1442 mediawiki 2007-08-06

Comments (2 posted)

moodle: cross-site scripting

Package(s):moodle CVE #(s):CVE-2007-3555
Created:August 7, 2007 Updated:December 22, 2008
Description: A cross-site scripting (XSS) vulnerability in index.php in Moodle 1.7.1 allows remote attackers to inject arbitrary web script or HTML via a style expression in the search parameter.
Alerts:
Debian DSA-1691-1 moodle 2008-12-22
Fedora FEDORA-2008-0610 moodle 2008-01-15
Fedora FEDORA-2007-1445 moodle 2007-08-06

Comments (none posted)

openssl: private key attack

Package(s):openssl CVE #(s):CVE-2007-3108
Created:August 7, 2007 Updated:May 13, 2008
Description: OpenSSL could allow a local user in certain circumstances to divulge information about private keys being used.
Alerts:
Gentoo 201412-11 emul-linux-x86-baselibs 2014-12-11
Debian DSA-1571-1 openssl 2008-05-13
Red Hat RHSA-2007:1003-02 OpenSSL 2007-11-15
Ubuntu USN-522-1 openssl 2007-09-29
rPath rPSA-2007-0199-1 openssl 2007-09-25
Fedora FEDORA-2007-661 openssl 2007-08-13
Foresight FLEA-2007-0043-1 openssl 2007-08-13
rPath rPSA-2007-0155-1 openssl 2007-08-10
Fedora FEDORA-2007-1444 openssl 2007-08-06

Comments (none posted)

xpdf: bounds checking issues

Package(s):xpdf CVE #(s):
Created:August 3, 2007 Updated:August 8, 2007
Description: XPDF had several bounds checking issues that were fixed in version 3.02 according to this change log. A patch can be found here.
Alerts:
Fedora FEDORA-2007-1383 xpdf 2007-08-01

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds