OpenLDAP ber_get_next() Bug Lets Remote Users Deny Service
SecurityTracker Alert ID: 1020405|
SecurityTracker URL: http://securitytracker.com/id/1020405
(Links to External Site)
Updated: Aug 14 2008|
Original Entry Date: Jul 1 2008
Denial of service via network|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
Version(s): 2.3.39 (stable)|
A vulnerability was reported in OpenLDAP. A remote user can cause denial of service conditions.|
A remote user can send specially crafted data to trigger a flaw in the decoding of ASN.1 BER network datagrams and cause the target service to crash.
A specially crafted BerElement size value can trigger this flaw.
The vulnerability resides in the ber_get_next() function in 'libraries/liblber/io.c'.
Cameron Hotchkies reported this vulnerability.
A remote user can cause the LDAP service to crash.|
The vendor has issued a fixed version (2.4.11).|
The vendor's advisory is available at:
Vendor URL: www.openldap.org/its/index.cgi/Software%20Bugs?id=5580 (Links to External Site)
|Underlying OS: Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: BER Decoding Remote DoS Vulnerability|
Full_Name: Cameron Hotchkies
OS: Gentoo Linux
Submission from: (NULL) (184.108.40.206)
This vulnerability allows remote attackers to deny services on vulnerable
installations of OpenLDAP. Authentication is not required to exploit this
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.
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 ?*/
> slapd -h ldap:// -d511 &
> xxd packet
0000000: ffff ff00 8441 4243 44 .....ABCD
> nc localhost 389 < packet