Slashdot Mirror


How To Prevent the Next Heartbleed

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?"

2 of 231 comments (clear)

  1. Re:need to get over the "cult of macho programming by MoonlessNights · · Score: 5, Insightful

    The problem has more to do with the "hey, this is free so lets just take it" attitude of the downstream consumers not willing to pay for anyone to look at the code or pay anyone to write it.

    Why would you want the OpenSSL people to be held accountable for something they basically just wrote on their own time since nobody else bothered?

    Striking out to solve a problem should NOT be punished (that culture of legal punishment for being useful is part of why knowledge industries are leaving North America).

    This problem was caused by a simple missed parameter check, nothing more. Stop acting like the cultural problem is with the developers when it is with the leaches who consumer their work.

  2. Re:How about by Pricetx · · Score: 5, Interesting

    A quote from the "Insane Coding" blog, which in turn quotes from the book "cryptography engineering":

    The issues with higher level languages being used in cryptography are:
    - Ensuring data is wiped clean, without the compiler optimizations or virtual machine ignoring what they deem to be pointless operations.
    - The inability to use some high-level languages because they lack a way to tie in forceful cleanup of primitive data types, and their error handling mechanisms may end up leaving no way to wipe data, or data is duplicated without permission.
    - Almost every single thing which may be the right way of doing things elsewhere is completely wrong where cryptography is concerned.