openldap-bugs September 2017

openldap-bugs@openldap.org

35 participants
128 discussions

Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by hyc＠symas.com 06 Sep '17

06 Sep '17

yos-nishino(a)ys.jp.nec.com wrote: > Dear Howard-san, > >> That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant. > > I saw memory.c again.=20 > As you told, I confirmed the comment was available only when LDAP_MEMORY_DE= > BUG was used(from line 27 to line 119). > > I am sorry to bother you, and I am grateful for your help. > I am going to use "case2" patch, which I expect slapd_crypt() becomes much = > faster. Thanks for the patch, now in git master. -- -- 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

Re: (ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 06 Sep '17

06 Sep '17

I'll say it another way. ldapsearch is asking for 200 items at a time. But it gets 2000 from the local slapd, when pcache is enabled. What the local client is asking of slapd should be separate from how it talks to the back-ldap. If the back-ldap returns more results then the requested page size, then slapd should handle that. On Wed, Sep 6, 2017 at 12:59 PM, Adam Heath <adam(a)brainfood.com> wrote: > No, it's a pcache bug. > > 10.10.55.128(remote active directory) works > localhost(without pcache) works > localhost(with pcache) breaks. > > Paging of the results *does* work with AD. And works with back-ldap, > pointed at AD. It's only when pcache is added that the paging options > are ignored. > > On Wed, Sep 6, 2017 at 12:48 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> --On Wednesday, September 06, 2017 6:15 PM +0000 adam(a)brainfood.com wrote: >> >>> Full_Name: Adam Heath >>> Version: 2.4.44 >>> OS: debian stretch >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (99.146.168.62) >>> >>> >>> I have configured slapd to proxy to a remote server. >>> >>> Using ldapsearch, I can talk directly to that remote server, and using the >>> pr=200/noprompt option, I get back 2900 results. >>> >>> Pointing ldapsearch at localhost, *without* pcache, I get the same set of >>> results(pages, and the final count is correct). >>> >>> When I enabled slapo-pcache, with *no* attribute sets, then the paging >>> options are removed, and I get only 2000 results(the max-size from the >>> remote server). >> >> >> Hi Adam, >> >> slapo-pcahce is acting in the correct fashion. It would appear that your >> remote system is Active Directory, which in typical Microsoft fashion, >> deliberately mis-implements paged results so that it incorrectly ignores the >> maxsize setting when paged results are in use (contrary to specifications). >> I would generally suggest talking to the AD administrator so that the bind >> identity of the pcache database is not subject to the maxsize limitation. >> >> This ITS will be closed. >> >> Regards, >> 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#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 06 Sep '17

06 Sep '17

No, it's a pcache bug. 10.10.55.128(remote active directory) works localhost(without pcache) works localhost(with pcache) breaks. Paging of the results *does* work with AD. And works with back-ldap, pointed at AD. It's only when pcache is added that the paging options are ignored. On Wed, Sep 6, 2017 at 12:48 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, September 06, 2017 6:15 PM +0000 adam(a)brainfood.com wrote: > >> Full_Name: Adam Heath >> Version: 2.4.44 >> OS: debian stretch >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.146.168.62) >> >> >> I have configured slapd to proxy to a remote server. >> >> Using ldapsearch, I can talk directly to that remote server, and using the >> pr=200/noprompt option, I get back 2900 results. >> >> Pointing ldapsearch at localhost, *without* pcache, I get the same set of >> results(pages, and the final count is correct). >> >> When I enabled slapo-pcache, with *no* attribute sets, then the paging >> options are removed, and I get only 2000 results(the max-size from the >> remote server). > > > Hi Adam, > > slapo-pcahce is acting in the correct fashion. It would appear that your > remote system is Active Directory, which in typical Microsoft fashion, > deliberately mis-implements paged results so that it incorrectly ignores the > maxsize setting when paged results are in use (contrary to specifications). > I would generally suggest talking to the AD administrator so that the bind > identity of the pcache database is not subject to the maxsize limitation. > > This ITS will be closed. > > Regards, > 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#8724) slapo-pcache truncates remote results
by quanah＠symas.com 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 6:15 PM +0000 adam(a)brainfood.com wrote: > Full_Name: Adam Heath > Version: 2.4.44 > OS: debian stretch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.146.168.62) > > > I have configured slapd to proxy to a remote server. > > Using ldapsearch, I can talk directly to that remote server, and using the > pr=200/noprompt option, I get back 2900 results. > > Pointing ldapsearch at localhost, *without* pcache, I get the same set of > results(pages, and the final count is correct). > > When I enabled slapo-pcache, with *no* attribute sets, then the paging > options are removed, and I get only 2000 results(the max-size from the > remote server). Hi Adam, slapo-pcahce is acting in the correct fashion. It would appear that your remote system is Active Directory, which in typical Microsoft fashion, deliberately mis-implements paged results so that it incorrectly ignores the maxsize setting when paged results are in use (contrary to specifications). I would generally suggest talking to the AD administrator so that the bind identity of the pcache database is not subject to the maxsize limitation. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 06 Sep '17

06 Sep '17

Full_Name: Adam Heath Version: 2.4.44 OS: debian stretch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.146.168.62) I have configured slapd to proxy to a remote server. Using ldapsearch, I can talk directly to that remote server, and using the pr=200/noprompt option, I get back 2900 results. Pointing ldapsearch at localhost, *without* pcache, I get the same set of results(pages, and the final count is correct). When I enabled slapo-pcache, with *no* attribute sets, then the paging options are removed, and I get only 2000 results(the max-size from the remote server). Command: docker exec -ti caching-ad ldapsearch -E pr=200/noprompt -o ldif-wrap=no -z none -w 'XXXX' -b 'XXXX' -D 'XXXX' '(objectclass=group)' dn -h localhost|grep -A 5 '# search result' slapd.conf: == egrep -v '^(#|$)' ../app-hosting/brainfood-docker-image-recipes/openldap/files/caching-slapd.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema attributetype ( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_ldap.la moduleload back_hdb.la moduleload back_bdb.la moduleload rwm moduleload pcache.la moduleload memberof.la sizelimit 5000 tool-threads 1 backend ldap readonly yes database ldap protocol-version 3 rebind-as-user norefs yes chase-referrals no uri "ldap://192.168.178.2:389" suffix "dc=ldap01,dc=com" rootdn "cn=admin,dc=ldap01,dc=com" rootpw "foobar" overlay memberof overlay pcache proxyCache hdb 100000 3 1000 100 pcachePersist TRUE cachesize 200 directory /var/lib/ldap == I expect pcache to not truncate the results from the remote server.

1 0

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

06 Sep '17

michael(a)orlitzky.com wrote: > On 09/06/2017 09:29 AM, Howard Chu wrote: >> >> Learn something about Unix, please. >> >> Use the ps command to verify that the process at least has the correct name. >> The init script should know it's looking for a process named slapd, not init. >> > > Supposing we want to copy/paste two or more "ps" calls into every slapd > init script, this still lets a hacker prevent his own hacked process > from being killed by writing junk into the file. > > If the standard practice was to write the PID file as an unprivileged > user, we would need to not only copy/paste those "ps" calls into every > slapd init script, but literally every init script for every daemon. > Apparently my predecessors didn't want to do that, so the standard > practice is to write the PID file as root. Do with that information what > you will. Apparently your predecessors also didn't understand that PIDs get recycled. If your init scripts are just blindly trusting the contents of PID files they're all broken already. But none of that is of any concern of the OpenLDAP Project. Closing this ITS as Invalid. -- -- 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

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

06 Sep '17

On 09/06/2017 09:29 AM, Howard Chu wrote: > > Learn something about Unix, please. > > Use the ps command to verify that the process at least has the correct name. > The init script should know it's looking for a process named slapd, not init. > Supposing we want to copy/paste two or more "ps" calls into every slapd init script, this still lets a hacker prevent his own hacked process from being killed by writing junk into the file. If the standard practice was to write the PID file as an unprivileged user, we would need to not only copy/paste those "ps" calls into every slapd init script, but literally every init script for every daemon. Apparently my predecessors didn't want to do that, so the standard practice is to write the PID file as root. Do with that information what you will.

1 0

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

06 Sep '17

michael(a)orlitzky.com wrote: > On 09/06/2017 08:29 AM, Howard Chu wrote: >>> 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate >>> the weird behavior resulting from the hack. >> >> Even if that were possible, it's clearly a bug in the init script, which >> failed to check that the process with that PID was the process it was >> expecting to find. Note that this is something any init script needs to do >> anyway, since PID files can go stale and some other process may be using the >> PID by the time you reference the file. > > Have you ever seen such an init script? > > How should the init system know what process it was expecting to find, > if not by reading that process's PID from the PID file? Learn something about Unix, please. Use the ps command to verify that the process at least has the correct name. The init script should know it's looking for a process named slapd, not 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

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

06 Sep '17

On 09/06/2017 08:29 AM, Howard Chu wrote: > >> 4. Someone compromises the daemon, which sits on the open network. > > Nobody compromises slapd from the network. There are no buffer overflow > vulnerabilities, there are no RCE vulnerabilities. > Oh, it's one of /those/ daemons. >> >> 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate >> the weird behavior resulting from the hack. > > Even if that were possible, it's clearly a bug in the init script, which > failed to check that the process with that PID was the process it was > expecting to find. Note that this is something any init script needs to do > anyway, since PID files can go stale and some other process may be using the > PID by the time you reference the file. Have you ever seen such an init script? How should the init system know what process it was expecting to find, if not by reading that process's PID from the PID file? If you decide not to write the PID file as root, that's of course up to you, but I still have to tell something to the people who ship OpenLDAP as part of their distributions. I can tell them "Howard says it should be easy," but considering that no one has ever done it, that's not real helpful advice. There are only two requirements really: it needs to be portable POSIX sh, and the stop() function must only kill the one process created by start(). If you give that a shot, you might see why I suggested that this be fixed in slapd.

1 0

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

06 Sep '17

michael(a)orlitzky.com wrote: > On 09/05/2017 05:38 PM, Ryan Tandy wrote: >> >> If you would like to propose a patch, we could review that. For myself I >> don't think I would attach a high priority to this. > > I understand that it's a low priority, I'm just trying to clean up the > hundred or so cases of this that we have in Gentoo. In a few, it's > impossible to do so because of the way the daemon creates the PID file > (like it is here), so I'm doing bugs/CVEs to keep track of them. This > way that distribution maintainers have something to watch and will know > when they can fix their init scripts. Your problem scenario is still unrealistic. > 4. Someone compromises the daemon, which sits on the open network. Nobody compromises slapd from the network. There are no buffer overflow vulnerabilities, there are no RCE vulnerabilities. > 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. Even if that were possible, it's clearly a bug in the init script, which failed to check that the process with that PID was the process it was expecting to find. Note that this is something any init script needs to do anyway, since PID files can go stale and some other process may be using the PID by the time you reference the file. > 7. Oops, the machine reboots, because I killed PID 1. > Big deal, you caused a temporary service outage. No remote code was injected, no data was leaked, no actual lasting damage was done. I'm inclined to close this ticket. It presupposes a class of bug that doesn't exist in OpenLDAP code, and it relies on an additional bug in a script that isn't part of OpenLDAP code. At best, this ticket has been mis-filed and the submitter needs to submit it to somewhere relevant, like whoever authored the broken init script. -- -- 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

← Newer
1
...
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2017