(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”