Tagged heartbleed

Voting Heartburn over “Heartbleed”

Heartbleed is the latest high-profile consumer Internet security  issue, only a few weeks after the “Goto Fail” incident. Both are recently discovered weaknesses in the way that browsers and Web sites interact. In both cases and others, I’ve seen several comments that connect these security issues with Internet voting. But because Heartbleed is pretty darn wicked, I can’t not share my thoughts on how it connects to the work we do in the TrustTheVote project — despite the fact that i-voting is not part of it. (In fact, we have our hands full fixing the many technology gaps in the types of elections that we already have today and will continue to have for the foreseeable future.)

First off, my thanks to a security colleague Matt Bishop who offered an excellent rant (his term not mine!) on Heartbleed and what we can learn from it, and the connection to open source. The net-net is familiar: computers, software, and networks are fundamentally fallible, there will always be bugs and vulnerabilities, and that’s about as non-negotiable as the law of gravity.

Here is my take on how that observation effects elections, and specifically the choice that many many U.S. election officials have made (and which we support), that elections should be based on durable paper ballots that can be routinely audited as a cross check on potential errors in automated ballot counting. It goes like this:

  • Dang it, too many paper ballots with too many contests, to count manually.
  • We’ll have to use computers to count the paper ballots.
  • Dang it, computers and software are inherently untrustworthy.
  • Soooo ….  we’ll use sound statistical auditing methods to manually check the paper ballots, in order to check the work of the machines and detect their malfunctions.

This follows the lessons of the post-hanging-chads era:

  • Dang it, too many paper ballots with too many contests, to count manually.
  • We’ll have to use computers to directly record votes, and ditch the paper ballots.
  • Dang it, computers and software are inherently untrustworthy.
  • Oops, I guess we need the paper ballots after all.

I think that these sequences are very familiar to most readers here, but its worth a reminder now and then from experts on the 3rd point — particularly when the perennial topic of i-voting comes up– because there, the sequence is so similar yet so different:

  • Dang it, voters too far away for us to get their paper ballots in time to count them.
  • We’ll have to use computers and networks to receive digital ballots.
  • Dang it, computers and software and networks are inherently untrustworthy.
  • Soooo …. Oops.

— EJS

Bishop on Heartbleed

(My thanks to a security colleague Matt Bishop who offered this excellent rant (his term not mine!) on Heartbleed and what we can learn from it, and the connection to open source. You can read riff on it here.)

“First, the Heartbleed vulnerability isn’t a virus; you can’t be infected by it. It’s a programming error in one particular part of OpenSSL that was introduced when new functionality was added in late 2011. If the servers you connect to do not use OpenSSL, you’re safe from this. But many very widely used servers do use it, hence the concern.

The comment is that it’s a good example of the subtlety of problems that can be introduced through poor programming practices. The specific problem was an assumption that an incoming packet length as given in the packet is correct. The attack basically puts a bogus value in the length field, which enables the attacker to capture a chunk of memory that may contain sensitive data like user names and password — in the clear. The value in the length field is not something most programmers would question or try to validate.

We’ve seen similar vulnerabilities before in software designed to enhance or check security. The one that comes to mind immediately was in a widely used encryption library that had a buffer overflow, allowing anyone who used a server (or privileged program) that relied on the library to escalate privileges. The reference for the curious is:

http://www.cert.org/historical/advisories/CA-1999-15.cfm

This is why people like me are so concerned about complex code, *including* the underlying operating systems and drivers that support the election software. Note I didn’t say secret. Secret code to my mind is by definition suspect, especially in an environment in which transparency is a key requirement (for example, elections). But even open source code that is complex is suspect, because of the possibility of subtle errors. Or, as a friend of mine put it in a talk he gave in 1989, “[Company] claims it has developed a secure system. It’s 1.5 million lines of code. 1.5 million! Want to bet I can’t find a vulnerability in 1.5 million lines of code?” And systems were much smaller then . . . if I remember correctly, Microsoft Windows 2000 had roughly 33.5 million lines of code in its code base. No idea how much code the various versions of Windows have now.

 

And none of this covers the process (procedures) surrounding the use of these systems, which also need to be checked as a whole.

Rantings from a security person,

Matt”