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].
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-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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]. > 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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Mon, 25 Jan 2010 14:24, ans...@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.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Werner Koch <w...@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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 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.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 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?
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.
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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ansgar Burchardt <ans...@43-1.org> writes: > 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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 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.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>>> 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
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 2010-01-23 Andreas Metzler <ametz...@downhill.at.eu.org> wrote:
> 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].
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;
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.
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.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
