[Cryptography] Heartbleed and fundamental crypto programming practices

[ianG]

On 11/04/2014 19:43 pm, Jan Pechanec wrote:
> On Thu, 10 Apr 2014, Jerry Leichter wrote:
> 
>> We've all by now heard of the Heartbleed security disaster.  I haven't 
>> seen the actual coding error, but the descriptions indicate that an 
>> attacker could cause the server to allocate and return a large buffer, 
>> almost all of which was left uninitialized - and often ended up 
>> containing various pieces of left-over sensitive information from 
>> previously-deleted and now-reused memory blocks.
>>
>> Years ago, when I developed some software in C++, I had a pair of 
>> classes called RedString and BlackString, imitating classic crypto 
>> usage of the colors.  A RedString contained "sensitive" data - data to 
>> be encrypted or that had been encrypted, keys in the clear, etc.  You 
>> could convert a RedString to a BlackString by encryption, or the other 
>> way around by decryption.  You could not misused a RedString in many 
>> obvious ways - e.g., the services that sent data over a link wouldn't 
>> access a RedString.
>>
>> More to the point, the destructor of a RedString cleared its memory 
>> before releasing it to the free pool.  A Heartbleed attack that 
>> revealed 64K of former RedString's would have revealed ... 64K blocks 
>> of zeros.
> 
> 	Jerry, what you described is not how the Heartbleed works.  The 
> problem is not with allocation of the buffer and that it was not 
> cleared, the problem is that memory past the input buffer is copied into 
> the buffer allocated for the reply.  And that source memory could be 
> still used and could contain what you call RedStrings, also in use.  
> The whole output buffer is overwritten here.  The problem is missing 
> bound checking, not the memory allocation.


What he's describing is a general defence against the presence of the
broad class of attack, not a specific blocker.  If we assume that the
attacker can at random times grab lumps of the memory, but isn't
otherwise in control, how do we make the app more robust?

The answer in general is crypto secret cleanliness.  In principle this
means minimising the number of copies and minimising the time spans
during which raw secrets are revealed.

Each piece of code that touches a crypto secret should keep the data for
the minimum amount of time, and scrub it on termination.

However this is fairly tough to do, you have to rewire a lot of thinking
in coding environments that copy stuff at random, and do lazy garbage
collection.

Hence, Jerry's solution posits objects that clearly identify their use,
and hold the actual secret tightly inside them, thus at least making it
easier to force the coder to respond when the objects come into play.

It's an interesting solution because if symbolises the problem and
forces the coder to respond to the symbols.

iang