2014 - the infosec year in review - part 5

This is part 5 of an n-part blog series, discussing the things I found to be game changers in Infosec in 2014.

Item:  Heartbleed (yes, I know this has been overdone, but don't stop reading yet)

What is (or was) it?  A vulnerability in OpenSSL that left servers (and clients) open to data exposure.

Why it's significant? The Heartbleed bug was huge - I know because it passed the "Jake's mom test."  What's that you ask?  I can always tell when the media hype surrounding a security vulnerability is truly huge, because my mom calls.  She's a nurse and doesn't work in infosec, so the only reason she calls is that she's heard about it in the media and is alarmed enough to ask for more information.  This happened three times in 2014, more than any time previously.  This means that national coverage of infosec happenings is improving.

CloudFlare issued a challenge, under the notion that private keys could not be reliably recovered.  They were wrong.  Servers can and did lose private keys to theft.  At Rendition Infosec, we found hat most of our clients are not familiar with the purpose of key reissue.  Some issued new keys, but kept the original information in the key intact (so customers could not tell the keys had been replaced). Some patched the vulnerable libraries but did not restart the software using those libraries.  Most businesses have never reissued their keys en-masse before.  Additionally, CRL's were never really designed to handle revoking everyone's keys.

Could it have been prevented? Yes, Ray Charles could have seen this coming.  Maybe not the specific vulnerability, but the OpenSSL code was a train wreck.  Here we were all using the code (myself included) and assuming it must be relatively secure because someone else must be looking at it.

Two specific preventive measures come to mind.  The first is the use of the custom memory allocator. Developers - stop doing this unless you really need it.  OpenSSL did not need a custom memory allocator.  One comment in the code suggests that malloc is slow on some platforms and this is the reason OpenSSL manages its own free lists.  OpenSSL even acknowledges the criticism on its own wiki.  If malloc and free had been used, my mom would never have heard about heartbleed.  The headline would have been "almost certain DoS with extremely unlikely data disclosure found in OpensSSL."  In the SANS Advanced Exploit Development course (where I'm a contributing author), we cover mitigations for heap overflows.  There are many and they make exploitation much harder.  But by using a custom allocator, OpenSSL removed the possibility of using any of these mitigations.

The second preventive measure is code review of critical open source software.  Again, this code was a train wreck.  @ErrataRob did a great job already reviewing some critical errors in the code.  One of the most glaring of these is actually an old programming joke.

   { s2n(strlen(s->ctx->psk_identity_hint), p); strncpy((char *)p, s->ctx->psk_identity_hint, strlen(s->ctx->psk_identity_hint));
p+=strlen(s->ctx->psk_identity_hint);
}

The joke is:

    strncpy(dst,src,strlen(src));

This just gets rid of the compiler warning without actually providing any additional security.  The length field should never be blindly set to the size of the source string.  Anyone with a college background in programming knows this is insecure, yet it was in the OpenSSL code (and interestingly did not cause Heartbleed).  We need better security audits around out open source software, just trusting that someone else is doing it won't work.

Stay tuned for more installments in the Infosec year in review.