[Cryptography] Heartbleed and fundamental crypto programming practices

[Jan Pechanec]

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.

	see the fix for yourself:

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead;hp=4e6c12f3088d3ee5747ec9e16d03fc671b8f40be

	regards, J.

-- 
Jan Pechanec <jan.pechanec at oracle.com>