openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#4753) Minor section error in slapo-retcode manpage
by gael.roualland＠oleane.net 15 Nov '06

15 Nov '06

Full_Name: Gaël Roualland Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) There is a minor typo in slapo-retcode manpage nroff header. The first line reads: .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" A blank is missing between SLAPO-RETCODE and the section 5.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Russ Allbery 14 Nov '06

14 Nov '06

Quanah Gibson-Mount <quanah(a)stanford.edu> writes: > Russ Allbery <rra(a)debian.org> wrote: >> So, what does it do, then? How doesn't it work? What would work >> instead given the above constraint? > I'll note I opened ITS#4750 upstream on this issue. Howard has said > that if a good security argument can be made, it could be committed into > the current (2.3+ releases). The security argument is made in the Debian bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387467> specifically: | > I'm curious about this, are you sure a libldap would read an "ldaprc" | > file when run from a setuid program? | | Yep: | | # ls -l /usr/bin/passwd | -rwsr-xr-x 1 root root 32296 2006-08-25 19:49 /usr/bin/passwd | # mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.away | | $ cd /tmp | $ passwd testuser | passwd: unknown user testuser | $ echo 'TLS_CACERT /etc/ssl/certs/ldapca.pem' > ldaprc | $ passwd testuser | passwd: You may not view or modify password information for testuser. | | > Or that it'd read the | > current-directory ldaprc in that situation? Can you provide an strace | > showing this happening? | | The interesting fragments: | | execve("/usr/bin/passwd", ["passwd", "testuser"], [/* 16 vars */]) = 0 | [...] | access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) | [...] | getuid32() = 1000 | [...] | geteuid32() = 0 | [...] | open("/etc/libnss-ldap.conf", O_RDONLY) = 3 | [...] | open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) | open("ldaprc", O_RDONLY|O_LARGEFILE) = 3 | | There is no path component in the last open(), so ldaprc is always read | from the current directory. | | > Also, the user would have to have access to more than the ldaprc file, | > no? Since the user couldn't control what server is being connected to | > without more control on the system, or control over the DNS, etc. | | True, but DNS poisoning is trivial (especially in a large local network | with lots of not-so-trusted machines). If I'd trust the network I'd have | no need for TLS at all... Clearly the user should have an /etc/ldap/ldap.conf under any normal circumstance, and a configuration that does not is most likely broken. However, my argument is that while there may be cases where a user creating a security vulnerability through a broken configuration is simply the user's problem, I believe this is a case where the action taken has no intuitive connection to security. This was initially noticed because a user was putting all their LDAP options in /etc/libnss-ldap.conf rather than in /etc/ldap/ldap.conf, which may be broken but which is not something that is obviously broken from a *security* standpoint. Having a library attempt to open files in the current directory and read them for configuration is highly non-intuitive and unexpected. Having it read configuration out of the user's home directory is less so, but in the case of setuid programs is still rather disturbing, particularly since the setuid program has no direct control over this behavior. So, I see two potential problems here: * A user can override the LDAP configuration of a setuid binary and cause it to, for instance, trust LDAP servers that it wouldn't otherwise trust, which is a potential attack (albeit a difficult one to exploit). If the setuid binary knows that it's using LDAP, it can avoid this via an environment variable, but frequently given such things as NSS plugins and PAM modules the binary isn't going to know that LDAP is involved. The primary problem here is that said setuid binary will read the configuration file based on HOME from the enviroment (it appears to me from the code) or the current directory (the above example), which violates one of the standard secure programming practices for setuid binaries (never trust the process environment including working directory that you're handed by the user). * The library may fall back to reading a file out of the current directory. I don't know if this behavior persists in 2.3; the above example is from 2.1. If it does persist, it opens other potential problems that don't involve setuid but instead involve creating files in the current working directory of a process one wishes to attack. Again, due to the plugin nature of current operating systems, the process being attacked may not even be aware that it's using LDAP. I think this exploit is unlikely to occur in practice since it requires some attacker control over the home directory of the process being attacked, but it's theoretically present. Steve's patch addresses the first issue but doesn't do much about the second, so it's an improvement but I'm not sure it's a complete solution. Unfortunately, this support is also important for the current functionality of the command-line tools and doubtless other programs that use the LDAP libraries. What we ideally need is some way for a user of the LDAP libraries to say, through the API, that user configuration files should not be loaded but that isn't a process-wide flag that interferes with the expected behavior of other uses of LDAP elsewhere in the same process. And as mentioned, I don't see an obvious way to do that without changing the API, which is, of course, a pain. In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position. I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag. -- Russ Allbery (rra(a)debian.org) <http://www.eyrie.org/~eagle/>

2 6

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 14 Nov '06

14 Nov '06

quanah(a)stanford.edu wrote: > --On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > > >> I note that nss/pam-ldap setting NOINIT (or otherwise mucking >> with libldap options) might break LDAP-enabled programs. But >> that's another matter. >> >> Anyways, I think the only good fix (for this and many other >> larger problems) is a library redesign/rewrite. > > Okay. > > I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap > source, maybe it was removed at some point? I'm looking at the latest code > from PADL. > > Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the > environment? Which has other problems. For the specific case of nss/pam_ldap the obvious solution is to require that they never use default values anywhere. Generally that is already what happens anyway. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4752) back-config Adds are not atomic
by hyc＠OpenLDAP.org 14 Nov '06

14 Nov '06

Full_Name: Howard Chu Version: HEAD/23/24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When LDAPAdding various types of entries under cn=config, failures in some later portion of the entry will cause the operation to fail but anything already set remains set. The current approach of using check_vals to validate before doing the main processing is inadequate. It may be possible to extend the current pre-check approach, otherwise we'll need to do something like define destructors for everything.

1 0

(ITS#4751) back-perl crashing with anonymous search request
by rhafer＠suse.de 14 Nov '06

14 Nov '06

Full_Name: Ralf Haferkamp Version: HEAD, RE23 OS: SUSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.155.116) I created a simple back-perl setup with the SampleLDAP.pm Module (slightly enhanced with a bind() method that just returns SUCCESS) from CVS Head and slapd crashed on me immediately on receiving the first anonymous search request. It survived however when I issued bind requests followed by search request. While digging through the code I found that back_perl_bind calls "PERL_SET_CONTEXT( PERL_INTERPRETER );" since a few revisions. All other back_perl_* functions (search, delete, modify, ...) do not call PERL_SET_CONTEXT, adding that seems to fix the crash. The perlembed man-pages state related to PERL_SET_CONTEXT: "PERL_SET_CONTEXT(interp) should also be called whenever "interp" is used by a thread that did not create it (using either perl_alloc(), ..." I'll commit a fix that adds PERL_SET_CONTEXT calls to the other functions as well (wrapped behind #ifdefs just like in back_perl_bind()).

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 13 Nov '06

13 Nov '06

--On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > I note that nss/pam-ldap setting NOINIT (or otherwise mucking > with libldap options) might break LDAP-enabled programs. But > that's another matter. > > Anyways, I think the only good fix (for this and many other > larger problems) is a library redesign/rewrite. Okay. I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap source, maybe it was removed at some point? I'm looking at the latest code from PADL. Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the environment? Which has other problems. >From the source of libldap: init.c: if( getenv("LDAPNOINIT") != NULL ) { --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

It was my intent when ldap.conf(5) was designed that it only provide defaults when selected by the user. For instance, a hostname when the user provides none. While libldap always read ldap.conf/.ldaprc, that wasn't considered a big deal. However, with various init options which are used without program selection, programs need now to provide an option to disable initialization. Ugh. I have noted that if I had to do it all over again, libldap would never read ldap.conf(5). Instead the program would have to separately call out to facility to obtain defaults. Some of RRA suggests are not workable. For instance, as now some options can only be set via ldap.conf(5)/.ldaprc, disabling it for root disallows root to use all features of programs and the library. But this is all water under the bridge. The library is what it is. Changing it would likely break other things. I note that nss/pam-ldap setting NOINIT (or otherwise mucking with libldap options) might break LDAP-enabled programs. But that's another matter. Anyways, I think the only good fix (for this and many other larger problems) is a library redesign/rewrite. Kurt At 08:04 PM 11/13/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: >Submission from: (NULL) (171.66.155.86) > > >The debian folks committed the following patch: > >Modified: openldap/trunk-2.1/libraries/libldap/init.c >=================================================================== >--- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev >749) >+++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev >750) >@@ -252,6 +252,12 @@ > char *home; > char *path = NULL; > >+ if (getuid() != geteuid()) { >+ /* Caller is setuid -- don't read any per-user configs in >+ these circumstances, as this may not be safe */ >+ return; >+ } >+ > if (file == NULL) { > /* no file name */ > return; > > >You can see this is against 2.1, but the code is essentially the same in OL >HEAD. > >The reason was: > >+ * Don't check for user configuration files when the caller is setuid; >+ addresses #387467, which is a potential security hole allowing >+ libnss-ldap settings to be overridden. Thanks to Stephen Frost for >+ bringing this to my attention. > > >which Howard note is not really the right way to do this. > >[19:07] Howard Chu: that's the wrong fix >[19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. >[19:09] Quanah: so this patch doesn't really fix anything? >[19:09] Howard Chu: probably not. > > >However, one of my co-workers notes: > > >19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy >fix because it means that every single binary that uses the LDAP libraries > and may be setuid has to know to do this. >19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. >19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home >directory, though. >19:50 <rra@home> Is that really what it's doing? >19:50 <rra@home> Something along those lines? >19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… >19:50 <Q> it can read .ldaprc, yes >19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. >19:51 <rra@home> That to me violates abstraction layers. >19:51 <rra@home> Applications are not going to expect libraries to do that. >19:51 <rra@home> The *right* solution would to me be to not do that; failing >that, I think OpenLDAP should bear the responsibility to do it securely, which > would include not reading user .ldaprc files when running as root. (There >are other ways to prevent that, of course.) >19:55 <rra@home> Basically, my argument is more that there should be a mode that >loads user configuration, but it probably shouldn't be the default > interface. >19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be >fixed regardless to pass that flag. > > >So, thoughts appreciated. > >--Quanah

1 0

(ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 13 Nov '06

13 Nov '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: Submission from: (NULL) (171.66.155.86) The debian folks committed the following patch: Modified: openldap/trunk-2.1/libraries/libldap/init.c =================================================================== --- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev 749) +++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev 750) @@ -252,6 +252,12 @@ char *home; char *path = NULL; + if (getuid() != geteuid()) { + /* Caller is setuid -- don't read any per-user configs in + these circumstances, as this may not be safe */ + return; + } + if (file == NULL) { /* no file name */ return; You can see this is against 2.1, but the code is essentially the same in OL HEAD. The reason was: + * Don't check for user configuration files when the caller is setuid; + addresses #387467, which is a potential security hole allowing + libnss-ldap settings to be overridden. Thanks to Stephen Frost for + bringing this to my attention. which Howard note is not really the right way to do this. [19:07] Howard Chu: that's the wrong fix [19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. [19:09] Quanah: so this patch doesn't really fix anything? [19:09] Howard Chu: probably not. However, one of my co-workers notes: 19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy fix because it means that every single binary that uses the LDAP libraries and may be setuid has to know to do this. 19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. 19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home directory, though. 19:50 <rra@home> Is that really what it's doing? 19:50 <rra@home> Something along those lines? 19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… 19:50 <Q> it can read .ldaprc, yes 19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. 19:51 <rra@home> That to me violates abstraction layers. 19:51 <rra@home> Applications are not going to expect libraries to do that. 19:51 <rra@home> The *right* solution would to me be to not do that; failing that, I think OpenLDAP should bear the responsibility to do it securely, which would include not reading user .ldaprc files when running as root. (There are other ways to prevent that, of course.) 19:55 <rra@home> Basically, my argument is more that there should be a mode that loads user configuration, but it probably shouldn't be the default interface. 19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be fixed regardless to pass that flag. So, thoughts appreciated. --Quanah

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 13 Nov '06

13 Nov '06

G'Day Kurt Yes, RFC 2307 is restrictive re: limiting the legal character set for the nisNetgroupTripleSyntax values to a "keystring" (ref: RFC 2252). What I find irksome probably boils down to:- Since LDAP was originally designed to gateway requests to X.500 servers that the character set of an IA5String should be legal. (RFC 2307, section 2.4, X.500 nisNetgroupTripleSyntax) With the added twist of the knife, that underscores are legal in the user CN's when doing the nisMapName=netgroup.byuser Note: OS specific "bad chars" still need to be taken into account by the implementer. Since the "nisNetgroupTripleSyntax" is unlikely to change from "keystring" to IA5String in the near future for OpenLDAP, I think I'll have to consider our options re: netgroup configuration and use. Regards IT Manager 2 Kurt D. Zeilenga wrote: > At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >> Full_Name: IT Manager 2 >> Version: 2.3 & 2.4 >> OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >> URL: >> Submission from: (NULL) (220.233.132.66) >> >> >> Src ./servers/slapd/schema_init.c >> Function nisNetgroupTripleValidate >> >> Fails validate of NIS Netgroup triplet when an underscore is used in a username, >> hostname or domainname. > > I believe this is the intended behavior. > >> Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". > > RFC 2307 is more restrictive. > > >> suggest change line >> } else if ( !AD_CHAR( *p ) ) { >> to >> } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { >> >> Regards >> IT Manager 2 > >

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

Kurt(a)OpenLDAP.org wrote: > Same applies to timeouts as well. Basically, items are intended > to provide defaults for applications which say "use default". > Having options, such as this and various timeouts, which get used > by the library without application saying "use default" are > quite problematic and should be avoided. > See my comment above; ldap.conf(5) sounds like a good place to put parameters that existing applications wouldn't allow. Maybe allowing things like timeouts as user-only would be a solution, since a user can force LDAPCONF for specific applications and alter their behavior. By now, I'd remove the RESTART option but leave the NETWORK_TIMEOUT in place. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs