openldap-bugs July 2017

openldap-bugs@openldap.org

22 participants
41 discussions

(ITS#8704) LMDB add option to use prev meta page
by hyc＠openldap.org 31 Jul '17

31 Jul '17

Full_Name: Howard Chu Version: LMDB 0.9 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.220) Submitted by: hyc Generally, running LMDB in NOSYNC mode means all integrity guarantees are gone, in even of a system crash. However, if some other thread runs mdb_env_sync periodically it's possible that the older DB state is still consistent, even if slightly out of date. I have always intended to add an env flag for using the older meta page, to potentially access a DB even after the latest txn snapshot was corrupted. A patch for this has been contributed, although support in the command-line tools still needs to be added.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 29 Jul '17

29 Jul '17

The problem scenario looks like the following: 1. I run "/etc/init.d/slapd start" to start the daemon. 2. slapd drops to the "slapd" user. 3. slapd writes its PID file, now owned by the "slapd" user. 4. Someone compromises the daemon, which sits on the open network. 5. The attacker is generally limited in what he can do because the daemon doesn't run as root. However, he can write "1" into the slapd.pid file, and he does. 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate the weird behavior resulting from the hack. 7. Oops, the machine reboots, because I killed PID 1.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by hyc＠symas.com 29 Jul '17

29 Jul '17

michael(a)orlitzky.com wrote: > Full_Name: Michael Orlitzky > Version: 2.4.45 > OS: Gentoo > URL: > Submission from: (NULL) (98.218.46.55) > > > The slapd daemon should create its PID file before dropping privileges. This > represents a minor security issue; additional factors are needed to make it > exploitable. > > Why? > > The purpose of the PID file is to hold the PID of the running daemon, > so that later it can be stopped, restarted, or otherwise signalled > (many daemons reload their configurations in response to a SIGHUP). > To fulfill that purpose, the contents of the PID file need to be > trustworthy. If the PID file is writable by a non-root user, then he > can replace its contents with the PID of a root process. Not sure this is a valid concern. The uid used to run services should not actually have a valid login shell, and thus should not ever be usable for any purpose other than running the daemon from init. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 28 Jul '17

28 Jul '17

Full_Name: Michael Orlitzky Version: 2.4.45 OS: Gentoo URL: Submission from: (NULL) (98.218.46.55) The slapd daemon should create its PID file before dropping privileges. This represents a minor security issue; additional factors are needed to make it exploitable. Why? The purpose of the PID file is to hold the PID of the running daemon, so that later it can be stopped, restarted, or otherwise signalled (many daemons reload their configurations in response to a SIGHUP). To fulfill that purpose, the contents of the PID file need to be trustworthy. If the PID file is writable by a non-root user, then he can replace its contents with the PID of a root process. Afterwards, any attempt to signal the PID contained in the PID file will instead signal a root process chosen by the non-root user (a vulnerability). This is commonly exploitable by init scripts that are run as root and which blindly trust the contents of their PID files. If one daemon flushes its cache in response to SIGUSR2 and another daemon drops all connections in response to SIGUSR2, it is not hard to imagine a denial-of-service by the user of the first daemon against the second.

1 0

(ITS#8702) SLAPD_MAX_DAEMON_THREADS is too small
by hyc＠openldap.org 28 Jul '17

28 Jul '17

Full_Name: Howard Chu Version: HEAD OS: Solaris 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.216.236.133) Submitted by: hyc Was benchmarking on an Oracle M8 box with 2048 SPARC VCPUs. With 1024 slapd threads configured, we needed 64 listener threads and 64 threadqueues to eliminate slapd bottlenecks, but the current default in daemon.c only allows up to 16 listener threads. It's a #ifndef so easily overridable at compile time, but 16 is probably too small in this age of processors with more and more cores.

1 0

(ITS#8701) account usability control for password less logins
by manikya.prabhu.salveru＠oracle.com 27 Jul '17

27 Jul '17

Full_Name: Manikya Version: 2.4.44 OS: Solaris 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.143.213.56) Solaris ldap clients are configured for pam_ldap and requires a control to validate users for password less logins. http://docs.oracle.com/cd/E19253-01/816-4556/schemas-250/index.html >From open-ds documentation. account usability control The account usability control provides a pair of request and response controls that can be used to determine whether a user account may be used for authenticating to the server. The request control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 and does not include a value. It should only be included in search request messages. The corresponding response control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 (the same as the request control), and it will be included in any search result entry messages for a search request that includes the account usability request control. The value for the account usability response control is encoded as follows: ACCOUNT_USABLE_RESPONSE ::= CHOICE { is_available [0] INTEGER, -- Seconds before expiration -- is_not_available [1] MORE_INFO } MORE_INFO ::= SEQUENCE { inactive [0] BOOLEAN DEFAULT FALSE, reset [1] BOOLEAN DEFAULT FALSE, expired [2] BOOLEAN DEFAULT_FALSE, remaining_grace [3] INTEGER OPTIONAL, seconds_before_unlock [4] INTEGER OPTIONAL } If the user account is available, then the control will include the number of seconds until the user's password expires, or -1 if password expiration is not enabled. If the user's account is not available, then the control will provide the reason it is unavailable.

1 0

(ITS#8700) Compile error
by papachoco＠gmail.com 26 Jul '17

26 Jul '17

Full_Name: Carlos Sanchez Version: 2.4.45 OS: macOS 10.12.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.97.40.67) I am getting the error below while compiling openldap 2.4.45 on the latest macOS sierra (10.12.6). I am only setting two configuration options configure-options = --disable-slapd --disable-slurpd Undefined symbols for architecture x86_64: "_ERR_remove_thread_state", referenced from: _tlso_destroy in libldap.a(tls_o.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [apitest] Error 1 make[1]: *** [all-common] Error 1 make: *** [all-common] Error 1 openldap_client: Command failed with exit code 2: make

1 0

(ITS#8699) More for cursor_del with DUPSORT
by hyc＠openldap.org 26 Jul '17

26 Jul '17

Full_Name: Howard Chu Version: LMDB 0.9.21 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.216.236.133) Submitted by: hyc When deleting a series of records in a loop using mdb_cursor_get(MDB_NEXT) in a DUPSORT DB, when deleting the last dup of one key, the first dup of the next key gets skipped on the next iteration. This appears to be due to an incomplete fix to ITS#8622

1 0

(ITS#8698) ppolicy: responses from pwdCheckModule discarded when using an extended password modify
by tim＠bishnet.net 26 Jul '17

26 Jul '17

Full_Name: Tim Bishop Version: 2.4.42 OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:630:340:1141::13) Whilst this issue was discovered on OpenLDAP 2.4.42, the code is unchanged on the latest version, so I believe it is still applicable there. The high-level overview of the problem is that when using the ppolicy overlay with an external pwdCheckModule, and a password is changed using the LDAPv3 Password Modify (RFC 3062) extended operation (ie. ldappasswd), the message returned by the pwdCheckModule is not passed back to the user. All other failure messages generated in ppolicy are returned correctly. I've looked into this and discovered the cause of the problem. We can start by looking at where the message is returned: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… The check_password_quality function calls out to the pwdCheckModule which sets txt to point at a malloc'd string. Here we set rs->sr_text to point to that, and make a note to free it later. This is the exception, in all other cases, as can be seen a few lines below, rs->sr_text is set to a static string. Later on, the result is returned to the user: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… And then after that, it is free'd. This all works fine for a normal password modify operation. The problem occurs when we wrap this in an extended password modify: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… This line is where the call into ppolicy originates (with a few steps in between), and then on line 237 below we see a call to send_ldap_extended (which returns rs->sr_text to the user) that includes a pointer to rs. In cases where rs->sr_text is a static string this is fine, but where we've set it to a response from pwdCheckModule it has at this point been free'd and set to NULL before send_ldap_extended gets a chance to send it. The result is that confusingly the response from pwdCheckModule is returned for non-extended password changes, but not for extended ones. I don't have a fix for this since I'm not familiar enough with the slapd code. But I'd imagine it'd require setting a flag either in rs or op to note when free'ing of rs->sr_text is required, and then move that free call as far out as necessary (back to where rs is created in connection.c?) so that rs->sr_text is always available.

1 0

(ITS#8697) Remove refptr symbols from slapd.def
by quanah＠openldap.org 20 Jul '17

20 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows 10 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When building OpenLDAP with a newer version of gcc, dlltool now exports a ton of ".refptr.FUNCTION" values out to the slapd.def file. This breaks the build process, as they aren't real functions. This is due to this change to gcc: https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00858.html Fix is simple enough, simply update our sed that we run against slapd.def: quanah@ub16:~/git/openldap/openldap-head/servers/slapd$ git diff . diff --git a/servers/slapd/Makefile.in b/servers/slapd/Makefile.in index 177ad28..0327537 100644 --- a/servers/slapd/Makefile.in +++ b/servers/slapd/Makefile.in @@ -210,7 +210,7 @@ slapd.def: libbackends.a liboverlays.a version.o dlltool --exclude-symbols main,ServiceMain@8 --export-all-symbols \ --output-def $@.tmp $$objs; echo EXPORTS > $@ - $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' $@.tmp | sort >> $@ + $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' -e '/\.refptr\./d' $@.tmp | sort >> $@ $(RM) $@.tmp symdummy.c: slapd.def

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2017