Use of custom memory allocators

Werner Koch wk at
Thu Dec 4 13:17:00 CET 2008


I looked at the gnutls code and found a problem.  In gnutls_global_init
you do this:

  if (gcry_control (GCRYCTL_ANY_INITIALIZATION_P) == 0)
      const char *p = gcry_check_version (GCRYPT_VERSION);


    #ifdef DEBUG
      /* applications may want to override that, so we only use
       * it in debugging mode.
      gcry_set_log_handler (_gnutls_gcry_log_handler, NULL);

  /* for gcrypt in order to be able to allocate memory */
  gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc,
			       _gnutls_is_secure_memory, gnutls_realloc,

A minor glitch is that you should call gcry_set_log_handler even before

     This function registers FUNC_LOG as `logging handler', which means
     that it will be called in case Libgcrypt wants to log a message.
     This function may and should be used prior to calling

This is so that problems during initializaion can be logged.

The real problem however is the use of gcry_set_allocation_handler.
This installs a new memory allocator defaulting to to standard
malloc/free.  Well, for an application using just gnutls this might not
be a problem (unless in FIPS mode).  However if an application is using
gnutls directly or indirectly (e.g. through openldap) and also making
direct use of libgcrypt this will change the standard Libgcrypt memory
allocators or those set by the actual application.  This is a security
problem because by using a plain malloc and free it is not anymore
guaranteed that all sensitive data is zeroes out as soon as needed.

If you really, really want to set other Libgcrypt allocation handlers,
you need to do it in the above initalization block and before setting
the finished flag.  (I'll add an extra sentence to the manual.)



Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

More information about the Gcrypt-devel mailing list