Bug#566351: libgcrypt problem

[Simon Josefsson]

Howard Chu <hyc at highlandsun.com> writes:

>> See comment #72 of this launchpad bug report for a detailed description
>> of why libgcrypts behavior causes the problem in libldap.
>>
>> https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/
>> https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72
>
> Note that the root cause here is that gnutls depends on libgcrypt but
> doesn't fully encapsulate it.

I don't see that, I believe the root cause is that applications are not
initializing libgcrypting properly.  Read the libgcrypt manual, it is
explained there.

We can discuss changing the design of libgcrypt works, but unless that
has happened, the problem remains with the applications, and,
fortunately, the problem can easily be fixed by the applications
initializing Libgcrypt as documented.

We could also discuss changing GnuTLS' use of Libgcrypt, but that also
does not change the fundamental problem.

> None of the gnutls docs mention that any special initialization
> function needs to be called when using it in a threaded application.

You must have missed this section:

http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html

> App writers using gnutls should not need to know that libgcrypt is
> under the covers and needs special handling.

The Libgcrypt designers appears to have believed otherwise, and given
how broken the applications appear to be in this area decision (setuid
programs doing LDAP+TLS?  Sigh) it seems that was useful because we are
now aware of these sub-optimal security practices.  Working on fixing
this to use a better mechanism (userv was mentioned) would be useful
regardless of what is done (or not) in GnuTLS/Libgcrypt.

The crypto parts of OpenSSL have a similar issue: they need mutexes
provided by the application.  Many libraries using OpenSSL doesn't
provide an interface to provide these mutexes, but depend on the
application initializing OpenSSL themselves.

> (Indeed, as illustrated in this bug report, apps generally won't and
> can't know anything about the underlying libraries.)

That is a problem indeed.

> So aside from deciding what fix if any is appropriate for libgcrypt's
> secmem implementation, the larger issue remains of how to make
> libgcrypt safe for use when it's nested under other libraries like
> gnutls. Saying "applications are responsible for correctly
> initializing libgcrypt" is a non-starter. libgcrypt needs to have that
> requirement removed, and gnutls needs to be more comprehensive and
> explicit in the steps it takes to initialize libgcrypt, so that gnutls
> callers are completely shielded from the lower API layers.

Right, I think things can be improved here.  However sometimes it is not
possible to shield applications from lower API layers: compare threads.
You can't have a multi-threaded application access the entropy functions
in any reliable manner with Libgcrypt or OpenSSL.  The application needs
to provide the libraries with mutexes for the thread library it is
using, so the libraries can protect these accesses properly.

/Simon