[cryptography] Just how bad is OpenSSL ?

Jeffrey Walton noloader at gmail.com
Mon Oct 29 16:06:58 EDT 2012

On Sun, Oct 28, 2012 at 3:01 PM, Solar Designer <solar at openwall.com> wrote:
> On Sat, Oct 27, 2012 at 06:47:05PM -0700, Patrick Pelletier wrote:
>> For the most part, I would say that OpenSSL is not badly written, just
>> badly documented.  I am not a cryptography expert (just a smart,
>> experienced programmer, trying to use TLS) so I'm not in a particularly
>> good position to judge the cryptographic merits of OpenSSL.  For the
>> most part, it seems sound, although a couple of things have given me
>> pause.  One is OPENSSL_cleanse, which overwrites memory with random
>> data.  Every other cryptography library I've seen seems to be happy with
>> just overwriting sensitive memory with zero.  I haven't seen any
>> explanation of why OpenSSL believes that overwriting with random data is
>> better than overwriting with zero.  In the absence of an explanation, it
>> feels a bit cargo-cultish.
> There is explanation.  CHANGES:
>   *) New function OPENSSL_cleanse(), which is used to cleanse a section of
>      memory from it's contents.  This is done with a counter that will
>      place alternating values in each byte.  This can be used to solve
>      two issues: 1) the removal of calls to memset() by highly optimizing
>      compilers, and 2) cleansing with other values than 0, since those can
>      be read through on certain media, for example a swap space on disk.
>      [Geoff Thorpe]
> crypto/mem.c (two places):
>         /* Create a dependency on the value of 'cleanse_ctr' so our memory
>          * sanitisation function can't be optimised out. NB: We only do
>          * this for >2Kb so the overhead doesn't bother us. */
>         if(ret && (num > 2048))
>         {       extern unsigned char cleanse_ctr;
>                 ((unsigned char *)ret)[0] = cleanse_ctr;
>         }
> The OPENSSL_cleanse() function is such that the memory is overwritten
> with the counter values, whereas the counter is incremented in ways
> dependent on the pointer to the memory region, and it is used to
> "pre-initialize" regions being allocated by OpenSSL's CRYPTO_malloc().
> This creates a non-trivial inter-dependency between the memory allocator
> and the memory sanitization functions, which presumably a compiler won't
> recognize as something that can be optimized out with no effect on
> operation of correctly written programs.
> Frankly, I do find this specific approach questionable, but the
> rationale is there, and the compiler optimization problem that this
> weird approach is trying to solve is real.
Out of curiosity, how would you do it? Perhaps cleanse() should go in
a separate source file compiled with no optimizations (-O0)?

Microsoft recognized the optimization problem some time ago, and
introduced SecureZeroMemory in Windows 2000. The C/C++ committee
recognizes optimizations (confer 'restrict' keyword), but doe not
offer a keyword to ensure program statements are not removed. Ditto
for Posix.

The vagueness in the definition of the 'volatile' qualifier has led to
different interpretations of its meaning (Microsoft, GCC, et al), so
assigning to a volatile global pointer will usually work, but its an
abuse of the keyword:

    static volatile void* g_zeroize = NULL;
    void wiper(void* buff, size_t len) {
        memset(buff, 0x00, len);
        g_zeroize = buff;

GCC uses volatile strictly for memory mapped hardware
(http://gcc.gnu.org/ml/gcc-help/2012-03/msg00251.html), so its an
abuse that the value is changed by software. Microsoft's
interpretation includes changes to memory by the hardware, OS, and
other threads (http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.90).aspx).

The OpenSSL cleanse() function will likely fail on BIOs created from
storage and memory mapped files when used on SSDs due to write
leveling and on-controller compression. If write leveling goes away,
it looks like cleanse() will still fail due to compression. Hence the
need for random, non-compressible data.


More information about the cryptography mailing list