Slashdot Mirror

← Back to Stories (view on slashdot.org)

How To Prevent the Next Heartbleed

Posted by timothy on from the leave-your-comment-in-the-form-of-an-exploit dept.

dwheeler (321049) writes "Heartbleed was bad vulnerability in OpenSSL. My article How to Prevent the next Heartbleed explains why so many tools missed it... and what could be done to prevent the next one. Are there other ways to detect these vulnerabilities ahead-of-time? What did I miss?"

4 of 231 comments (clear)

  1. Re:How about by zr · · Score: 4, Informative

    about as effective as sunshine and puppies.

  2. Re:Static analysis by Krishnoid · · Score: 4, Informative

    Coverity has a blog post describing the problem and why their static analysis methods currently can't detect it.

  3. Re:How about by Dahamma · · Score: 4, Informative

    I have personally ported OpenSSL to at least 6 embedded systems, one of which was so proprietary they wrote their own C/C++ compiler. Good luck finding an Ada compiler for that.

    his makes it great for low-level, performance sensitive programs like OSes, compilers,

    Aaand... performance sensitive like, say... crypto? There isn't much code more performance sensitive than crypto libraries, which is one of OpenSSL's main uses. In fact, there are a whole bunch of native assembler implementations for x86, MIPS, ARM, PPC, etc to achieve that low level performance. Clearly you have never actually looked at the OpenSSL code base...

  4. Re:How about by kthreadd · · Score: 3, Informative

    If your web server is pushing out lots of https traffic then yes it is performance sensitive.