openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by amg1127＠cefetrs.tche.br 26 Jun '08

26 Jun '08

Full_Name: Anderson M. Gomes Version: 2.4.9 (but 2.4.10 has the bug) OS: Ubuntu 8.04.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.58.241.178) I submitted a bug report in Ubuntu's Launchpad. The address is: https://bugs.launchpad.net/ubuntu/+source/openldap2.3/+bug/243337 The bug refers to 2.4.9, but it is reproducible in OpenLDAP 2.4.10 (I could reproduce it, at least).

1 0

(ITS#5580) BER Decoding Remote DoS Vulnerability
by zdi-disclosures＠tippingpoint.com 26 Jun '08

26 Jun '08

Full_Name: Cameron Hotchkies Version: 2.3.41 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.179.208.36) This vulnerability allows remote attackers to deny services on vulnerable installations of OpenLDAP. Authentication is not required to exploit this vulnerability. The specific flaw exists in the decoding of ASN.1 BER network datagrams. When the size of a BerElement is specified incorrectly, the application will trigger an assert(), leading to abnormal program termination. Tech Details: The code exhibiting the problem is located in the function ber_get_next() function in "libraries/liblber/io.c" . The function fails to handle properly BER encoding of an element (tag + length + content) that contains: * exactly 4 bytes long "multi-byte tag" * exactly 4 bytes long "multi-byte size" The total size of the resulting encoding equals to the size of the BerElement structure buffer plus one byte. This causes the function returns indicating that more data are needed, but leaves the read-pointer pointing right at the end of the buffer, which is not permitted. Subsequent calls to the function result in an assertion failure: assert( 0 ); /* ber structure is messed up ?*/ Example Exploitation: > slapd -h ldap:// -d511 & ... > xxd packet 0000000: ffff ff00 8441 4243 44 .....ABCD > nc localhost 389 < packet

1 0

(ITS#5579) Interaction of ppolicy attributes
by andrew.findlay＠skills-1st.co.uk 26 Jun '08

26 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132) If an account becomes locked due to excessive failed authentications, its entry will contain the attributes pwdFailureTime and pwdAccountLockedTime. If the account is subsequently unlocked by setting a new password, all values of those attributes are automatically removed. However, if the password is left alone and the account is unlocked by removing pwdAccountLockedTime, values remain in pwdFailureTime. This means that a single authentication failure will immediately lock the account again. pwdFailureTime cannot be modified directly, so I think there is a case for clearing it when pwdAccountLockedTime is cleared explicitly. Andrew

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 26 Jun '08

26 Jun '08

I have uploaded a proposed fix for this: ftp://ftp.openldap.org/incoming/andrew-findlay-sortvals-20080626.patch My reasoning is that the break statement terminates the loop before the last value in the list has been compared with the assertion value. Thus, even if the last value matches, the loop ends with -1 in 'match'. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 26 Jun '08

26 Jun '08

On Wed, Jun 25, 2008 at 08:10:56PM +0000, Andrew Findlay wrote: > When 'sortvals members' is in effect, some attribute modify operations produce > bad results. This seems to occur when an operation adds an attribute that sorts > to the end of the list. Having thought about this some more I now think that the problem is to do with read/search rather than add. The last value in the list cannot be matched however it got there. The test data I uploaded with the ITS contains this group entry: dn: cn=tenK,ou=groups,o=test,dc=example,dc=org objectclass: groupOfNames cn: tenK member: uniqueIdentifier=a_000000,dc=example,dc=org member: uniqueIdentifier=a_000001,dc=example,dc=org member: uniqueIdentifier=a_004994,dc=example,dc=org member: uniqueIdentifier=a_004995,dc=example,dc=org member: uniqueIdentifier=a_004996,dc=example,dc=org member: uniqueIdentifier=a_004997,dc=example,dc=org member: uniqueIdentifier=a_004998,dc=example,dc=org member: uniqueIdentifier=a_004999,dc=example,dc=org member: uniqueIdentifier=a_005000,dc=example,dc=org If I do a search for any value except the last one, it succeeds: ./bound-search member=uniqueIdentifier=a_004999,dc=example,dc=org # tenK, groups, test, example.org dn: cn=tenK,ou=groups,o=test,dc=example,dc=org objectClass: groupOfNames cn: tenK member: uniqueIdentifier=a_000000,dc=example,dc=org member: uniqueIdentifier=a_000001,dc=example,dc=org member: uniqueIdentifier=a_004994,dc=example,dc=org member: uniqueIdentifier=a_004995,dc=example,dc=org member: uniqueIdentifier=a_004996,dc=example,dc=org member: uniqueIdentifier=a_004997,dc=example,dc=org member: uniqueIdentifier=a_004998,dc=example,dc=org member: uniqueIdentifier=a_004999,dc=example,dc=org member: uniqueIdentifier=a_005000,dc=example,dc=org # search result search: 2 result: 0 Success ./bound-search member=uniqueIdentifier=a_005000,dc=example,dc=org ... this does not find anything This explains why the add and modify operations failed in such an odd way. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 25 Jun '08

25 Jun '08

Hi, On Tue, Jun 24, 2008 at 3:37 PM, <unix.gurus(a)gmail.com> wrote: > On Tue, Jun 24, 2008 at 12:50 PM, <unix.gurus(a)gmail.com> wrote: >> Hi, >> >> I have uploaded a patch against HEAD that normalizes the attributes >> used under cn=monitor according to the schema: >> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch > > Unified diff of the same thing: > sean-burford-monitor-normalize-unified-080624.patch > > The search (namingContexts:distinguishedNameMatch:=CN=...) returns the > expected results, I'll check what filterentry.c:test_mra_filter() is > up to later. As far as I can tell the arguments passed to filterentry.c:test_mra_filter() for that search also look sane, so whilst it passes my tests I'm looking forward to an official opinion on this patch. > make test also completes successfully, for what it's worth. -- Thanks, Sean Burford

1 0

(ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 25 Jun '08

25 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz Submission from: (NULL) (88.97.25.132) When 'sortvals members' is in effect, some attribute modify operations produce bad results. This seems to occur when an operation adds an attribute that sorts to the end of the list. The attached tarball contains a cut-down config and dataset, along with a set of scripts and LDIF files that demonstrate the bug. To create the problem: (This does NOT need to run as root) edit vars to set appropriate PATH # First version of problem - single LDAP op removes one member and adds another: rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif ./update-dsa mess-tenk.ldif ./update-dsa unmess-tenk.ldif The first update is OK, but the second fails thus: modifying entry "cn=tenK,ou=groups,o=test,dc=example,dc=org" ldap_modify: No such attribute (16) additional info: modify/delete: member: no such value If 'sortvals member' is not set in slapd.conf.test you can just alternate those two LDIFs forever. Check data with: ./bound-search cn=tenk Now compare with the same process using change-tenk.ldif and change-tenk-back.ldif - they do the same job but with a value that sorts earlier, and they work OK. # Second version - repeat adding of single value: ./stop-slapd rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif ./update-dsa add-member.ldif ./update-dsa add-member.ldif ./update-dsa add-member.ldif First update OK. Second update OK but should not be. Third fails is it should. Check data with: ./bound-search cn=tenk

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 25 Jun '08

25 Jun '08

Michael Ströder wrote: > Kurt Zeilenga wrote: >> >> On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: >>> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of >>> URIs a >>> proxy is serving; can be modified run-time' SUP managedInfo ) >> >> THe fact that this element is published with a .666 OID is a bug. >> .666 are intended for experiments and should never be published. > > Sorry, could have been in my build because of -DDEVEL. Built without -DDEVEL and this schema element is still there but not 'managedInfo'. > P.S.: Frankly I see no problem with publishing a .666 OID. Personally I'd prefer to see interims schema elements in the subschema subentry over seeing no schema declaration for existing attributes. Ciao, Michael.

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by ando＠sys-net.it 25 Jun '08

25 Jun '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> I suspect something like: if back-monitor and/or back-ldap are built as >>> modules, and loaded in the wrong order (back-ldap first, back_monitor >>> then), 'olmDbURIList' is likely to be registered __before__ >>> 'managedInfo'. >> So, a manpage fix something like this? >> >> If monitor is a dynamically loaded module, it should be "moduleload"ed >> before any modules it wants to monitor. A dynamically loaded monitor >> may be unable to monitor a statically built module. > > Not necessary. The order of moduleloads is irrelevant. > > back-monitor initializes its schema as soon as the module is loaded. All of > the other backends initialize their monitor schema when a backend is first > instantiated. The problem you're talking about here doesn't exist. well, all modules do. So if a module needs to register schema dependent on another module that's not loaded yet, it should either fail or, if that piece of schema is to be considered optional, just complain it couldn't do all the job. So it seems pertinent: if you load modules in the "wrong" order, you could miss monitoring functionalities. I note that back-bdb actually tries to register the schema all times a database is instantiated, unless already done. In any case, if the back_monitor module is loaded __after__ the server is already running, existing databases will not gain monitoring capabilities; only subsequent ones will. I don't consider this necessarily a bug (it could be worked out by explicitly setting "monitoring" to "on" after loading the back_monitor module, provided some backend-specific hook is invoked). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 24 Jun '08

24 Jun '08

Kurt Zeilenga wrote: > > On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of >> URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > THe fact that this element is published with a .666 OID is a bug. .666 > are intended for experiments and should never be published. Sorry, could have been in my build because of -DDEVEL. Nevertheless I'd appreciate if the schema elements of back-monitor are published in subschema subentry. Ciao, Michael. P.S.: Frankly I see no problem with publishing a .666 OID.

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