Bug#368297: About the libgcrypt and OpenLDAP issue

[Carlos Alberto Lopez Perez]

On 19/04/13 20:56, Werner Koch wrote:
> Having said this, I don't see a reason why not to put the
> responsibilities in the hands of the suid program authors.  They anyway
> wake up every night due to a nightmare telling them to check this and
> that and - oh - I am using a library I didn't checked for 2 releases;
> lets set 2 years aside for another full audit of my entire program.
> Adding two lines of code right at startup shouldn't make their headaches
> worse.

Basically because the authors of this programs don't know they are using
libgcrypt under the hood. And they shouldn't know.

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.

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

The two patches proposed to fix this problem until now, what are doing
under the hood, is basically disable the secmem feature of libgcrypt to
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.

The whole initialization routine of GnuTLS (which is right now broken
for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the
libgcrypt commit d769529) disables secmem [1]. This is why reverting
that commit fixes this bug (fixes the GnuTLS init routine).

Why would anyone ever want to to disable the usage of secmem when
handling such critical data as a TLS library could handle? Just to avoid
the dropping privileges problem?? Is just insane!

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:
GCRYCTL_INIT_SECMEM_NODROP_PRIVS


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.

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.



[1]
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gcrypt/init.c;h=3d69f44

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20130419/69e4e911/attachment.pgp>