openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8705) Windows registry key creation incorrect
by quanah＠openldap.org 03 Aug '17

03 Aug '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 installing OpenLDAP on windows, it creates a registry key for the Eventlog to map startup/shutdown events. There was an attempt to fix the problem with the key value back in 2003, 6e8adce9d94ffff125d6acce669c35245d73d0df. However, the fix is incorrect. Without 6e8adce9d94ffff125d6acce669c35245d73d0df, the key value is set to (on a 64-bit install): "C:\Program Files\OpenLDAP\slapd.exe service" With 6e8adce9d94ffff125d6acce669c35245d73d0df, the key value is set to (on a 64-bit install): "C:\Program" The value that works is: "C:\Program Files\OpenLDAP\slapd.exe" The goal of 6e8adce9d94ffff125d6acce669c35245d73d0df was to strip of " service", but since it simply parses on a single space, if the install path has a space elsewhere in it, you end up with the incorrect value noted above.

1 0

Re: (ITS#8701) account usability control for password less logins
by benjamin.chang＠oracle.com 02 Aug '17

02 Aug '17

Question about a proposed workaround: Would it be possible to use slapo-ppolicy to set the pwdPolicySubentry attribute for each user to provide the desired 1.3.6.1.4.1.42.2.27.9.5.8 control response (see http://ldapwiki.com/wiki/Account%20Usability%20Request%20Control), i.e., can pwdPolicySubentry be used supply the sub-entry and related operational attributes needed to validate users for password-less logins?

1 0

Re: (ITS#8690) syncprov memory leak
by quanah＠symas.com 01 Aug '17

01 Aug '17

--On Tuesday, July 11, 2017 9:17 PM +0000 quanah(a)symas.com wrote: > --On Tuesday, July 11, 2017 1:25 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.45 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (47.208.148.239) With the patch applied, test019 sporadically segfaults after doing a delete op on an entry. Took me 12/50 iterations with back-mdb, 2/50 with back-bdb. But just 1/1 on two other occasions, so while it's not every iteration, it's fairly repeatable. I will work on getting a backtrace as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8702) SLAPD_MAX_DAEMON_THREADS is too small
by quanah＠symas.com 01 Aug '17

01 Aug '17

--On Friday, July 28, 2017 5:56 PM +0000 hyc(a)openldap.org wrote: > 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. It would be nice if instead of something hard coded, it was instead configurable by switching its usage to dynamically allocated arrays. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(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

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