Heartbleed’s Case for Test Driven Development
By Mark Bumiller– Heartbleed is quickly becoming a common word, not only in the IT community but also in the general population. This widespread internet security bug even has multiple obligatory XKCD comics.
There has been much talk about the technical details of the bug. The greatest conversation is centered on how this simple bug was overlooked by the many eyes of the open source community. It’s the Office Space equivalent of “a decimal point in the wrong place or something”. One of the more thorough analyses about the prevention of similar bugs going forward provides three suggestions:
- Pay money for security audits of critical security infrastructure like OpenSSL
- Write lots of unit and integration tests for these libraries
- Start writing alternatives in safer languages
As you probably assumed from my title, I am not going to talk about points one and three. I am going to focus on how to make sure little things—like a decimal point—are not overlooked…again. Enter Test Driven Development (TDD).
The heartbeat functionality can be found in Section 4 of RFC 6520. Quick inspection yields several requirements regarding the padding:
- The padding is random content that MUST be ignored by the receiver.
- The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. (explained in detail)
- The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes.
- The padding of a received HeartbeatMessage message MUST be ignored.
- If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.
Does one of these requirements stand out? It should.
When using TDD, the first step (after receiving requirements) is to develop tests. A sample test harness for the above requirements may have the following methods:
After filling in the guts of this test harness, the developer could then proceed to implementation. If at any point a test fails, the developer would know their code is incorrect. In our special case, the developer of OpenSSL (and the RFC proposal writer) would realize testLargePayloadLengthTooLargeIsDiscarded is failing and would fix it. Heartbleed would never be an issue.
At IDT, we take testing seriously. We believe in Test Driven development. ATRT: Test Manager can be used to conduct system level tests at every step, from initial development to installation and beyond. ATRT: Analysis Manager can analyze large amounts of data and make sure every message meets every requirement. If you don’t practice TDD, we can still help you verify that your software still works with each and every change and help direct you towards a TDD workflow.
If you use a server that was vulnerable to Heartbleed, change your password. If you’re a sys-admin, please check to see if your servers are secure by taking the SSL Labs Test. It even checks for the Heartbleed vulnerability. If you are vulnerable, replace OpenSSL with an unpatched version immediately. Afterward, don’t forget to revoke your certificate and replace it with a new one. Assume being vulnerable is the same as being compromised. Remember – what makes Heartbleed dangerous is that it leaves no trace.
Mark Bumiller is a software engineer at IDT. He is a contributing member of the ATRT: Test Manager and the ATRT: Analysis Manager development teams.