Debian Bug report logs - #566351
libgcrypt11: should not change user id as a side effect

Package: libgcrypt11; Maintainer for libgcrypt11 is Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>; Source for libgcrypt11 is src:libgcrypt11.

Reported by: ansgar@debian.org

Date: Sat, 23 Jan 2010 04:57:02 UTC

Severity: serious

Tags: help, patch, squeeze-ignore, wheezy-ignore

Merged with 368297, 545414, 579647, 601667, 628671, 658739, 658896

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Sat, 23 Jan 2010 04:57:05 GMT) Full text and rfc822 format available.

Message #3 received at submit@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@2008.43-1.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libgcrypt11: should not change user id as a side effect
Date: Sat, 23 Jan 2010 13:55:23 +0900
Package: libgcrypt11
Version: 1.4.4-6
Severity: normal

Hi,

the function lock_pool from src/secmem.c has the side effect of changing
user ids if real uid != effective uid.  This causes strange behaviour in
other programs:

A program using libnss-ldap for querying group membership with SSL
enabled, but without nscd might suddenly change the user id when calling
getgroups (or initgroups).  An example for this is the atd daemon[1].

Regards,
Ansgar

[1] https://bugs.launchpad.net/bugs/509734

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgcrypt11 depends on:
ii  libc6                         2.10.2-2   GNU C Library: Shared libraries
ii  libgpg-error0                 1.6-1      library for common error values an

libgcrypt11 recommends no packages.

Versions of packages libgcrypt11 suggests:
pn  rng-tools                     <none>     (no description available)

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Sat, 23 Jan 2010 13:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 23 Jan 2010 13:51:03 GMT) Full text and rfc822 format available.

Message #8 received at 566351@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Ansgar Burchardt <ansgar@2008.43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Sat, 23 Jan 2010 14:47:25 +0100
On 2010-01-23 Ansgar Burchardt <ansgar@2008.43-1.org> wrote:
> the function lock_pool from src/secmem.c has the side effect of changing
> user ids if real uid != effective uid.  This causes strange behaviour in
> other programs:

> A program using libnss-ldap for querying group membership with SSL
> enabled, but without nscd might suddenly change the user id when calling
> getgroups (or initgroups).  An example for this is the atd daemon[1].

> Regards,
> Ansgar

> [1] https://bugs.launchpad.net/bugs/509734

Hello,
afaiui this is documented behavior:
| GCRYCTL_INIT_SECMEM; Arguments: int nbytes
| This command is used to allocate a pool of secure memory and thus
| enabling the use of secure memory. It also drops all extra privileges
| the process has (i.e. if it is run as setuid (root)). If the argument
| nbytes is 0, secure memory will be disabled. The minimum amount of
| secure memory allocated is currently 16384 bytes; you may thus use a
| value of 1 to request that default size. 

cu andreas




Set Bug forwarded-to-address to 'mid.gmane.org/20100123134725.GA3309@downhill.g.la'. Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Sat, 23 Jan 2010 13:57:07 GMT) Full text and rfc822 format available.

Changed Bug forwarded-to-address to 'http://mid.gmane.org/20100123134725.GA3309@downhill.g.la' from 'mid.gmane.org/20100123134725.GA3309@downhill.g.la' Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Sat, 23 Jan 2010 14:03:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 25 Jan 2010 10:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 25 Jan 2010 10:45:02 GMT) Full text and rfc822 format available.

Message #17 received at 566351@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Ansgar Burchardt <ansgar@2008.43-1.org>
Cc: Andreas Metzler <ametzler@downhill.at.eu.org>
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Mon, 25 Jan 2010 10:56:17 +0100
Hi!

I understand that there is sometimes the need for lifetime long suid
programs.  Although, I don't think that it is a sensible approach to
write software this way (instead of using helpers like userv), I can add
a hack to disable dropping of permissions.

Ansgar, is it that what you want?


Salam-Shalom,

   Werner


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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 25 Jan 2010 13:27:03 GMT) Full text and rfc822 format available.

Message #20 received at 566351@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@2008.43-1.org>
To: gcrypt-devel@gnupg.org, 566351@bugs.debian.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Mon, 25 Jan 2010 22:24:24 +0900
Hi,

Werner Koch <wk@gnupg.org> writes:

> I understand that there is sometimes the need for lifetime long suid
> programs.  Although, I don't think that it is a sensible approach to
> write software this way (instead of using helpers like userv), I can add
> a hack to disable dropping of permissions.
>
> Ansgar, is it that what you want?

Yes, that is fine with me.  Changing the default may break assumptions
made by existing applications after all.

It would be nice if the documentation could mention that libraries that
initialize gcrypt themselves should use this hack.  Otherwise the
side effect of changing user ids is "inherited" by the library (which is
what was the problem here: the changing of user ids was inherited by
libnss-ldap via openldap and gnutls).

Regards,
Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 25 Jan 2010 14:51:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 25 Jan 2010 14:51:15 GMT) Full text and rfc822 format available.

Message #25 received at 566351@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Ansgar Burchardt <ansgar@2008.43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Mon, 25 Jan 2010 15:47:57 +0100
On Mon, 25 Jan 2010 14:24, ansgar@2008.43-1.org said:

> Yes, that is fine with me.  Changing the default may break assumptions
> made by existing applications after all.

Of course we will not change the default.

> It would be nice if the documentation could mention that libraries that
> initialize gcrypt themselves should use this hack.  Otherwise the

That will never happen.  This is totally bogus. 

If an application does not properly initialize libgcrypt it is in any
case a severe error.  However, Libgcrypt tries to minimize the bad
effects of this and thus in general it works just fine.  Dropping
extended privileges is a part of this.

> side effect of changing user ids is "inherited" by the library (which is
> what was the problem here: the changing of user ids was inherited by
> libnss-ldap via openldap and gnutls).

Are you trying to tell us that there is an application with dependencies
to libnss, openldap and gnutls and that one is intended to be run suid?
Did you audit all that code and the way the code is used to be written
properly in a way that the suid-ness is not exploitable? 

Given how hard it is to even write a small suid application I have
severe doubts about the application and whether my proposed hack makes
sense at all.


Salam-Shalom,

   Werner

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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 25 Jan 2010 15:15:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ansgar Burchardt <ansgar@43-1.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 25 Jan 2010 15:15:14 GMT) Full text and rfc822 format available.

Message #30 received at 566351@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@43-1.org>
To: 566351@bugs.debian.org
Cc: gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Tue, 26 Jan 2010 00:13:48 +0900
Werner Koch <wk@gnupg.org> writes:

> Are you trying to tell us that there is an application with dependencies
> to libnss, openldap and gnutls and that one is intended to be run suid?
> Did you audit all that code and the way the code is used to be written
> properly in a way that the suid-ness is not exploitable?

Yes, it is even quite simple to write such an application: Just call
getgroups(), getpwent(), ... on a system that uses LDAP.  If there is no
caching daemon like nscd running, the application will use libnss-ldap
(via glibc's Name Service Switch) which can in turn use gnutls.

As the application itself does not use openldap, gnutls, or gcrypt there
is no way it could initialize gcrypt.

Using PAM can probably result in similar problems.

Regards,
Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 25 Jan 2010 15:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 25 Jan 2010 15:48:06 GMT) Full text and rfc822 format available.

Message #35 received at 566351@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Ansgar Burchardt <ansgar@43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Mon, 25 Jan 2010 16:43:11 +0100
On Mon, 25 Jan 2010 16:13, ansgar@43-1.org said:

> Yes, it is even quite simple to write such an application: Just call
> getgroups(), getpwent(), ... on a system that uses LDAP.  If there is no
> caching daemon like nscd running, the application will use libnss-ldap
> (via glibc's Name Service Switch) which can in turn use gnutls.

That is a broken design.  glibc should never ever allow suid processes
to run code from external services it is not 100% sure they are clean.
I guess libnss_files and the other standard ones might be fine, but LDAP
or even LDAPS are very problematic.  Such code belongs into a separate
process and not into the one of an arbitrary - possible suid -
application.

> As the application itself does not use openldap, gnutls, or gcrypt there
> is no way it could initialize gcrypt.

You may consider this a featue - it indicates that there is something
severly wrong with the application running on a particular system
configuration.


Shalom-Salam,

   Werner


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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Tue, 26 Jan 2010 08:03:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fweimer@bfk.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 26 Jan 2010 08:03:21 GMT) Full text and rfc822 format available.

Message #40 received at 566351@bugs.debian.org (full text, mbox):

From: Florian Weimer <fweimer@bfk.de>
To: Ansgar Burchardt <ansgar@43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Tue, 26 Jan 2010 07:52:21 +0000
* Werner Koch:

> That is a broken design.  glibc should never ever allow suid processes
> to run code from external services it is not 100% sure they are clean.
> I guess libnss_files and the other standard ones might be fine, but LDAP
> or even LDAPS are very problematic.  Such code belongs into a separate
> process and not into the one of an arbitrary - possible suid -
> application.

The libc jas no business policing user code in this way.  NSS and PAM
modules already need to be SUID-safe, and there's really no way around
that.  A process-based solution for PAM and NSS might have been
preferable, but it's rather late for that now.

One side effect of dropping privileges is that some code no longer
treats the process environment as tainted, leading to security issues
if the process has opened descriptors while it had increased
privilege.  Beyond getuid() != geteuid(), there is really no good way
to check for a tainted environment, alas.

But the whole discussion is rather odd.  I thought that access to
locked memory no longer requires root privileges, no?

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 27 Jan 2010 00:18:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ansgar Burchardt <ansgar@43-1.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 27 Jan 2010 00:18:15 GMT) Full text and rfc822 format available.

Message #45 received at 566351@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@43-1.org>
To: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 27 Jan 2010 09:17:34 +0900
Werner Koch <wk@gnupg.org> writes:

> On Mon, 25 Jan 2010 16:13, ansgar@43-1.org said:
>
>> Yes, it is even quite simple to write such an application: Just call
>> getgroups(), getpwent(), ... on a system that uses LDAP.  If there is no
>> caching daemon like nscd running, the application will use libnss-ldap
>> (via glibc's Name Service Switch) which can in turn use gnutls.
>
> That is a broken design.  glibc should never ever allow suid processes
> to run code from external services it is not 100% sure they are clean.
> I guess libnss_files and the other standard ones might be fine, but LDAP
> or even LDAPS are very problematic.  Such code belongs into a separate
> process and not into the one of an arbitrary - possible suid -
> application.

It can run in a separate process if nscd (glibc's name service caching
daemon) is running.  But if nscd is not installed or not running for
some reason, there is not much to do except doing the query in the same
process.

gcrypt's behavior also does not only affect suid processes, but also
processes started by root that change their real user id to something
else, but still need to change to a different user id later.

>> As the application itself does not use openldap, gnutls, or gcrypt there
>> is no way it could initialize gcrypt.
>
> You may consider this a featue - it indicates that there is something
> severly wrong with the application running on a particular system
> configuration.

There are enough sensible reasons for an application using gcrypt only
indirectly (eg. applications using gnutls should not need to care which
cryptographic library is used by it, more so for applications that only
use a library like libcurl that uses gnutls, but can also use OpenSSL).

Regards,
Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 27 Jan 2010 08:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 27 Jan 2010 08:48:06 GMT) Full text and rfc822 format available.

Message #50 received at 566351@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Ansgar Burchardt <ansgar@43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 27 Jan 2010 09:44:39 +0100
Ansgar Burchardt <ansgar@43-1.org> writes:

> Werner Koch <wk@gnupg.org> writes:
>
>> On Mon, 25 Jan 2010 16:13, ansgar@43-1.org said:
>>
>>> Yes, it is even quite simple to write such an application: Just call
>>> getgroups(), getpwent(), ... on a system that uses LDAP.  If there is no
>>> caching daemon like nscd running, the application will use libnss-ldap
>>> (via glibc's Name Service Switch) which can in turn use gnutls.
>>
>> That is a broken design.  glibc should never ever allow suid processes
>> to run code from external services it is not 100% sure they are clean.
>> I guess libnss_files and the other standard ones might be fine, but LDAP
>> or even LDAPS are very problematic.  Such code belongs into a separate
>> process and not into the one of an arbitrary - possible suid -
>> application.
>
> It can run in a separate process if nscd (glibc's name service caching
> daemon) is running.  But if nscd is not installed or not running for
> some reason, there is not much to do except doing the query in the same
> process.

Why can't the system call fail in that situation?

> There are enough sensible reasons for an application using gcrypt only
> indirectly (eg. applications using gnutls should not need to care which
> cryptographic library is used by it, more so for applications that only
> use a library like libcurl that uses gnutls, but can also use OpenSSL).

I agree here though.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 27 Jan 2010 10:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 27 Jan 2010 10:33:04 GMT) Full text and rfc822 format available.

Message #55 received at 566351@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Ansgar Burchardt <ansgar@43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 27 Jan 2010 11:28:27 +0100
On Wed, 27 Jan 2010 01:17, ansgar@43-1.org said:

> There are enough sensible reasons for an application using gcrypt only
> indirectly (eg. applications using gnutls should not need to care which
> cryptographic library is used by it, more so for applications that only
> use a library like libcurl that uses gnutls, but can also use OpenSSL).

There is an easy solution to this:  Use your own memory handler.

Anyway, they need to care about this; read the gcrypt manual to see why
this is important.

In general all these inter-library dependencies are a mess.  They
subvert the assumptions of carefully written software.  We have seen
large trees of dependencies whre severeal vesion of the same library are
in use - that works only by coincidence and yields bugs which are very
hard to track down.  There is also a licences compliance problem with
this approach: I noticed in several cases OpenSSL used along with GPL
software due to dependencies the developer was not aware of (e.g.
OpenLDAP).



Salam-Shalom,

   Werner

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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 27 Jan 2010 11:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ansgar Burchardt <ansgar@43-1.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 27 Jan 2010 11:48:03 GMT) Full text and rfc822 format available.

Message #60 received at 566351@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@43-1.org>
To: Simon Josefsson <simon@josefsson.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 27 Jan 2010 20:44:28 +0900
Hi,

Simon Josefsson <simon@josefsson.org> writes:

>> It can run in a separate process if nscd (glibc's name service caching
>> daemon) is running.  But if nscd is not installed or not running for
>> some reason, there is not much to do except doing the query in the same
>> process.
>
> Why can't the system call fail in that situation?

nscd is optional and one probably does not want to make the system
unusable if it crashes (no possibility to log in when you cannot
access the user database).  It would likely also require special
handling of the entire boot process when nscd is not yet available.

Regards,
Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 27 Jan 2010 13:21:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 27 Jan 2010 13:21:12 GMT) Full text and rfc822 format available.

Message #65 received at 566351@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Ansgar Burchardt <ansgar@43-1.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 27 Jan 2010 14:18:29 +0100
Ansgar Burchardt <ansgar@43-1.org> writes:

> Hi,
>
> Simon Josefsson <simon@josefsson.org> writes:
>
>>> It can run in a separate process if nscd (glibc's name service caching
>>> daemon) is running.  But if nscd is not installed or not running for
>>> some reason, there is not much to do except doing the query in the same
>>> process.
>>
>> Why can't the system call fail in that situation?
>
> nscd is optional and one probably does not want to make the system
> unusable if it crashes (no possibility to log in when you cannot
> access the user database).  It would likely also require special
> handling of the entire boot process when nscd is not yet available.

It would be nice if it was possible to configure it to fall back on
something saner than invoking a setuid-binary when nscd is not
available/working.  That should work during boot too.  Just an idea.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Thu, 29 Apr 2010 13:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rune Schjellerup Philosof <rune@philosof.dk>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 29 Apr 2010 13:39:07 GMT) Full text and rfc822 format available.

Message #70 received at 566351@bugs.debian.org (full text, mbox):

From: Rune Schjellerup Philosof <rune@philosof.dk>
To: 566351@bugs.debian.org
Subject: Another launchpad bug report
Date: Thu, 29 Apr 2010 15:27:48 +0200
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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Thu, 29 Apr 2010 15:45:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Howard Chu <hyc@highlandsun.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 29 Apr 2010 15:45:12 GMT) Full text and rfc822 format available.

Message #75 received at 566351@bugs.debian.org (full text, mbox):

From: Howard Chu <hyc@highlandsun.com>
To: 566351@bugs.debian.org
Subject: libgcrypt problem
Date: Thu, 29 Apr 2010 08:36:57 -0700
> 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. None of the gnutls docs mention that any special 
initialization function needs to be called when using it in a threaded 
application. App writers using gnutls should not need to know that libgcrypt 
is under the covers and needs special handling. (Indeed, as illustrated in 
this bug report, apps generally won't and can't know anything about the 
underlying libraries.) 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.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Fri, 30 Apr 2010 08:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 30 Apr 2010 08:15:05 GMT) Full text and rfc822 format available.

Message #80 received at 566351@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Howard Chu <hyc@highlandsun.com>
Cc: 566351@bugs.debian.org
Subject: Re: Bug#566351: libgcrypt problem
Date: Fri, 30 Apr 2010 10:05:09 +0200
Howard Chu <hyc@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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Fri, 30 Apr 2010 08:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Howard Chu <hyc@highlandsun.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 30 Apr 2010 08:39:08 GMT) Full text and rfc822 format available.

Message #85 received at 566351@bugs.debian.org (full text, mbox):

From: Howard Chu <hyc@highlandsun.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 566351@bugs.debian.org
Subject: Re: Bug#566351: libgcrypt problem
Date: Fri, 30 Apr 2010 01:38:53 -0700
Simon Josefsson wrote:
> Howard Chu<hyc@highlandsun.com>  writes:
>> 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

Not at all. OpenLDAP libldap_r does precisely these two steps, as documented 
in your link:
           gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
           gnutls_global_init();

But that is completely useless, due to the behavior inside libgcrypt and 
gnutls which I already explained in here

https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72

>> (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.

Yes, it's a thorny issue. There are only two good solutions I'm aware of:
 - compile in a default set of thread callbacks, whose actual implementations 
point to the "native" thread library using weak external references. If the 
thread library is present, all the API references will resolve, otherwise they 
remain as NULL pointers and can be ignored.
 - ask for help from glibc. libc could provide a vector of function pointers 
for pthread support; this would be init'd as no-ops by default, and 
transparently replaced with the real thing when libpthreads is loaded into the 
process' address space.

Other libraries which need to be thread-agnostic then won't need any special 
initialization at all, nor would there be any race conditions any more.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 03 May 2010 10:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Howard Chu <hyc@highlandsun.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 03 May 2010 10:57:05 GMT) Full text and rfc822 format available.

Message #90 received at 566351@bugs.debian.org (full text, mbox):

From: Howard Chu <hyc@highlandsun.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 566351@bugs.debian.org
Subject: Re: Bug#566351: libgcrypt problem
Date: Mon, 03 May 2010 03:55:21 -0700
Simon Josefsson wrote:
> Howard Chu<hyc@highlandsun.com>  writes:
>> 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.

Yes, as I pointed out in the Ubuntu bug report, nss-pam-ldapd and/or OpenLDAP 
nssov completely avoids this specific problem, but the problems in 
GnuTLS/libgcrypt remain.

> 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.

And again in this specific instance, OpenSSL still works correctly with 
nss-ldap, because nss-ldap provides its own mutex locking already. The reason 
people are noticing this problem now is because GnuTLS/libgcrypt *don't* 
behave correctly, even when initialized as documented *and* locking is taken 
care of at a higher level.

>> (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.

Your example here is a poor one, for a number of reasons. First of all you're 
assuming a single global entropy pool, which is already a design flaw. If you 
associate the entropy pool with a caller context, most of this problem goes 
away. Secondly, on most of the platforms of interest, OpenSSL simply reads 
from /dev/[u]random or EGD/PRNGD, and the read() is an atomic operation and 
doesn't need thread/reentrancy protection.

If you properly partition the library state across context handles and session 
handles most of the need for mutexes disappears. IMO the fact that OpenSSL 
uses context handles and neither GnuTLS nor MozillaNSS do makes OpenSSL 
superior for deployment in real world environments, because many 
libraries/code contexts within one process can use OpenSSL without stepping on 
each other, and that's the default behavior.

Anyway, probably the first step for GnuTLS is to add a new init API that also 
initializes gcrypt threading, so that apps do all of their interaction solely 
with GnuTLS, instead of having to also use gcrypt init APIs and hope they 
actually coordinate correctly.
-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/




Severity set to 'grave' from 'normal' Request was from David Adam <zanchey@ucc.gu.uwa.edu.au> to control@bugs.debian.org. (Fri, 10 Dec 2010 03:45:08 GMT) Full text and rfc822 format available.

Severity set to 'normal' from 'grave' Request was from David Adam <zanchey@ucc.gu.uwa.edu.au> to control@bugs.debian.org. (Fri, 10 Dec 2010 03:51:06 GMT) Full text and rfc822 format available.

Forcibly Merged 368297 545414 566351. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Fri, 31 Dec 2010 22:09:06 GMT) Full text and rfc822 format available.

Added indication that 566351 affects libldap-2.4-2 Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Fri, 31 Dec 2010 22:09:07 GMT) Full text and rfc822 format available.

Forcibly Merged 368297 545414 566351 579647 601667. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 21 May 2011 20:21:06 GMT) Full text and rfc822 format available.

Removed indication that 566351 affects libldap-2.4-2 Added indication that 566351 affects libnss-ldap Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 21 May 2011 20:21:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Thu, 26 May 2011 18:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <clint@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 26 May 2011 18:03:03 GMT) Full text and rfc822 format available.

Message #107 received at 566351@bugs.debian.org (full text, mbox):

From: Clint Adams <clint@debian.org>
To: Simon Josefsson <simon@josefsson.org>, 566351@bugs.debian.org
Cc: Howard Chu <hyc@highlandsun.com>
Subject: Re: Bug#566351: libgcrypt problem
Date: Thu, 26 May 2011 18:06:39 +0000
On Mon, May 03, 2010 at 03:55:21AM -0700, Howard Chu wrote:
> Anyway, probably the first step for GnuTLS is to add a new init API
> that also initializes gcrypt threading, so that apps do all of their
> interaction solely with GnuTLS, instead of having to also use gcrypt
> init APIs and hope they actually coordinate correctly.

Is this a viable possibility?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Thu, 26 May 2011 18:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 26 May 2011 18:09:07 GMT) Full text and rfc822 format available.

Message #112 received at 566351@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Clint Adams <clint@debian.org>, 566351@bugs.debian.org
Cc: Simon Josefsson <simon@josefsson.org>, Howard Chu <hyc@highlandsun.com>
Subject: Re: Bug#566351: libgcrypt problem
Date: Thu, 26 May 2011 14:07:21 -0400
[Message part 1 (text/plain, inline)]
On 05/26/2011 02:06 PM, Clint Adams wrote:
> On Mon, May 03, 2010 at 03:55:21AM -0700, Howard Chu wrote:
>> Anyway, probably the first step for GnuTLS is to add a new init API
>> that also initializes gcrypt threading, so that apps do all of their
>> interaction solely with GnuTLS, instead of having to also use gcrypt
>> init APIs and hope they actually coordinate correctly.
> 
> Is this a viable possibility?

given that the development head of gnutls (2.99.2) just dropped
libgcrypt support in favor of nettle, it seems unlikely to me.

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Forcibly Merged 368297 545414 566351 579647 601667 628671. Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Sat, 25 Jun 2011 10:42:14 GMT) Full text and rfc822 format available.

Changed Bug submitter to 'ansgar@debian.org' from 'Ansgar Burchardt <ansgar@2008.43-1.org>' Request was from Ansgar Burchardt <ansgar@43-1.org> to control@bugs.debian.org. (Sun, 11 Dec 2011 12:08:01 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Sat, 03 Nov 2012 17:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 03 Nov 2012 17:33:03 GMT) Full text and rfc822 format available.

Message #121 received at 566351@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 566351@bugs.debian.org
Cc: gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Sat, 3 Nov 2012 18:29:22 +0100
On 2010-01-23 Andreas Metzler <ametzler@downhill.at.eu.org> wrote:
> On 2010-01-23 Ansgar Burchardt <ansgar@2008.43-1.org> wrote:
> > the function lock_pool from src/secmem.c has the side effect of changing
> > user ids if real uid != effective uid.  This causes strange behaviour in
> > other programs:

> > A program using libnss-ldap for querying group membership with SSL
> > enabled, but without nscd might suddenly change the user id when calling
> > getgroups (or initgroups).  An example for this is the atd daemon[1].

There is very long Ubuntu bug about the issue
<https://bugs.launchpad.net/debian/+source/sudo/+bug/423252>, this
comment sums it up:
<https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72>

Ubuntu is now shipping libgcrypt with this patch
--------------------------------
+--- a/src/global.c
++++ b/src/global.c
+@@ -445,8 +445,6 @@
+
+     case GCRYCTL_SET_THREAD_CBS:
+       err = ath_install (va_arg (arg_ptr, void *), any_init_done);
+-      if (! err)
+-      global_init ();
+       break;
+
+     case GCRYCTL_FAST_POLL:
--------------------------------

which might be replaced by the following one to fix
<https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798>.
------------------------------
--- libgcrypt11-1.5.0.orig/src/global.c
+++ libgcrypt11-1.5.0/src/global.c
@@ -370,11 +370,13 @@ _gcry_vcontrol (enum gcry_ctl_cmds cmd,
       break;
 
     case GCRYCTL_DISABLE_SECMEM_WARN:
+      global_init ();
       _gcry_secmem_set_flags ((_gcry_secmem_get_flags ()
                               | GCRY_SECMEM_FLAG_NO_WARNING));
       break;
 
     case GCRYCTL_SUSPEND_SECMEM_WARN:
+      global_init ();
       _gcry_secmem_set_flags ((_gcry_secmem_get_flags ()
                               | GCRY_SECMEM_FLAG_SUSPEND_WARNING));
       break;
@@ -445,8 +447,6 @@ _gcry_vcontrol (enum gcry_ctl_cmds cmd,
 
     case GCRYCTL_SET_THREAD_CBS:
       err = ath_install (va_arg (arg_ptr, void *), any_init_done);
-      if (! err)
-       global_init ();
       break;
 
     case GCRYCTL_FAST_POLL:
------------------------------

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Wed, 07 Nov 2012 10:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 07 Nov 2012 10:33:03 GMT) Full text and rfc822 format available.

Message #126 received at 566351@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Andreas Metzler <ametzler@downhill.at.eu.org>
Cc: 566351@bugs.debian.org, gcrypt-devel@gnupg.org
Subject: Re: Bug#566351: libgcrypt11: should not change user id as a side effect
Date: Wed, 07 Nov 2012 10:31:16 +0100
On Sat,  3 Nov 2012 18:29, ametzler@downhill.at.eu.org said:

> comment sums it up:
> <https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72>

Well, it is the usual problem with inter-library dependencies.  We will
never be able to get this right.  The DSO is just not designed to work
with completely independent libraries.  I don't like to say, but in this
regard Windows DLLs are a better solution.

Although we can't solve all the problems we will be able to solve the
thread initialization problem.  Libgcrypt 1.6 will ignore the thread
callbacks and assume pthread.  Semaphores are then used for locking and
provide a way to do thread-safe initialization.  The hopefully minor
drawback is that one needs to link against librt.


> +     case GCRYCTL_SET_THREAD_CBS:
> +       err = ath_install (va_arg (arg_ptr, void *), any_init_done);
> +-      if (! err)
> +-      global_init ();

Okay, if that works, fine.  It might break other things; I don't know.
There are enough selftests to hopefully detect such a break (in
particular in FIPS mode).


Salam-Shalom,

   Werner

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




Added tag(s) d-i and patch. Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Tue, 22 Jan 2013 18:18:12 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658896 Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Tue, 22 Jan 2013 18:18:14 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'normal' Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Wed, 23 Jan 2013 12:27:08 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658896 Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Wed, 23 Jan 2013 17:54:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Thu, 24 Jan 2013 23:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 24 Jan 2013 23:48:07 GMT) Full text and rfc822 format available.

Message #139 received at 566351@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, adam.stokes@canonical.com
Cc: 368297@bugs.debian.org, 545414@bugs.debian.org, 566351@bugs.debian.org, 579647@bugs.debian.org, 601667@bugs.debian.org, 628671@bugs.debian.org, 658896@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org, pkg-gnutls-maint@lists.alioth.debian.org, control@bugs.debian.org
Subject: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
Date: Fri, 25 Jan 2013 00:44:21 +0100
[Message part 1 (text/plain, inline)]
reassign 368297 libldap-2.4 2.4.31-1
thanks

Hi!


I have been digging on this issue and I found the ultimate cause of this
problem.


When sudo/su/passwd/<insert-any-setuid-program-that-calls-getpwent()> on
a system configured with PAM/LDAPs it chains into libldap, which uses
GnuTLS/libgcrypt to manage the TLS channel.


The problem is that when OpenLDAP calls gnutls_global_init(), this
function does nothing because OpenLDAP had previously already
initialized libgcrypt at some point on the stack (probably by mistake).

So, gnutls_global_init() checks that some basic initialization of
libgcrypt was already done and skips completely any action.

The problem is that gnutls_global_init() is supposed to set the flag
GCRYCTL_DISABLE_SECMEM which disables both the use of secure memory
*and* the "feature" of dropping privileges that libgcrypt has. [1]

So, what is happening is that the initialization of libgcrypt is not
being done as expected.

I cooked a very small patch that, just after calling
gnutls_global_init() checks if the initialization was successful, and if
was not, then it sets this flag (DISABLE_SECMEM)

I understand that (perhaps) the right fix could be to patch GnuTLS to
check for INITIALIZATION_FINISHED instead of ANY_INITIALIZATION. But
there are two problems with this:

 * One is that this could introduce some regression or bug on some
program that could be (wrongly) relying on this "feature" of GnuTLS.
Keep in mind that this code has been there since the beginning of the
project (I was blaming the git repository)


* The second problem is that GnutTLS (upstream) completely dropped the
support for libgcrypt (they even removed the code). So IMHO it don't
makes sense to fix GnuTLS at this point. For Jessie, GnuTLS should
switch to nettle. And OpenLDAP will have to switch to another crypto
library other than libgcrypt, or will have to patch the file
libraries/libldap/tls_g.c to stop using any GnuTLS code.


So, for the moment (Wheezy) I think the best approach to solve this bug
is to apply the small patch for OpenLDAP that I'm attaching.
It is the less intrusive approach to fix this bug. It don't needs to
touch anything on GnuTLS or libgcrypt. It is really fixing the problem
where is: OpenLDAP is not setting DISABLE_SECMEM when initializing
libgcrypt.

The approach taken by Ubuntu, to patch libgcrypt (LP: #423252), already
caused some regressions (LP: #1013798)


If someone wants to try it, I have uploaded the debs (AMD64) and the
sources to this URL:

http://ftp.neutrino.es/debian/OpenLDAP/


I tested that with this small patch the problem goes completely away.

Example of test:
----------------
1) Install current libldap-2.4-2 from Wheezy and test sudo:
root ~ # apt-get install --reinstall libldap-2.4-2=2.4.31-1

clopez ~ $ sudo whoami
[sudo] password for clopez:
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/clopez/8: Operation not permitted
sudo: unable to set supplementary group IDs: Operation not permitted
sudo: unable to execute /usr/bin/whoami: Operation not permitted


2) Install fixed libldap-2.4-2 and test sudo:
root ~ # wget
http://ftp.neutrino.es/debian/OpenLDAP/libldap-2.4-2_2.4.31-1.1_amd64.deb
root ~ # dpkg -i libldap-2.4-2_2.4.31-1.1_amd64.deb


clopez ~ $ sudo whoami
[sudo] password for clopez:
root
-------------

Therefore I'm reassigning this bug to libldap-2.4 (src:OpenLDAP)

Attached is also a debdiff for src:OpenLDAP


Read the comments inside the patch for further information.


I'm CC'ing libgcrypt/OpenLDAP/GnuTLS maintainers and will be later
reporting on Ubuntu's LP this.



Regards!
--------

[1]
http://lists.debian.org/debian-devel/2010/03/msg00298.html
https://bugs.g10code.com/gnupg/issue1181
[debdiff_openldap_fix-dropping-privileges-by-libgcrypt-secmem.debdiff (text/plain, attachment)]
[fix-dropping-privileges-by-libgcrypt-secmem.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, attachment)]

Bug reassigned from package 'libgcrypt11' to 'libldap-2.4'. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:19 GMT) Full text and rfc822 format available.

No longer marked as found in versions libgcrypt11/1.4.4-6. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:21 GMT) Full text and rfc822 format available.

Marked as found in versions 2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:23 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libldap-2.4' to 'libldap-2.4-2'. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:10 GMT) Full text and rfc822 format available.

No longer marked as found in versions 2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:13 GMT) Full text and rfc822 format available.

Marked as found in versions openldap/2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:15 GMT) Full text and rfc822 format available.

Unset Bug forwarded-to-address Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 04:27:04 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658739 658896 Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Tue, 05 Feb 2013 03:24:16 GMT) Full text and rfc822 format available.

Removed tag(s) d-i. Request was from Adam D. Barratt <adam@adam-barratt.org.uk> to control@bugs.debian.org. (Wed, 20 Feb 2013 11:33:03 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libldap-2.4-2' to 'libgcrypt11'. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 14 Apr 2013 18:39:05 GMT) Full text and rfc822 format available.

No longer marked as found in versions openldap/2.4.31-1. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 14 Apr 2013 18:39:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#566351; Package libgcrypt11. (Mon, 22 Apr 2013 16:33:23 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 22 Apr 2013 16:33:23 GMT) Full text and rfc822 format available.

Message #166 received at 566351@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>, 368297@bugs.debian.org
Cc: Andreas Metzler <ametzler@downhill.at.eu.org>, adam.stokes@canonical.com, 545414@bugs.debian.org, 566351@bugs.debian.org, 579647@bugs.debian.org, 601667@bugs.debian.org, 628671@bugs.debian.org, 658896@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org, pkg-gnutls-maint@lists.alioth.debian.org, control@bugs.debian.org
Subject: Re: Bug#368297: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
Date: Mon, 22 Apr 2013 18:30:11 +0200
[Message part 1 (text/plain, inline)]
tags 368297 + wheezy-ignore
user release.debian.org@packages.debian.org
usertag 368297 + wheezy-can-defer

On Fri, Jan 25, 2013 at 00:44:21 +0100, Carlos Alberto Lopez Perez wrote:

> When sudo/su/passwd/<insert-any-setuid-program-that-calls-getpwent()> on
> a system configured with PAM/LDAPs it chains into libldap, which uses
> GnuTLS/libgcrypt to manage the TLS channel.
> 
So I've tried to reproduce that, by installing sudo-ldap, slapd,
lib{nss,pam}-ldap, ssl-cert and configuring stuff to use
ldaps://localhost.  Seems like things work when the user is in
/etc/passwd, and fail if they're in ldap.
The failure goes away when switching to lib{nss,pam}-ldapd, which was
already the recommended workaround for this bug in squeeze.

I understand that some use cases aren't supported by this alternative,
but:
- AIUI this was already the case in squeeze
- the way forward is probably to improve on them, for jessie, not try
  and keep lib{nss,pam}-ldap around indefinitely

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Added tag(s) wheezy-ignore. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Mon, 22 Apr 2013 16:33:38 GMT) Full text and rfc822 format available.

Added tag(s) squeeze-ignore. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Wed, 06 Nov 2013 02:33:18 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 19:27:52 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.