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

• ABSTRACT
• Table of Contents
• Introduction
• Analysis
• Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
  • Specifications Design
  • Design of Exceptional Elements
    • Encoding Exceptions
    • Application Exceptions
• Injection
• Semantic Rules
• Instrumentation
• Implementation
  • Results from the Test-Runs
  • Verification via Exploits
• Test-Material Package
  • Package Information
  • Licence and Copyright
  • Usage
    • Using with Java
    • Using without Java
  • Download
  • Notes
• Conclusions
  • Acknowledgments
• Vulnerability Management
  • Prior Public Vulnerabilities
  • The Vulnerability Process
  • Advisories and Vendor Statements

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

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.

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.

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

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:

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:

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.

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.

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

• c06-ldapv3-enc-r1.jar - Test-material (exceptional BER encodings) release v1
• c06-ldapv3-enc-r1.jar.asc - Detached PGP signature
• c06-ldapv3-app-r1.jar - Test-material (exceptional search PDUs) release v1
• c06-ldapv3-app-r1.jar.asc - Detached PGP signature

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]