Bug#368297: About the libgcrypt and OpenLDAP issue

[Werner Koch]

On Fri, 19 Apr 2013 22:37, clopez at igalia.com said:

> They just call a standard function (ex: getpwent). This function may or
> may not chain with libgcrypt depending on how the system libraries are
> compiled and how the system is configured.

Okay, then it is the fault of the libnss code to allow the use of
complex code not suited for suid processes.  After all it boils down to
a design problem of libpam.

> On the case of a Debian system configured to use PAM/LDAP this will
> chain to libldap->libgrypt.

I still can't believe it.

> prevent the dropping privileges problem. This is a suboptimal solution.
> I think that anybody would agree that the usage of "mlocked" memory
> regions for this kind of data like passwords is encouraged.

Not necessary if you the swap space is encrypted.  This provides an even
better port-mortem protection than mlock.

> The whole initialization routine of GnuTLS (which is right now broken
> for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the

Surely it is broken.  Only the application itself can guarantee that the
threading system has been properly initialized.  A library can only try
its best to avoid future damage.

> handling such critical data as a TLS library could handle? Just to avoid
> the dropping privileges problem?? Is just insane!

Running code conveying data over the network in a suid process is evil!

> At least, I think that you should consider adding a new flag to
> libgcrypt that allows the application/library developer to complete
> disable the dropping privileges feature. Perhaps something like:

That was my suggesttion.  Shall we go for that?

> IMHO is not the business of libgcrypt to care about the security of the
> application that uses it. And dropping privileges for the caller
> application when not directly asked is, at least, rude.

IMNSHO Libgcrypt needs to do it because its post-initialization layers
have not been designed for a suid process.

> The programmer of the suid application should care himself about
> dropping privileges when he feels like that. If you force him to drop
> privileges he will just skip your secmem routine. This is bad for everyone.

Nope: SUID processes are bad and should only be used if really really
necessary.  In contrast mlocked memory is a nice to have feature but the
attack scenarios are pretty limited compared to networking suid code.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.