openldap-bugs August 2008

openldap-bugs@openldap.org

40 participants
169 discussions

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 04 Aug '08

04 Aug '08

On Aug 3, 2008, at 11:38 AM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.112.78) > > > Source files downloadable fomr http://www.openldap.org should be > digitally > signed. It's common practice to use PGP (GnuPG) for that. Saying this should be done solely because you claim it is "common practice" is lame. It would be better to state what attacks you worry about, and why you think providing digital signatures using a trustworthy signing key, and what requirements are for this trustworthy signing key. But I note the practice is, itself, lame. Often there is no reason to trust the signing key other than where the link to the signing key was published. Often the signature itself is not widely published, or errors in providing it too far common to raise concerns in case the signature publication fails (by error or attack). For instance, web_ldap says it provides a signature for a digital release, but clicking on the link provides a page which says "Not found". Maybe your releases have been hacked, but most likely its just publication issue. Most verifiers faced with such such a "Not found" message will just not perform the verification. Often they won't even bother to raise an issue to the publisher. And if an attacker successfully takes over the main website, we have to realize that they can replace everything. Maybe they will replace whatever text we have about digital signatures with a statement that signatures are no longer provided, and then delete them. Or they may fake publication errors. They could even fake an email to the announcement list that signatures are temporarily not provided due to operational reasons, or announce a new signing key. Fortunately, it is unlikely that such an attack would go unnoticed for long period of time. I would argue that if takeover was a major threat (which it might well be), that more time should be spent detecting a takeover (we have some in place). I also find it interesting that you suggest signing tarballs and not announcement messages. I note that an attacker need not modify a tarball, or cause a new tarball to be distributed, to successfully mount an attack against the downloader. One could simply point "stable" to a known problematic release. As the signature for the problematic release would be valid, it doesn't help the downloader in detecting they got the wrong release. Of course, even if you sign release messages, the attacker can still replace the current messages with prior ones whose signatures would still be valid. But, as I noted with hashes, the fact that release messages are widely published may make it more likely that such problems will be detected. I note as well that properly deploying release signing requires more than script modification. For instance, one does need to consider that the host to sign the releases might itself been taken over and the implications of such a takeover. Also, in signing announcements, considerable testing would need to take place to ensure produced signatures were actually verifiable (lots of things muck with email in ways that invalid email signatures). Anyways, for this to go anywhere, I think you or others advocating it need to more precisely state which attacks you concerned about, how you think digital signatures will help, and detail requirements on that signing (in particular, requirements on signing key so trust can be established and maintained). I note that GNU PGP folks say that verification of a wide published message digest is sufficient to ensure the integrity of their releases. Basically, PGP signing here offers little value as an attacker who has supplanted the other protections (namely widely distributed message digests) is in position to convince most every downloader than the current release is not signed, or was signed but that signature is not currently available, or was signed by some key other than that previously used by the distributor. Note that these are human-factor attacks, not attacks based upon any weakness in the PGP signing standards or implementations.

1 0

(ITS#5641) Segmentation fault - slaptest and slapd
by hfranzke＠tee.toshiba.de 04 Aug '08

04 Aug '08

Full_Name: Helmut Franzke Version: 2.4.11 / 2.4.9 OS: Ubuntu server 8.04.1 / Centos 4.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.109.150.105) I could get slaptest/slapd to produce a segmentation fault by using the unique overlay and a unique_uri with a base dn. This behaviour depends on the position of the overlay/unique_uri in slapd.conf and doesn't appear if you don't use a base dn regardless of the position. (I know an overlay should be defined after the other configuration settings have been set. I encountered this bug when I put it in the first part by mistake, see below) I could reproduce this with OpenLdap 2.4.9 from Ubuntu 8.04.1 server as well as a fresh compiled OpenLdap 2.4.11 on Ubuntu 8.04.1 and Centos 4.6 How to reproduce: Take a (very simple) OpenLdap installation and put the overlay stuff before the suffix configuration: ------------------------------------------------------------- . . moduleload unique . . ####################################################################### # Specific Directives for database #1, of type hdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database hdb # The base of your directory in database #1 overlay unique unique_uri ldap:///"dc=my-domain,dc=com"?gidNumber?sub suffix "dc=my-domain,dc=com" . . ------------------------------------------------------- Then check the configuration: ldapmaster-dev:/etc/ldap#slaptest Segmentation fault ldapmaster-dev:/etc/ldap#slapd -d 4 Segmentation fault Putting the overlay stuff at the end of the database section or the suffix configuration before the overly stuff it works as expected. It also works without a base dn (unique_uri ldap:///?gidNumber?sub) regardless of the position.

1 0

(ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 04 Aug '08

04 Aug '08

Full_Name: Ali Pouya Version: 2.4.11 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I have a test directory with two mirrors A and B and a replica C connected to A. I usaually use server A for write operations. I encounter the following problems : 1) If the data base is initiated in stand alone (so serverID defaults to zero) and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on C it scans all of the objects writtent on A afterwards, producing the followin log for each object : ====================================================== entry_decode: "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" <= entry_decode(cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr) => bdb_dn2id("cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr") <= bdb_dn2id: got id=0x9 => test_filter GE => access_allowed: search access to "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" "entryCSN" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 ====================================================== For a directory with 10 million objects the this takes more than one hour (slapd is running but the service is not available). If I set serverID=3 on the replica C the problem disapears. 2) If I do only one write operation on B, then I get two contextCSN values, which is normal. But il this case slapd on B scans, at each startup, all objecs written on A after the write operation on B. The log and the effect are similar to those explained above. Should I consider this as a normal behaviour or a bug ? My mirror configuration is similar to the one recommended in Admin's Guide. Of course I can provide more detailed information if required. Thanks for your HELP Best Regards Ali

1 0

(ITS#5639) Digital (PGP-)signature for downloadable sources
by michael＠stroeder.com 03 Aug '08

03 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.112.78) Source files downloadable fomr http://www.openldap.org should be digitally signed. It's common practice to use PGP (GnuPG) for that.

1 0

Re: (ITS#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by hyc＠symas.com 01 Aug '08

01 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > After upgrading to 2.4.11 all our LDAP servers would abort when modifications > were made to them. Here are the last messages leading up to and including the > abort: This appears to be the same as ITS#5581. Please direct all further emails to that item instead. It looks like there's a problem in your slapo-unique configuration. > > => bdb_list_candidates 0xa0 > => bdb_filter_candidates > OR > => bdb_list_candidates 0xa1 > => bdb_filter_candidates > EQUALITY > => bdb_equality_candidates (objectClass) > => key_read > bdb_idl_fetch_key: [b49d1940] > <= bdb_index_read: failed (-30989) > <= bdb_equality_candidates: id=0, first=0, last=0 > <= bdb_filter_candidates: id=0 first=0 last=0 > => bdb_filter_candidates > <= bdb_filter_candidates: id=0 first=0 last=0 > <= bdb_list_candidates: id=0 first=0 last=0 > <= bdb_filter_candidates: id=0 first=0 last=0 > <= bdb_list_candidates: id=0 first=1 last=0 > <= bdb_filter_candidates: id=0 first=1 last=0 > bdb_search_candidates: id=0 first=1 last=0 > bdb_search: no candidates > send_ldap_result: conn=7 op=13 p=3 > send_ldap_result: err=0 matched="" text="" > => unique_search found 0 records > ==> unique_search > str2filter "(&(?=error)(|))" > put_filter: "(&(?=error)(|))" > put_filter: AND > put_filter_list "(?=error)(|)" > put_filter: "(?=error)" > put_filter: simple > put_simple_filter: "?=error" > => bdb_search > bdb_dn2entry("dc=fam") > => access_allowed: search access to "dc=fam" "entry" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > search_candidates: base="dc=fam" (0x00000001) scope=2 > Assertion failed: (f != NULL), function oc_filter, file search.c, line 970. > Abort trap: 6 -- -- 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#5635) slapi SLAPI_MODIFY_MODS mod->mod_op offset.
by hyc＠symas.com 01 Aug '08

01 Aug '08

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.10 > OS: Linux/F9 > URL: > Submission from: (NULL) (138.37.8.59) > > > In a slapi pre-modify function (SLAPI_PLUGIN_PRE_MODIFY_FN) you can get a null > terminated array of LDAPMod modifications. Like so: > > /* get list of mods */ > if (slapi_pblock_get(pb,SLAPI_MODIFY_MODS,&mods) || !mods) { > LOG("[%i] Error retrieving LDAPMods.\n",conn_id); > return (PLUGIN_STOP); > } > DEBUG("[%i] Got LDAPMods.",conn_id); > > > If you loop over these and extract the mod_op values which are held in > mod->mod_op, the values seem to be offset by 128. i.e. an add operation, which > should have a value of 0 (LDAP_MOD_ADD) has a value of 128. A delete operation, > should have 2 (LDAP_MOD_DELETE) it seems to be set to 130. > > The numbers differ only in the 8th bit. So I'm wondering if there is a strange > signed/unsigned int conversion thing going on somewhere. That's the LDAP_MOD_BVALUES flag. There's no bug here, this ITS will be closed. -- -- 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#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by stef＠memberwebs.com 01 Aug '08

01 Aug '08

Full_Name: Stef Version: 2.4.11 OS: FreeBSD 6.3-RELEASE-p2 URL: Submission from: (NULL) (38.99.5.20) After upgrading to 2.4.11 all our LDAP servers would abort when modifications were made to them. Here are the last messages leading up to and including the abort: => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=1 last=0 <= bdb_filter_candidates: id=0 first=1 last=0 bdb_search_candidates: id=0 first=1 last=0 bdb_search: no candidates send_ldap_result: conn=7 op=13 p=3 send_ldap_result: err=0 matched="" text="" => unique_search found 0 records ==> unique_search str2filter "(&(?=error)(|))" put_filter: "(&(?=error)(|))" put_filter: AND put_filter_list "(?=error)(|)" put_filter: "(?=error)" put_filter: simple put_simple_filter: "?=error" => bdb_search bdb_dn2entry("dc=fam") => access_allowed: search access to "dc=fam" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) search_candidates: base="dc=fam" (0x00000001) scope=2 Assertion failed: (f != NULL), function oc_filter, file search.c, line 970. Abort trap: 6

1 0

(ITS#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by kouk＠noc.uoa.gr 01 Aug '08

01 Aug '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080801.diff Submission from: (NULL) (195.134.100.30) There is a bug in the function 'slap_acl_mask' in servers/slapd/acl.c that affects the processing of dynacls. In particular the code attempts to apply ACL_ACCESS2PRIV to a variable already containing a slap_mask_t value. By chance this does not make a difference except when the dynacl rule is applied after a 'break' in a previous rule that has altered the default mask. It appears that the intention was to check whether the requested access level applies to the dynacl rule access mask. Instead the check is made against the current applied mask. The referenced patch fixes this issue by passing the requested access level as an extra parameter to the function and using it for the check.

1 0

(ITS#5636) performance improvement in ACI evaluation
by stef＠noc.uoa.gr 01 Aug '08

01 Aug '08

Full_Name: Stefanos Stamatis Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/stefanos-stamatis-080801.diff Submission from: (NULL) (195.134.100.30) The function 'aci_mask' in servers/slapd/aci.c will evaluate the type and subject part of an ACI even if the 'action;rights;attr;' part of the ACI does not apply. This is bad for performance, especially if the subject is a set which dereferences the objects 'user' or 'this'. The referenced patch solves this issue by fixing 'aci_list_get_rights' to return 0 if the returned mask does not effect a change.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2008