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?"
It could have been discovered with static analysis if anyone had the foresight to implement a specific check ahead of time (although it's unknown whether anyone could have thought of checking this specific case before Heartbleed was discovered):
http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/
about as effective as sunshine and puppies.
Every industry goes through this. At one point it was aviation, and the "hot shot pilot" was the Real Deal. But then they figured out that even the Hottest Shot pilots are human and sometimes forget something critical and people die, so now, pilots use checklists all the time for safety. No matter how awesome they might be, they can have a bad day, etc. And this is also why we have two pilots in commercial aviation, to cross check each other.
In programming something as critical as SSL it's long past time for "macho programming culture" to die. First off, it needs many eyes checking. Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more. No matter how macho the programmer thinks s/he is, s/he is only human and WILL make mistakes like this. We need better tools and technologies to move the industry forward.
Last, in other engineering professions there is licensing and engineers are held accountable for mistakes they make. Maybe we don't need that for some $2 phone app, but for critical infrastructure it is also past time, and programmers need to start being held accountable for the quality of their work.
It's things the "brogrammer" culture will complain BITTERLY about, their precious playground being held to professional standards. But it's the only way forward. It isn't the wild west any more. The world depends on technology and we need to improve the quality and the processes behind it.
Yes, I'm prepared to be modded down by those cowboy programmers who don't want to be accountable for the results of their poor techniques... But that is exactly the way of thinking that our industry needs to shed.
Let's remember the good old bug that plagued (and probably still does) many libraries that read graphic files such as TIFF. The classic scenario was that the programmer was reading the expected image size from the TIFF file header, allocated memory for this size, then read the reminder of the file into said buffer, until end of file. Instead of reading as many bytes as he has allocated. Now for a correct file this would work, however if the file is maliciously crafted to indicate one size in the header while having a much larger real size, you would do a classic buffer overrun. This is pretty much similar to what the SSL programmer did. And no tools were ever able to predict this type of errors, whether TIFF or SSL.
BTW the last famous one with TIFF files was pretty recent:
http://threatpost.com/microsoft-to-patch-tiff-zero-day-wait-til-next-year-for-xp-zero-day-fix/103117
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.
Yes, I think it's clear the next gen of CPUs really needs to have the machine language removed entirely. What a security hole!
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...
The US Army will swear that I was once, many moons ago, officially certified in Ada, whether that means anything or not. I never liked it much, even though I did turn in successful code a few times, and I really have a problem with Ada for open source applications - Yes, in theory, Ada has some very strong security functions by design, but it's definitely not going to result in the 'many eyes make all bugs shallow' effect. I actually read your post as deliberately tongue in cheek at first, what with phrases such as 'extremely unsafe'.
But as I think more about it, one of the problems revealed by Heartbleed is open sourcing the target code didn't result in a lot of properly trained eyes passing over that code. I never thought I'd encourage anyone to learn Ada after I got out of the service (just as I never thought I'd encourage anyone to start a cult worshipping many-tentacled, eldritch, blasphemous horrors from beyond space-time as we delusionally try to limit our conceptions of it to preserve our fundamental human sanity, and for much the same reasons), but I have to admit, you may have a damned good argument for Ada there.I don't know if the extensive compile time checking of Ada 2012 could have automatically caught the bug that made Heartbleed possible - the last version of Ada I've really used is 95, but I'd be really interested to hear from someone who's current if they think Ada is just about totally bulletproof against this sort of bug, because even the older versions I recall had some features that would have made it hard to make this sort of mistake.
Who is John Cabal?
If your web server is pushing out lots of https traffic then yes it is performance sensitive.
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.
Rigorous testing is helpful, but I think it's the wrong approach. The problem here was lack of requirements and/or rigorous design. In the physical engineering disciplines, much effort is done to think about failure modes of designs before they are implemented. In software, for some reason, the lack of pre-implementation design and analysis is endemic. This leads to things like Heartbleed - not language choice, not tools, not lack of static testing.
I would also go as far as saying if you're relying on testing to see if your code is correct (rather than verify your expectations), you're already SOL because testing itself is meaningless if you don't know the things you have to test - which means up-front design and analysis.
That said, tools and such can help mitigate issues associated with lack of design, but the problem is more fundamental than a "coding error."
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)