HeartBleed did hit the internet community on 201-04-07. Many bloggers already did explain the bug and some of the consequences (most of that information can be read on a web site exclusively created for this bug – how many bugs have an own homepage?). Some also discussed why such a bug can happen (missing check of input parameters, internal implementation of memory management, …). But what most of them do not describe is what we can learn from that.
It’s easy to point at the line of code that has caused this issue and say “that’s clearly wrong – you should have checked the data”, but that’s not the point. C++ does not check your memory management as well as C# does, so you always will do mistakes and it’s pointless to complain about a specific single error (that has been undetected for years). But what we should do is try to find ways to prevent such problems in our code. So have a look at the bug fix and think about what was helping the bug to become true.
You can look up the commit for the fix in GitHub – it’s a fairly easy fix, but it reveals a really ubiquitous issue: trust in caller provided information (I don’t blame C++ for such a lousy support of secure memory management – it’s an old language without a focus on preventing the developer to make mistakes … it simply assumes that you as a human never do a mistake). In this case the length of the block the caller wants to get back has been provided by the caller. In my opinion this is a major design flaw. The caller should not be allowed to determine the length of a response – it can provide some data about the maximum size of content you “should” return, but you NEVER should simply use that number.
So is the bug relevant to C#-Developers? Yes definitely: it shows that trust in external data is a really bad idea – and that does have nothing to do with C++, SSL or OpenSource … it’s a really basic security concern: do not trust the data in your methods parameters. The fix in OpenSSL is now comparing the desired length with the length of the buffer and using the minimum of both. I would recommend to not even do that: simply return the same data you got – that way there would be no need for a user specified length that might be wrong.