Oulun yliopisto - Etusivulle University of Oulu in English

ee.oulu.fi

Electrical and Information Engineering

University of Oulu > Faculty of Technology > Electrical and Information Engineering


OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c06-ldapv3

$RCSfile: index.html,v $ $Revision: 1.152 $ $Date: 2001/12/03 21:39:23 $
Permission is hereby granted for quoting, reprinting and redistributing
this document, provided that a link to this document is given, and all
changes made are clearly separated from the original text.

ABSTRACT

LDAP is a lightweight directory access protocol originally designed to provide access to X.500 directories. LDAP has been adopted in the network infrastructure for directory services, authentication and as a PKI building component. The robustness of LDAP enabled servers was evaluated by feeding them with exceptionally formatted BER encodings and LDAP search requests. Robustness problems of servers were evaluated for their security implications. A survey of the related standards was made, existing implementations were identified and targets were chosen. Test-material was prepared and tests were carried out. Results were gathered and reported. Many of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. To promote and support hardening LDAP server implementations this test-material should be adopted in the evaluation and development of these products.

Table of Contents

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document.

This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol. The subject protocol and the chosen subset of it are illustrated in the "Analysis" section below.

Analysis

"LDAP is a specification for a client-server protocol to retrieve and manage directory information. It was originally intended as a means for clients on PCs to access X.500 directories, but can also be used with any other directory system that follows the X.500 data models." [http://www.innosoft.com/ldapworld/]

The purpose of this study was to evaluate implementation level security of LDAP (Lightweight Directory Access Protocol) implementations. The factors behind choosing LDAP included:

  • LDAP is used, or at least planned to be used, in accessing and storing security critical information, such as PKI certificates, user authentication data and IT management information.
  • LDAP, with its newest version 3, is making its way towards becoming a widely deployed protocol. Increased attention to the security of LDAP implementations in early stage may lessen the future agony.

In this test-suite, the focus was set on the certain protocol data units (PDUs) sent from the client to the server, and the protocol version was chosen to be the newest LDAPv3. Namely these PDUs included exceptional BER (Basic Encoding Rules) encodings and LDAP search request PDUs. Rationale behind the selection:

  • Testing servers was estimated to be easier than targeting the clients. This is due to servers being, by design, ready to accept incoming LDAP messages without prior session setup.
  • A LDAP server may be critical for the network infrastructure. Even an denial-of-service attack against a LDAP server may have serious implications.
  • Robustness problems in decoding exceptional BER encoding may lead to situation where application level authentication based access control is ineffective since errors reside in code that will be involved in parsing the authentication packets as well.
  • LDAP search PDU provides interesting complexity for the test design.

Design

Standard Survey

The available standards specifying the selected protocol have to be studied, and analysed. The relevant protocol specifications are listed in the table below.

Only the core LDAPv3 specifications are listed. Various vendor specific extensions are left out at this point but are available from [http://www.innosoft.com/ldapworld/ldapext.html].

Survey of related standards and protocol specifications
Name Document Date Organization Status Link Description
RFC2251 19971201 IETF Closed (link) Lightweight Directory Access Protocol (v3)
RFC2252 19971201 IETF Closed (link) LDAPv3 Attribute Syntax Definitions
RFC2253 19971201 IETF Closed (link) UTF-8 String Representation of Distinguished Names
RFC2254 19971201 IETF Closed (link) The String Representation of LDAP Search Filters
RFC2255 19971201 IETF Closed (link) The LDAP URL Format
RFC2256 19971201 IETF Closed (link) A Summary of the X.500(96) User Schema for use with LDAPv3
RFC2279 19980101 IETF Closed (link) UTF-8, a transformation format of ISO 10646

LDAP includes a subset of the X.500 functionality. Therefore understanding over X.500 is useful while designing test-cases for LDAP implementations. More information on X.500 directory service and other X.series standards is available from ITU-T [http://www.itu.int/itudoc/itu-t/rec/x/x500up/] for a price. However some old X.series documents are available from different sources for free [http://www.nexor.com/info/directory.htm].

"ASN.1 Complete", by Professor John Larmouth, provides additional information about ASN.1 and BER.

Subject Survey

A survey of the available implementations is conducted. This should include a diverse selection of implementations in order to gain a better insight into the applications implementing the protocol, and to give a hint of the impact of the potential vulnerabilities. Typically, not all implementations are available for testing, and thus cannot be tested by the project personnel within this test-suite prerelease phase.

Survey of the LDAP implementations
Subject name License Platform Link to source
AE SLAPD commercial hp/ux, solaris, win32 (link)
CA eTrust Directory commercial solaris, win32 (link)
ClickMail Central Directory commercial mac (link)
CommuniGate Pro commercial several (link)
DC-Directory commercial hp/ux, linux, solaris, win32 (link)
Eudora WorldMail Server commercial win32 (link)
IBM SecureWay Directory commercial aix, os/400, os/390, solaris, win32 (link)
InJoin Directory Server commercial aix, hp/ux, irix, solaris, win32 (link)
iPlanet directory server commercial aix, hp-ux, linux, solaris, tru64, win32 (link)
Lotus Domino R5 Server commercial aix, as/400, hp/ux, linux, os/2, solaris, s/390, win32 (link)
Microsoft Active Directory commercial win32 (link)
Microsoft Exchange Server commercial win32 (link)
Missive commercial aix, solaris (link)
M-Vault directory commercial aix, irix, linux, solaris, win32 (link)
NEXOR Directory commercial unknown (link)
Novell NDS eDirectory commercial linux, netware, solaris, tru64, win32 (link)
OpenLDAP public several (link)
Oracle Internet Directory commercial several (link)
PGP Keyserver commercial solaris, win32 (link)
Siemens DirX Meta Directory commercial aix, hp/ux, linux, solaris, win32 (link)
Syntegra Global Directory commercial unknown (link)
Teamware Office commercial solaris, win32 (link)
University of Michigan SLAPD historical several (link)

Some good pointers to other vendors offering LDAP products may be found from the [LDAPzone] and Clayton Donley LDAP Resources [http://www.linc-dev.com/ldapres.html].

A subset of the implementations was chosen to be tested during the test-suite creation and prerelease phases.

Injection Vector Survey

The injection vector survey, or delivery vector survey, analyses the different methods of delivering the test-cases to the implementations under test (IUTs). Often, there are several methods of injection and one test-suite cannot cover them all, or might miss some vectors not available in all implementations.

injection-vector-survey
Application protocol Transport protocol Packet
LDAP PDU TCP+IP LDAP bind, add, delete, search PDU(s)
LDAP PDU UDP+IP Connectionless LDAP

Core specification(s) of LDAP Protocol specify that TCP is the typical way to transfer LDAP PDUs from client to server and vice versa. RFC1798 specifies means of transferring LDAP over unreliable transport, namely UDP. It seems however that few current implementations offer the possibility of using UDP transport. Therefore, TCP is a logical choice. This selected delivery vector should provide successful injection of test-cases to all chosen implementations.

Specifications Design

Protocol data unit specifications are used as a basis for generating the test-cases. Starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool developed in this project uses a custom dialect of BNF (Backus-Naur Form). The BNF is capable of describing context-free syntax of a specification, but is not usually enough for the PDU generation. The specification is completed by semantic rules which semantically extend the BNF and communication rules which provide communication channels with external components. Rules are implemented in Java.

In this test-suite, a BNF presentation of LDAP PDUs was needed. LDAP specification uses mainly ASN.1 notation, but also some BNF in the inner structures. Relevant ASN.1 specifications are manually converted into BNF. This should be straightforward since the specification mentions that typically BER (Basic Encoding Rules) are used for PDU encoding and decoding.

Design of Exceptional Elements

An exceptional element is a piece of data designed to provoke undesired behaviour of the subject implementation. A single test-case contains one or few exceptional elements. An exceptional element can be illegal according protocol specification, but often it is legal or in the hazy region between legal and illegal constructs. In a nutshell, an exceptional element is an input that might not have been considered properly when implementing the software.

The LDAP PDU specification and especially the attribute syntax definition appear to be quite complex. This probably forces the server developers to a rigorous use of BER encoding/decoding tools, which gives little hope of finding vulnerabilities in the decoding parts. On the other hand, if someone has done BER fiddling manually, tests will tear the particular implementation to pieces. One set of test-cases will concentrate on exceptional ASN.1/BER encodings to test the robustness of the used decoder.

The application logic of a LDAP server receives data objects from BER decoder, acts according the requests, and sends the reply back to client though BER encoder. One might suppose that the use of ASN.1/BER protects the application logic from misformatted input. However, any exceptional input which is correctly encoded will pass to the application logic. An another set of test-cases will use legal encodings to test the robustness of the application logic.

Test-cases are tuned to use root distinguished name as a LDAP baseobject (baseObject = ""). This ensures that filters are evaluated to maximum extend possible without configuring the server in any way. This also saves anyone from the task of configuring the server specifically for this test-suite, since root DN should always be present what ever the LDAP server configuration might be.

The following table lists used exception categories used to test both BER encoding and application logic. The leading letter in the category name is interpreted as follows:

  • E: BER Encoding exceptions
  • F: Format string and UTF-8 encoding exceptions
  • O: Overflow exceptions
  • I: Integer value exceptions
  • X: Binary mode on/off flag exceptions

For more information on UTF-8 encoding problems, see Markus Kuhn's analysis [http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt].

Exception categories
Name Description
E0 Invalid encodings for L field of BER encoding.
E1 All possible values for T fields class part
E2 All possible values for T fields number part using five bits and some overlong number encodings.
E3 Invalid encodings for BER NULL type.
E4 Invalid encodings for BER BOOLEAN type.
E5 Invalid encodings for BER INTEGER type.
E6 Invalid encodings for BER OCTETSTRING type.
E7 Invalid encodings for BER BITSTRING type.
E8 Invalid encodings for BER SEQUENCE-OF type.
E9 Invalid encodings for BER SET-OF type.
E10 Invalid encodings for BER OBJECT-IDENTIFIER type.
E11 Multiple distinguished names instead of one.
E12 All possible filter type encodings and some undefined filter types.
E13 Total garbage with semi correct encodings.
E14 One or more fields from search PDU are totally missing.
F0 Exceptional elements applied to LDAP baseObject containing printf like format strings (ie. %.9999d).
F1 Exceptional elements applied to LDAP search requests search filters attribute description field containing printf like format strings (ie. %.9999d).
F2 Broken UTF-8 encodings. Adopted mostly from UTF-8 testset by Markus Kuhn
F3 Exceptional elements containing printf like format strings (ie. %.9999d). These are general format strings with no specific internal structure.
O0 General overflow strings. Long strings of a letter 'a' (hex 0x61), space, escape mark '\', quotation mark ("),
O1 LDAP object identified (oid) anomalies, with very long integers and other boundary values as oids. Also some broken oid presentations are included.
O2 LDAP baseObject overflows. This single exception element holds all overflow type anomalies applied to baseObject. It overflows both sides of equals mark. Generated overflowing equals, greater than, less than, plus, minus, comma, slash etc. characters specified in RFC2253 and tries multiple base objects separated by comma.
O3 Attribute description's option overflow. Long strings and huge number of options are applied as ldap search request filters attribute descriptions.
O4 Huge number of continuous initial substrings offered to substrings filter. Includes some basic format strings
O5 Huge number of continuous any substrings offered to substrings filter. Includes some basic format strings
O6 Huge number of continuous final substrings offered to substrings filter. Includes some basic format strings
O7 Huge number of continuous attributes offered to attribute field. Includes some basic format strings
O8 Nearly total garbage applied to attribute descriptions option field. Contains unsupported characters, etc.
I0 huge and very small integer values to test unsigned/signed handling of ldap server in fields timeLimit etc.
X0 sets attribute descriptions binary option on/off.

The tests are divided into two sets of test-cases "Encoding Exceptions" and "Application Exceptions".

Encoding Exceptions

In "Encoding Exceptions" exceptional ASN.1/BER elements are exercised. The purpose is to test the robustness of the BER decoder of tested LDAP server. The table below lists the test-groups in the encoding test-set:

Encoding exceptional-element details
Name Category First index # Test-cases
zero_case - 0 1
ldap-request-length-of-length E0 1 504
ber-t-class-combinations-global E1 505 968
ber-t-number-combinations-global E2 1473 378
ber-tlv-NULL-global E3 1851 288
ber-tlv-BOOLEAN-global E4 2139 336
ber-tlv-INTEGER-global E5 2475 348
ber-tlv-OCTETSTRING-global E6 2823 288
ber-tlv-BITSTRING-global E7 3111 264
ber-tlv-SEQUENCE-OF-global E8 3375 312
ber-tlv-SET-OF-global E9 3687 300
ber-tlv-OBJECT-IDENTIFIER-global E10 3987 216
ber-multipleDN E11 4203 7
ber-filtertype E12 4210 15
ber-missingfield E14 4225 11
ber-tlv-garbage-collection E13 4236 1728

Legend:

  • Category column describes what kind of exceptional elements are integrated in the test-group.
  • "First index #" and "Test-cases" columns describe how many test-cases belong to the test-group, describing the first test-case number, and the number of cases from thereon.

Application Exceptions

In "Application Exceptions" correctly formatted ASN.1/BER elements contain exceptional data objects. The purpose is to test the robustness of the LDAP server application logic. The table below lists the test-groups in the application test-set:

Application exceptional-element details
Name Category First index # Test-cases
zero_case n/a 0 1
zero-case-feqm n/a 1 1
zero-case-fgoe n/a 2 1
zero-case-floe n/a 3 1
zero-case-fam n/a 4 1
zero-case-fsubstrings n/a 5 1
zero-case-attributes n/a 6 1
sreq-basedn-overflow O2 7 302
sreq-basedn-fmtstring F0 309 50
sreq-basedn-general-utf8 F2 359 52
sreq-fpresent-attribdesc-overflow O1 411 152
sreq-fpresent-attribdesc-dotteddecimal-overflow O2 563 158
sreq-fpresent-attribdesc-fmtstring ? 721 27
sreq-fpresent-attribdesc-general-utf8 F2 748 52
sreq-fpresent-attribdesc-option-overflow O3 800 110
sreq-fpresent-attribdesc-option-fmtstring F1 910 27
sreq-fpresent-attribdesc-option-garbage O8 937 27
sreq-feqm-attribdesc-overflow O0 964 152
sreq-feqm-attribdesc-dotteddecimal-overflow O1 1116 158
sreq-feqm-attribdesc-fmtstring F4 1274 27
sreq-feqm-attribdesc-option-overflow O3 1301 110
sreq-feqm-attribdesc-option-fmtstring F1 1411 27
sreq-feqm-attribdesc-option-garbage O8 1438 27
sreq-feqm-attribvalue-overflow X0,O0 1465 304
sreq-feqm-attribvalue-fmtstring X0,F4 1769 54
sreq-fgoe-attribdesc-overflow O0 1823 152
sreq-fgoe-attribdesc-dotteddecimal-overflow O1 1975 158
sreq-fgoe-attribdesc-fmtstring F4 2133 27
sreq-fgoe-attribdesc-option-overflow O3 2160 110
sreq-fgoe-attribdesc-option-fmtstring F1 2270 27
sreq-fgoe-attribdesc-option-garbage O8 2297 27
sreq-fgoe-attribvalue-overflow X0,O0 2324 304
sreq-fgoe-attribvalue-fmtstring X0,F4 2628 54
sreq-fgoe-attribvalue-utf8 X0,F2 2682 104
sreq-floe-attribdesc-overflow O0 2786 152
sreq-floe-attribdesc-dotteddecimal-overflow O1 2938 158
sreq-floe-attribdesc-fmtstring F4 3096 27
sreq-floe-attribdesc-option-overflow O4 3123 110
sreq-floe-attribdesc-option-fmtstring F1 3233 27
sreq-floe-attribdesc-option-garbage O8 3260 27
sreq-floe-attribvalue-overflow X0,O0 3287 304
sreq-floe-attribvalue-fmtstring X0,F4 3591 54
sreq-fam-attribdesc-overflow O0 3645 152
sreq-fam-attribdesc-dotteddecimal-overflow O1 3797 158
sreq-fam-attribdesc-fmtstring F4 3955 27
sreq-fam-attribdesc-option-overflow O3 3982 110
sreq-fam-attribdesc-option-fmtstring F1 4092 27
sreq-fam-attribdesc-option-garbage O8 4119 27
sreq-fam-attribvalue-overflow X0,O0 4146 304
sreq-fam-attribvalue-fmtstring X0,F4 4450 54
sreq-fsubstrings-attribdesc-overflow O0 4504 152
sreq-fsubstrings-attribdesc-dotteddecimal-overflow O1 4656 158
sreq-fsubstrings-attribdesc-fmtstring F4 4814 27
sreq-fsubstrings-attribdesc-option-overflow O3 4841 110
sreq-fsubstrings-attribdesc-option-fmtstring F1 4951 27
sreq-fsubstrings-attribdesc-option-garbage O8 4978 27
sreq-fsubstrings-option-initial-overflow O0 5005 152
sreq-fsubstrings-option-initial-fmtstring F4 5157 27
sreq-fsubstrings-option-any-overflow O0 5184 152
sreq-fsubstrings-option-any-fmtstring F4 5336 27
sreq-fsubstrings-option-final-overflow O0 5363 152
sreq-fsubstrings-option-final-fmtstring F4 5515 27
sreq-fsubstrings-multiple-substrings-initial O4 5542 24
sreq-fsubstrings-multiple-substrings-any O5 5566 24
sreq-fsubstrings-multiple-substrings-final O6 5590 24
sreq-attributes-overflow O0 5614 152
sreq-attributes-dotteddecimal-overflow O1 5766 158
sreq-attributes-fmtstring F4 5924 27
sreq-attributes-option-overflow O3 5951 110
sreq-attributes-option-fmtstring F1 6061 27
sreq-attributes-option-garbage O8 6088 27
sreq-attributes-multiple O7 6115 24
sreq-messageID-integer I1 6139 110
sreq-scope-integer I1 6249 110
sreq-derefAliases-integer I1 6359 110
sreq-timelimit-integer I1 6469 110
sreq-sizelimit-integer I1 6579 110

Legend:

  • Category column describes what kind of exceptional elements are integrated in the test-group.
  • "First index #" and "Test-cases" columns describe how many test-cases belong to the test-group, describing the first test-case number, and the number of cases from thereon.

It should be noted that the application test-group sreq-messageID-integer is infected by a test design flaw. This flaw renders the BER length of the field to always contain value one (1), whatever the size of the actual content might be. Thus, it should be considered as an encoding test-group.

Injection

The test-tool provides communication rules for test-case injection. The initial testing revealed that the default TCP communication rule was insufficient for injection of test-cases into LDAP servers. Two improvements were required:

  • A LDAP server takes time to recover after a test-case causing crash or hang. Without any instrumentation capable to noticing this, many subsequent test-cases are lost due to connection failures. As a temporary solution (for this test-suite) the communication code should retry connecting to the LDAP server until it becomes active and testing can proceed.
  • Some LDAP servers blocked writing of longish test-cases forever causing the testing to block. The standard timeout mechanism could not interrupt the blocked Java socket writing situation. The communication rule was modified to break infinite writes using more efficient timeout technique.

Semantic Rules

The test-tool provides semantic rules as method for augmenting the (already extended) BNF specification.

LDAP requires use of the basic encoding rules (BER) for formatting octets send over the TCP/IP connection. BER is a simple encoding method and can be modeled using BNF excluding length fields. Semantic rule BNFLength was programmed using Java to calculate correct values for the lenght fields.

Instrumentation

With instrumentation on the target platform we are able to monitor for undesired behavior of the subject implementation. Typically this manifests as exceptions or signals such 'access violation' and 'segmentation fault'.

No instrumentation will be bundled with this test-suite release. Observing any undesired behavior relies solely on the tools and logging provided by the target platform. Unfortunately the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves.

Implementation

Test-runs were conducted against the chosen subject implementations. Packet specifications, desired anomalies, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Results from the Test-Runs

Results from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against chosen subject software. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into subgroups based on the exception element types utilised and PDU fields under examination.

Exception groups are marked failed if any single case or combination of cases in exception category consistently either:

  • Clearly crashed the server or a server process.
  • Closed the port 389 denying further service requests.
  • Killed other existing connections.
  • Caused server to start trashing, i.e. consume most CPU or memory resources.

When the server did behave in suspicious manner, but no single test-case reliably producing the situation could be identified, the group is marked inconclusive.

Encoding exception element results
Name tr-001 tr-002 tr-003 tr-004 tr-005 tr-006 tr-007 tr-008
zero_items - - - - - - - -
ldap-request-length-of-length X I - - - X - X
ber-t-class-combinations-global - - - - - - - X
ber-t-number-combinations-global - - - - - X - X
ber-tlv-NULL-global - - - - - X - X
ber-tlv-BOOLEAN-global - - - - - X - X
ber-tlv-INTEGER-global - - - - - X - X
ber-tlv-OCTETSTRING-global - - - - - X - X
ber-tlv-BITSTRING-global - - - - - X - X
ber-tlv-SEQUENCE-OF-global - - - - - - - X
ber-tlv-SET-OF-global - - - - - X - X
ber-tlv-OBJECT-IDENTIFIER-global - - - - X X - X
ber-multipleDN - - - - - - - -
ber-filtertype - - - - - - - -
ber-missingfield - - - - - - - -
ber-tlv-garbage-collection - - - X - - - X
Application exception element results
Name tr-001 tr-002 tr-003 tr-004 tr-005 tr-006 tr-007 tr-008
zero_items - - - - - - - -
zero-case-feqm - - - - - - - -
zero-case-fgoe - - - - - - - -
zero-case-floe - - - - - - - -
zero-case-fam - - - - - - - -
zero-case-fsubstrings - - - - - - - -
zero-case-attributes - - - - - - - -
sreq-basedn-overflow - - - X X X - -
sreq-basedn-fmtstring - - - X X - - -
sreq-basedn-general-utf8 - - - - - - - -
sreq-fpresent-attribdesc-overflow - - - X X - - -
sreq-fpresent-attribdesc-dotteddecimal-overflow - - - X X - - -
sreq-fpresent-attribdesc-fmtstring - - - X X - - -
sreq-fpresent-attribdesc-general-utf8 - - - - - - - -
sreq-fpresent-attribdesc-option-overflow - - - - X - - -
sreq-fpresent-attribdesc-option-fmtstring - - - - - - - -
sreq-fpresent-attribdesc-option-garbage - - - - X - - -
sreq-feqm-attribdesc-overflow - - - X X - - -
sreq-feqm-attribdesc-dotteddecimal-overflow - - - X X - - -
sreq-feqm-attribdesc-fmtstring - - - - X - - -
sreq-feqm-attribdesc-option-overflow - I - - X - - -
sreq-feqm-attribdesc-option-fmtstring - - - - - - - -
sreq-feqm-attribdesc-option-garbage - - - - X - - -
sreq-feqm-attribvalue-overflow - X - - X X - -
sreq-feqm-attribvalue-fmtstring - I - X - - - -
sreq-fgoe-attribdesc-overflow - - - - X - - -
sreq-fgoe-attribdesc-dotteddecimal-overflow - - - X X - - -
sreq-fgoe-attribdesc-fmtstring - - - X X - - -
sreq-fgoe-attribdesc-option-overflow - - - - X X - -
sreq-fgoe-attribdesc-option-fmtstring - - - - - - - -
sreq-fgoe-attribdesc-option-garbage - - - - X - - -
sreq-fgoe-attribvalue-overflow - - - X X X - -
sreq-fgoe-attribvalue-fmtstring - - - - - ? - -
sreq-fgoe-attribvalue-utf8 - - - - - ? - -
sreq-floe-attribdesc-overflow - - - - X ? - -
sreq-floe-attribdesc-dotteddecimal-overflow - - - - X ? - -
sreq-floe-attribdesc-fmtstring - - - X X ? - -
sreq-floe-attribdesc-option-overflow - - - - X ? - -
sreq-floe-attribdesc-option-fmtstring - - - - - ? - -
sreq-floe-attribdesc-option-garbage - - - - X ? - -
sreq-floe-attribvalue-overflow - - - X X ? - -
sreq-floe-attribvalue-fmtstring - - - - - ? - -
sreq-fam-attribdesc-overflow - - - X X ? - -
sreq-fam-attribdesc-dotteddecimal-overflow - - - X X ? - -
sreq-fam-attribdesc-fmtstring - - - X X ? - -
sreq-fam-attribdesc-option-overflow - - - - X ? - -
sreq-fam-attribdesc-option-fmtstring - - - - - ? - -
sreq-fam-attribdesc-option-garbage - - - - X ? - -
sreq-fam-attribvalue-overflow - - - X - ? - -
sreq-fam-attribvalue-fmtstring - - - - - ? - -
sreq-fsubstrings-attribdesc-overflow - - - X X ? - -
sreq-fsubstrings-attribdesc-dotteddecimal-overflow - - - X X ? - -
sreq-fsubstrings-attribdesc-fmtstring - - - X X ? - -
sreq-fsubstrings-attribdesc-option-overflow - - - - X ? - -
sreq-fsubstrings-attribdesc-option-fmtstring - - - - - ? - -
sreq-fsubstrings-attribdesc-option-garbage - - - - X ? - -
sreq-fsubstrings-option-initial-overflow - X - - X ? - -
sreq-fsubstrings-option-initial-fmtstring - I - - X ? - -
sreq-fsubstrings-option-any-overflow - X - - X ? - -
sreq-fsubstrings-option-any-fmtstring - I - - X ? - -
sreq-fsubstrings-option-final-overflow - X - - X ? - -
sreq-fsubstrings-option-final-fmtstring - I - - X ? - -
sreq-fsubstrings-multiple-substrings-initial - - - - - ? - -
sreq-fsubstrings-multiple-substrings-any - - - - - ? - -
sreq-fsubstrings-multiple-substrings-final - - - - - ? - -
sreq-attributes-overflow - - - X X ? - -
sreq-attributes-dotteddecimal-overflow - - - X X ? - -
sreq-attributes-fmtstring - - - X X ? - -
sreq-attributes-option-overflow - - - - X ? - -
sreq-attributes-option-fmtstring - - - - - ? - -
sreq-attributes-option-garbage - - - - - ? - -
sreq-attributes-multiple - - - - X ? - -
sreq-messageID-integer - - - - - ? - X
sreq-scope-integer - - - - - ? - -
sreq-derefAliases-integer - - - - - ? - -
sreq-timelimit-integer - - - - - ? - -
sreq-sizelimit-integer - - - - - ? - -

Legend:

  • tr-nnn: Each different test-run (tr-nnn) represents a different tested implementation.
  • X: Verdict is failed - Suspicious behavior, single test-case identified.
  • I: Verdict is inconclusive - Suspicious behavior, no single test-case identified.
  • -: Verdict is pass - No suspicious behavior observed.
  • ?: Verdict not collected - test-runs not completed.

The results are further summarised in the tables below.

Encoding results summary
Test-run # Total test-cases Failed test-cases Total groups Failed groups
tr-001 5964 n 16 1
tr-002 5964 n 16 n
tr-003 5964 0 16 0
tr-004 5964 5 16 1
tr-005 5964 n 16 1
tr-006 5964 79 16 9
tr-007 5964 0 16 0
tr-008 5964 n 16 12
Application results summary
Test-run # Total test-cases Failed test-cases Total groups Failed groups
tr-001 6685 0 77 0
tr-002 6685 15 77 n
tr-003 6685 0 77 0
tr-004 6685 n 77 23
tr-005 6685 n 77 46
tr-006 2628 n 32 4
tr-007 6685 0 77 0
tr-008 6685 9 77 1

Legend:

  • n: We were unable to determine the exact number of failures. See the more detailed tables above.
  • tr-006: Application test-run for this subject were not completed, thus only partial results are presented.

Each failed test-case represents a minimum a denial of service type chance of exploiting the vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error condition. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.

Verification via Exploits

To support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intended for demonstration purposes and is harmless as it is. The simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the software.

To support the vulnerability reports to the respective vendors, following exploits were developed:

  • Buffer overflow exploits allowing execution of arbitrary code were demonstrated against four LDAP server products.
  • Denial of service was demonstrated for the two remaining LDAP server products identified as vulnerable.

Test-Material Package

Package Information

Test-material is distributed as two JAR-packages, one for encoding exceptions and one for application exceptions. A package comprises of the following elements:

  • Test-cases (PDUs), located in testcases/ directory
  • Java code (source and compiled) for feeding the test-cases against the system under test.
  • LICENSE.TXT - GNU General Public License (GPL) version 2.
  • README.TXT - Very short instructions.

Licence and Copyright

The test-material is licensed under GNU General Public License (GPL) version 2, at no charge. This is done in order to ensure that vendors and their customers may freely utilise the test-material. Standard GPL terms for no warranty and no liability apply.

We recommend some additional guidelines, although these do not restrict the test-material licence. These guidelines can be found from the "Test-suite releases in Theory and Practice" document.

Usage

A prerequisite for using the test-material is a properly configured and started LDAP version 3 server.

The test-material can be used either with the bundled injection code [Using with Java] or with an external injector [Using without Java].

Using with Java

Java Runtime is a prerequisite for running the bundled Java code. [http://java.sun.com] This package has been tested on Java 2 Platform, Standard Edition (J2SE). [http://java.sun.com/j2se/1.3/].

Usage examples for the injection code bundled in the JAR-package:

java -jar c06-ldapv3-app-r1.jar -help
This command displays the built-in help for the available command line options. Options such as selecting a specific range of test-cases or non-standard destination port are high-lighted therein.
java -jar c06-ldapv3-app-r1.jar -host hostname -single <index>
Run the application test-case (index) into LDAP server hostname port 389.
java -jar c06-ldapv3-app-r1.jar -host hostname
Run all application test-cases into LDAP server hostname port 389.

Using without Java

The test-cases (PDUs) are in raw binary format and can be used by any suitable delivery software, such as nc (netcat). The individual test-cases can be extracted from the JAR-package with tools such as unzip, winzip or jar. Refer to the manual pages and product documentation of the respective tools for additional information.

Download

Notes

For better application level test-coverage, the LDAP server should accept search requests without preceding bind. However, any flaws discovered through the encoding test-material are likely to be exposed even if authentication via bind is required.

Conclusions

The initial results from the c06-ldapv3 tests indicate that implementations errors plague several LDAP server products. Some of the tested servers to failed in many, if not most, exception categories. This is alarming since LDAP servers are potential building blocks of critical infrastructure.

A subset of the LDAP protocol features was covered. Test-material should be extended to include for example other LDAP PDU types, such as bind, modify, insert and add.

Acknowledgments

We wish to express our gratitude to individual vendors who worked with us to protect their customers. Last, but not least, we are grateful to CERT/CC and AusCERT for their patient help, advice and active role during the vulnerability process.

Vulnerability Management

Prior Public Vulnerabilities

The most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities.

No directly related prior public vulnerabilities were found.

The Vulnerability Process

During the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by the CERT/CC in role of an independent coordinator and advisor. An attempt was made to seek a channel to distribute the test-material to vendors whose products we were not able to obtain for testing. A grace period of over 45 days was kept between the vendor notification and public release.

Advisories and Vendor Statements

Vendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:

  • [CERT/CC 2001-07-16] CERT® Advisory CA-2001-18 Multiple Vulnerabilities in Several Implementations of the Lightweight Directory Access Protocol (LDAP)

As of 16th of July 2001 we were aware of that five out of six vendors involved have addressed the security implications brought up by this test-suite with fixed builds of their products. These releases have been verified to survive the test-material as it is.

[This page is CSS2 enabled. Your browser might not fully support it]