HeartBleed and what C# Developers can learn from it

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Sylvio's Infobox

Aktuelle Themen rund um SQL Server, BI, Windows, ...

Meredith Lewis

Professional Digital Portfolio

Vittorio Bertocci

Just another WordPress.com weblog

ScottGu's Blog

Just another WordPress.com weblog

AJ's blog

Thoughts and informations I think worthwhile to share...

Outlawtrail - .NET Development

Architecture & Design

SDX eXperts Flurfunk

Just another WordPress.com weblog

%d bloggers like this: