[markbnj]

It seems interesting that Akamai protected itself from heartbleed by implementing a custom allocator, which was in some respects at least part of what caused heartbleed.

[brians]

In some sense, yes, the special free list caused it. In another sense, the missed bounds check caused it. In a third sense, the lack of proofs of safety, or informal code review process, "caused" it---that one's harder for me to argue.

My own preferred sense is that mixing network code with soft real time performance requirements with crypto in a single library, single process, all in C---maybe that caused it, and will cause problems for any channel-oriented crypto network system. Imagine trying to mix GnuPG with high performance networking! Boom.

My preferred tools for thinking about what causes accidents like this are Leveson's systems-oriented frameworks, explained in Engineering a Safer World. The text is available free from MIT Press, I believe. If you're responsible for the safety of a planetary computer system, you should read it and it's principal competitors.

And if you do, Akamai Infosec is hiring.

[markbnj]

I'll keep that in mind, Brian, although my reading list is long, and not getting any shorter.

[anaphor]

Well OpenSSL didn't implement their own malloc exactly, they used some weird indirection to try and speed it up on some platforms, which may have bypassed protections that some versions of malloc have enabled (guard pages).

[markbnj]

Agreed, it's a loose analogy at best. The juxtaposition just struck me, mainly because it could be viewed as singling out the real difference, which is how the code was handled.