Heartbleed Update • Hacker News Board

Re: Heartbleed Update

#11

Post by brians » Sat, Apr 12, 2014, 6:48 PM UTC

markbnj wrote: post #9

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.

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.

Re: Heartbleed Update

#12

Post by markbnj » Sat, Apr 12, 2014, 9:45 PM UTC

anaphor wrote: post #10

markbnj wrote: post #9

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.

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).

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.

Re: Heartbleed Update

#13

Post by markbnj » Sun, Apr 13, 2014, 2:07 AM UTC

brians wrote: post #11

markbnj wrote: post #9

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.

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 wi…

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

Re: Heartbleed Update

#14

Post by markbnj » Sun, Apr 13, 2014, 2:09 AM UTC

kevinchen wrote: post #5

athoik wrote: post #2

Maybe Akamai should create a challenge just like Cloudflare did...

What would that solve? We already know that it's possible to compromise the private key using this bug. The problem is that no one knows whether attackers have actually done so, since very few organizations will log all the data going in and out of their servers.

Does it matter? Once you know they might have, you have to assume they did. That's why the Cloudflare challenge was watched so closely.