OUSPG
[This page is CSS2 enabled. Your browser might not fully support it]
PROTOS Test-Suite: c06-ldapv3
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.
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.
"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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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].
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.
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.
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.
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.
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.
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.
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.
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]
|