Bug#566351: libgcrypt11: should not change user id as a side effect
Ansgar Burchardt
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
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Metzler
> 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
Werner Koch
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.
Ansgar Burchardt
Werner Koch <w...@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
Werner Koch
> 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.
Ansgar Burchardt
> 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
Werner Koch
> 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.
Florian Weimer
> 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 <fwe...@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
Ansgar Burchardt
> On Mon, 25 Jan 2010 16:13, ans...@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
Simon Josefsson
> Werner Koch <w...@gnupg.org> writes:
>
>> On Mon, 25 Jan 2010 16:13, ans...@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
Werner Koch
> 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.
Ansgar Burchardt
Simon Josefsson <si...@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
Simon Josefsson
> Hi,
>
> Simon Josefsson <si...@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
Andreas Metzler
> On 2010-01-23 Ansgar Burchardt <ans...@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].
<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'
Werner Koch
> comment sums it up:
> <https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72>
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 ();
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.